Broadcom bcm5703/bcm5704, and bcm5705, respectively.
Taken verbatim from the Linux-2.6.12.3 tg3 driver, where the firmware
is explictly marked as non-GPLed (hex-encoded binary blobs are not in
source form, and therefore violate the terms of the GPL), along with
the Boradcom non-GPL copyright allowing distribution of this
hex-encoded firmware.
should obviously have been CSR_READ(sc, BGE_MARB_MODE) incurred during
my backport of 5714/5715 support from my netbsd-3 development branch,
back into -current.
acpi.c and take the opportunity to create a sysctl node that contains the
address of the main ACPI table.
The name of the node, "machdep.acpi_root", is questionable but matches the
one FreeBSD has, which will make it easier to port their acpidump(8)
program.
bcm5715 PCI-Express dual-port NICs. Taken from the Broadcom-supplied
Linux driver, bcm-8.3.13a.
Add nascent support for the bcm5780, but (since I have no bcm5780 to
test), don't yet add an entry which allows us to match or attach to a
5780.
Change 5752 support: Follow the lead of the Broadcom-supplied Linux
driver (bcm) and the Linux tg3 driver, and treat the 5752 like a 5750.
including the LSI MegaRAID SCSI 320-0x, 320-2x, 320-4x, 320-1E, 320-2E,
the LSI MegaRAID SATA 300-6x and 300-8x.
Tested on an LSI MegaRAID SATA 300-8x, which confirms private advice
that after PCI-IDs to our amr(4) driver, the newer LSI MegaRAID cards
will Just Work
The Linux megaraid2 driver accepts various Intel cards with the same
pci-device IDs as the LSI MegaRAID cards, treating them exaclty as the
above-listed LSI cards. Rework our amr(4) driver to also match and
attach those device-ID if seen with an Intel vendor-ID. Add the
Intel-vendor PCI decice-ids to pcidevs, so that PCI_VERBOSE will
correctly identify the Intel cards.
Update src/share/man/man4/amr.4 to list the newly-supported cards.
(NB: I don't have the LSI SCSI or any Intel cards to test, just the
LSI SATA, which works fine for me.)
TOC reading. Note that the external interfaces haven't changed. Only the
formatted toc is requestable.
The read msinfo command hasn't been changed in this patch though it could
become more clever using the CD_TOC_MSINFO format.
gigabit bcm5714 (copper), bcm5714S (serdes), bcm5715 (copper),
bcm5715S (SERDES), also bcm5780 (copper) and bcm5780S (SERDES).
Extracted from Broadcom-supplied Linux driver and from prerelease patches
for Linux-2.6.15.
We can now delete an entry from the tables using
veriexecctl delete /path/to/file
or remove an entire table using
veriexecctl delete /mount_point
(any directory will work for the mount point it's on)
so don't support the SCSI_PREVENT_ALLOW_MEDIUM_REMOVAL command.
When an "Illegal field in CDB" is reported for this command, mark the
device as non-removable (which is always true for USB keys from the SCSI
point of view), print a message and ignore the error.
For DIOCLOCK, return ENOTTY if the device is not removable instead of
trying a command which will fail.
Fix a problem reported by Hubert Feyrer for some USB umass devices, patch
tested by him.
bcm5714, added yesterday to sys/dev/pci/if_bge.c in revision 1.98,
since it appears the 5714 has a new PHY revision. Pending further
details, follow the FreeBSD code (as submitted by
John Cagle <john dot cagle at hp dot com> and committed by
ps@FreeBSD.ORG), and treat the 5714 integral PHY the same way as we
treat the bcm5750 integral PHY.
ethernet devices: bcm5714, bcm5752 (previously the 5789, but fvdl
committed that whilst I was musing).
Add definitions to sys/dev/pci/if_bgereg.h for the Broadcom 57xx-family
ASIC revisions on these newer chips.
Add entries to the PCI-device-version and bge-internal-asic-revision
tables in sys/dev/pci/if_bge.c to use these new devices. Pending
further information, follow the lead of FreeBSD's if_bge.c driver and,
pending further info, treat these new chips as we do the 5750.
match of 100 which will supersede the de and tlp match if present. If not
present, then these two drivers will fail to match an mii. Thanks to thorpej
for the explanation.
- handle SIOCADDMULTI/SIOCDELMULTI properly, i.e. no need to reset
anything as we don't do multicast filters (yet)
- restructure some code and use an IS_RUNNING macro
Fix iwi_init to set if_flags before the net80211 state machine is kicked
and init to IEEE80211_S_INIT.
The problem is that these ioctl()s are declared as _IO() and expect to pass an
integer as argument, instead of a pointer. When dereferencing the argument
pointer in the ioctl() handler as an int we get the upper 32bit of the value so
we simply dereference it as long. Other _IO() ioctl()s may need similar fixes.
Tested on sparc64, sparc and macppc.
boards. Currently, only the associated LED is being used because
that's the only LED my card has. The other two LEDs (OFDM and
activity) can later be set by someone, easily, who owns some board
with that LEDs.
Reviewed by Nick Hudson.
ADAPTER_REQ_RUN_XFER context (which can be interrupt context), defer this
to the ADAPTER_REQ_GROW_RESOURCES callback.
Fix a panic in uvm reported by John R. Shannon on port-xen; patch tested on
ahc by me and on ahd by John.
rather then 'IDE RAID'
fix the ID of the 9xxx series controller and rename to ATARAID_9k, since
3ware doesn't refer to it using the 'Escalade' family name
- Replace references to linesw[0] with a ttyldisc_default() function
that returns the default ("termios") line discipline.
- The linesw[] array is gone, replaced by a linked list.
- ttyldisc_add() and ttyldisc_remove() have been replaced by
ttyldisc_attach() and ttyldisc_detach().
- Things that provide line disciplines are now responsible for
registering those disciplines with the system. The linesw
structures are no longer declared in tty_conf.c
- Line disciplines are now refcounted; a lookup causes a reference to
be held. ttyldisc_release() releases the reference. Attempts to
detach an in-use line discipline result in EBUSY.
- Fix function signature lossage in if_sl.c, if_strip.c, and tty_tb.c
that was masked by the old tty_conf.c
- tty_init() is no longer necessary; delete it and its call from main().
- add some missing bus_dmamap_sync operations.
- don't process other interrupts if we get an error/radio off
interrupt.
- improve command handling - sleep against the descriptor instead
of the descriptor set.
framework. There is no need to waste the space if you are only using
algoritms provided by hardware accelerators. To get the software
implementations, add "pseudo-device swcr" to your kernel config.
- Lazily initialize the opencrypto framework when crypto drivers
(either hardware or swcr) register themselves with the framework.
shipped from the factory with TSO-capable firmware. The TSO support
here may also work on 5705 chips, but that is (so far) untested.
TSO support written after careful reading of the Linux tg3 driver,
and (after attempting to deconstruct the cut-and-paste mess therein)
very close reading of the Broadcom-supplied Linux driver, particularly
the building of Tx-DMA buffer descriptors (bds). The TSO code herein was
then rewritten from scratch, circa 4am local time, October 27 2005.
(In other words: this is 4am software; caveat emptor.)
Other magic register settings in this patch are required; without
them, attepmting to use TSO locks up the chip. The required register
settings were extracted from the cited Linux drivers.
Note that TSO-capable firmware for the 5703/5704 is distributed in
non-GPL form with the aforementioned Linux drivers. Once the 5705 case
is debugged, (particularly the pseudo-header checksum precalculation
flagged with an XXX) downloading that TSO-capable firmware to the
5703/5704 should, in principle, enable TSO support on all but the
original bcm5700 (I forget if the 5701 can support TSO, or not).
Note also that the ``hard case '' of IP/TCP headers spanning more than
one mbuf is not handled; I haven't been able to trigger it. In any
case, since TSO applies only to packets generated by the local TCP,
and our TCP always leaves space for TCP headers and a normal IP
header, TSO on an IP/TCP header spanning multiple headers can only
arise due to insertion of IP options. I beleive that we are clearly
better off outlawing that case, and requiring ip_insertoptions()
to pull-up TCP headers on any packets with M_CSUM_TSOv4 set.
As far as I know, bge hardwar does not support TSO for IPv6.
XXX Due to tradition the wheel is reported as the Z direction (and the Z
direction as W).
Now Apple's Mighty Mouse is fully supported, except the X11 mouse driver
doesn't know what to do with the new coordinate.
a W "coordinate" that can be used for these.
This changes the type of wsmouse_input(). To avoid changing a lot of drivers
a compatibilty #define is provided. Maybe changing all drivers would have
been better?
Add the ability to force ugen to attach with very high priority if "flags 1"
is specified. This can be used with the vendor and product locators to
force ugen to be used for certain devices.
Similarly, uhid only attaches if no other HID driver (ums or ukbd) wants it.
Again, "flags 1" will force uhid to attach anyway.
1 Added new sysctl controls for debugging.
2 Improve detection & support for hardware WEP.
3 Revamp handling of transmit descriptor rings.
4 Reliably IFF_OACTIVE when transmit descriptors are available, to
stop the transmit section of the driver from freezing up.
5 Fix beacon transmission in adhoc and hostap modes. XXX There is
a wart in hostap mode, where beacons are transmitted at 1/2 the
correct rate. Load beacon descriptors when the RTW_INTR_BINT
interrupt arrives; schedule RTW_INTR_BINT 1ms ahead of the target
beacon time.
6 Recover more gracefully from tx/rx errors: avoid
transmitter/receiver/chip resets. Try to re-synchronize software
state with hardware state---e.g., load next descriptor pointer
from hardware.
7 Activate the transmit watchdog timer for beacons as well as other
packets.
8 Introduce rtw_idle() that waits for transmit DMA to finish; call
it before resetting the transmitter.
1 Reset both IFF_OACTIVE and the transmit watchdog timer in
appropriate places to avoid both wedging the transmit section
and spurious transmit timeouts.
2 Reset IFF_ALLMULTI at the top of atw_filter_setup so that the
NIC will filter the multicast packets we are not interested in
after we come out of promiscuous mode.
3 In atw_txdrain, count drained transmit descriptors to avoid
descriptor exhaustion.
Only clear the IFF_OACTIVE flag when we have a chance of being able
to queue a packet to the hardware, instead of when the hardware queue
is empty, and fix up handling and prodding of the tx.
These fixes clear up an occasional "sk0: watchdog timeout" from the
on-board ethernet on my Asus A8V motherboard.
OK christos@
message. In such case we would not update resid with the proper value
(eventually resid would not be updated at all if there was only one data
phase). To fix this, have the script save the offset in the data tables at
disconnect time if there was a transfer, and use this to compute the resid
if the current offset is 0.
Problem reported and patch tested by edwin, Roy Bixler and YAMAMOTO Takashi.
Fix kern/31990 by YAMAMOTO Takashi.
o Intel 82801FBM ICH6M LPC Interface Bridge
o Intel 82801FB/FR PCI Express Port #2
o TI PCIxx21/x515 Cardbus Controller
o TI PCI7x21/7x11 IEEE 1394 Host Controller
o TI PCIxx11/21 Integrated FlashMedia Controller
Each call to the FreeBSD bge_start() routine the transmit producer
pointer index from the chip mailbox register BGE_MBX_TX_HOST_PROD0_LO.
The local copy of that value is then updated by bge_encap() as
bge_encap() encapsulates packets in the Tx ring. If bge_encap()
succeds in encpuslating one or more packets, bge_start() tells the
chip to start sending the newly-encinitiates writes the new value back
to the chip mailbox register.
However, comparison of the Linux drivers (Broadcom-supplied and
open-source tg3.c) and to the OpenSolaris driver confirms that
register BGE_MBX_TX_HOST_PROD0_LO is write-only to software.
Thus, we can just keep a copy in the softc, and eliminate the
(expensive) PCI register write on each call to bge_start().
``Make it so''.
instead of setting it to zero. Otherwise nothing ever sets it unless some code
explicitly changes the baud rate. For a serial console (in particular) we want
to use the baud rate set by the bios (or whatever) and used by theboot code.
This is the way it was before a 'new version of com driver' was added in 1997 (rev 1.99)
shouldn't claim it either, but a buggy software shouldn't be able to crash
the kernel anyway). Should fix port-sparc64/31925 by Johan A.van Zanten
(which should really be kern/31925).
Analysed and patch tested by Martin Husemann.
in some drivers including wd and scsi.
- physio: if a caller provided a buf, stick to use it
because some drivers use it as an identifier.
- sprinkle simple_locks.
- scsistrategy: rather than issueing an async request and
waiting for its completion, simply issue a sync request.
the way to wait for the completion had an assumption that
B_CALL is never used. it isn't the case after the recent
physio() changes.
pointed/analyzed/tested by Martin Husemann.
blindly assuming MCLBYTES will DTRT.
- Use bus_dmamap_load_mbuf() instead of bus_dmamap_load() where
appropriate.
- If we have to coalesce a Tx mbuf chain comprised of more than IWI_MAX_NSEG
segments, allocate a cluster iff the payload won't fit in the header.
- remove bogus multicast handling [pointed out by thorpej]
and don't reset the chip on ENETRESET; ENETRESET is a sign
that only the multicast filter needs changing.
- make a few functions static
- introduce gem_bitwait() to factor out some of the register wait code.
- add gem_stop() in attach
- some DEBUG should be GEM_DEBUG
- handle underrun, packet too long, and overflow errors by resetting the chip
- add handler in ioctl for add/del multi
- fix typo
Also:
- add a shadow sc_if_flags member so that we don't reset the chip if we
don't need to.
The change adopts the idea of fxp to drop the incoming packet and panic
if the old mbuf cannot be reloaded. Since the bus_dmamap is allocated
during attach, this is not supposed to happen. Since a lot of code moves
anyway, factor out the allocation of RX ring elements, which is shared
between the init path and the RX interrupt path.
XXX A better fix might be to borrow the mbuf from the logic end of the
XXX ring buffer, but that needs more involved driver changes.
Reviewed by dyoung@ and nick@
expensive, and pointless. As elsewhere in the kernel (and as approved
under FIPS-140-2 by multiple test labs, incidentally) we use arc4 to
generate IVs here; there is no benefit to their being cryptographically
strong so long as there is a sufficient Hamming distance between them.
- rather than embedding bufq_state in driver softc,
have a pointer to the former.
- move bufq related functions from kern/subr_disk.c to kern/subr_bufq.c.
- rename method to strategy for consistency.
- move some definitions which don't need to be exposed to the rest of kernel
from sys/bufq.h to sys/bufq_impl.h.
(is it better to move it to kern/ or somewhere?)
- fix some obvious breakage in dev/qbus/ts.c. (not tested)
jonathan