This bit(SW event 7 in publicly available data sheet) is used to
make RX CPU handle a firmware command and the bit is automatically
cleared after RX CPU completed the command.
Generally firmware command takes the following steps.
1. Write BGE_SRAM_FW_CMD_MB with a command.
2. Write BGE_SRAM_FW_CMD_LEN_MB with the length of the command in bytes.
3. Write BGE_SRAM_FW_CMD_DATA_MB with actual command data.
4. Generate BGE_RX_CPU_EVENT and let firmware handle the command.
5. Wait for the ACK of the firmware command.
No functional changes.
about the various driver events like load, unload, reset, suspend,
restart, and ioctl operations.
Define driver's event rather than using hard-coded values. We don't
still send suspend/resume event to firmware.
Previously bge(4) used BGE_SDI_STATUS to send events. Because driver
has to access firmware mail box to inform current state, using
BGE_SDI_STATUS register was wrong. The end result was the same as
BGE_SDI_STATUS is 0x0C04.
No functional changes.
The origin of GENCOMM seems to come from Alteon Tigon Host/NIC
interface definition where it defines general communications region
which is active when firmware is loaded and running. This region
was used in communication between the host and processor internal
to the Tigon chip.
Broadcom data sheet also defines the region as 'Software Gencomm'
in NetXtreme memory map but lacks detailed description of its
interface so it was hard to know which ones are used for which
interface.
This change shall slightly enhance readability.
No functional changes.
larger than 4KB in size. However the maximum DMA segment size
created in DMA tag is 4KB, so we wouldn't encounter the issue here.
Just record this issue such that let developers not to create a DMA
segment that is larger than 4KB for BCM5719. It's possible to split
a DMA segment into multiple smaller ones in run time but I believe
it's not worth to implement that.
o Protect bge(4) status block access and register dump with driver lock.
o Add missing bus_dmamap_sync() before dumping status block.
o Use minimum status block size, 32 bytes, for status block dump on most
controllers except BCM5700 AX/BX.
While I'm here, make the handler show 5717 Plus in hardware flags.
* preserve AR_TxIntrReq on every descriptor in an aggregate chain,
not just the first descriptor;
* always blank out the descriptor in ar5416ChainTxDesc() when forming
aggregates - the way I'm using this in the 11n branch is to first
chain aggregates together, then use the other HAL calls to fill in
the details.
* Add the TID field in the TX status descriptor;
* Add in the 11n first/middle/last functions for fiddling
with the descriptors. These are from the Linux and the
reference driver, but I'm not (currently) using them.
* Add further AR_ISR_S5 register definitions.
Obtained from: Linux ath9k, Atheros
interfere with traffic, as the NF load can take quite a while and poking the
AGC every 10uS is just a bit silly.
Instead, just leave the baseband NF calibration where it is and just read it
back next time a longcal interval happens.
controller.
AX88772B data sheet does not show detailed information about
checksum offloading related things. It seems the controller has
lots of options to support checksum offloading but I failed to
understand why this feature requires so much complex controller
configuration and status bits.
One of major difference between AX88772B and its predecessor is
AX88772B uses a new RX header format when RX checksum offloading is
enabled. It also requires the received length of a frame should be
multiple of 4. Controller will pad necessary bytes to make the
length of received frame to be multiple of 4. It is driver's
responsibility to offset this pad bytes.
Note, AX88772B could be configured to get partial checksum value in
in RX header. This mode uses different RX header format and
currently we don't use that fature.
This change makes axe(4) use driver specific MII attach handler to
override uether(9)'s default MII attach and announce flow-control
capability for AX88178/AX88772A/AX88772B to PHY drivers. It seems
original AX88772 also supports flow-control but I didn't enable it
due to lack of test/access to the controller. The flow-control
threshold parameter is loaded from EEPROM and there is no way to
override this value without reprogramming EEPROM. For AX88772B,
TX/RX IP/TCP/UDP checksum offloading is announced to network stack.
IPv6 and PPPoE checksum offloading is also supported by controller
but we have no way to take advantage of these features.
Driver already knows PHY address so make PHY driver know that
information and remove unnecessary PHY address check used in
miibus_readreg/miibus_writereg callbacks. Also announce AX88178,
AX88772A and AX88772B support VLAN over-sized frame.
While I'm here clean up headers and remove axe_start() in
axe_init() because the link wouldn't be available right after media
change.
handler such that driver can announce interface capabilities and
can do its own MII attach. Currently all USB ethernet controllers
have no way to establish a link with pause capabilities. Lack of
checksum offloading support also was one of reason to bring this
change in.
This change adds a couple of wrappers to USB ethernet drivers
(uether_ifmedia_upd, uether_init and uether_start). All exported
functions in uether has prefix uether_ so I think it's more
consistent to have wrappers that follow the convention.
This change preserves ABI/KPI so it should be safe to merge this
change to stable/8.
While I'm here add missing __FBSDID and clean up headers.
Reviewed by: hselasky
controller which is found on ULi M1563 South Bridge & M1689 Bridge.
These controllers look like a tulip clone.
M5263 controller does not support MII bitbang so use DC_ROM
register to access MII registers. Like other tulip variants, ULi
controller uses a setup frame to configure RX filter and uses new
setup frame format. It's not clear to me whether the controller
supports a hash based multicast filtering so this patch uses 14
perfect multicast filter to filter multicast frames. If number of
multicast addresses is greater than 14, controller is put into a
mode that receives all multicast frames.
Due to lack of access to M5261, this change was not tested with
M5261 but it probably works. Many thanks to Marco who provided
remote access to M5263.
Tested by: Marco Steinbach <coco <> executive-computing dot de>,
Martin MATO <martin.mato <> orange dot fr>
link such that calling dc_setcfg() right after media change would
be meaningless unless controller in question is not Davicom DM9102.
Ideally dc_setcfg() should be called when speed/duplex is resolved
otherwise it would reprogram controller with wrong speed/duplex
information. Because MII status change callback already calls
dc_setcfg() I think calling dc_setcfg() in dc_init_locked() is
wrong. For instance, it would take some time to establish a link
after mii_mediachg(), so blindly calling dc_setcfg() right after
mii_mediachg() will always yield wrong media configuration.
Extend dc_ifmedia_upd() to handle media change and still allow
21143 and Davidcom controllers program speed/duplex regardless of
current resolved speed/duplex of link. In theory 21143 may not need
to call dc_setcfg() right after media change, but leave it as it is
because there are too many variants to test that change. Probably
dc(4) shall need a PHY reset in dc_ifmedia_upd() but it's hard to
verify correctness of the change.
This change reliably makes ULi M5263 establish a link.
While I'm here correctly report media change result. Previously it
always reported a success.
- for the legacy PCI ATA channels move channel number out of the device
description, same as it is for ahci(4), siis(4) and mvs(4);
- add device description for the ISA ATA channels.
where the driver assumed that BA resources are still available due to
net80211 saying so.
PR: 161407, 159768
Tested by: cperciva, rene
MFC after: 3 days
As the underlying block is 4KB if the PMC throughput is low the measurement
will be reported on the next tick. pmcstat(8) use the modified flush API to
reclaim current buffer before displaying next top.
MFC after: 1 month
It seems the D_PSEUDO flag was meant to allow make_dev() to return NULL.
Nowadays we have a different interface for that; make_dev_p(). There's
no need to keep it there.
While there, remove an unneeded D_NEEDMINOR from the gpio driver.
Discussed with: gonzo@ (gpio)
Some earlier series (~AR5212?) play badly with BIOSes.
In these instances, they may require a forced reset (by transitioning
the NIC through D0 -> D3 -> D0) before they probe/attach correctly.
This is currently disabled because:
* I haven't figured out the "right" code to ensure this only happens
for PCI NICs (not PCIe or Cardbus);
* I haven't at all done wide scale testing for this, and I'm not yet
ready for said wide-scale testing.
I'm documenting this primarily so users with misbehaving NICs have
something to tinker with.
Obtained from: Atheros
The final missing bit here is enabling the PCI configuration register
read, but there's currently no glue available for the HAL to read (and
write) PCI configuration space registers.
Obtained from: Atheros
The AR5008/AR9001 series NICs have a bug where BB register reads
will occasionally be corrupted. This could cause issues with things
such as ANI, which adjust operational parameters based on the
BB radio register reads. This was introduced in the AR5008 chip
and fixed with the first released AR9002 series NIC (AR9280v2.)
A followup commit will implement the acutal WAR when reading
BB registers. I'm still not sure how I'll implement it - whether
it should be done in the osdep layer, or whether it should just
live in the AR5416 HAL. Either way, they can use this capability
bit to determine whether to implement the WAR or not.
Thankyou to various sources inside Atheros who have helped me track
down what this particular issue is.
Obtained from: Atheros
There are HAL methods which are actually direct register
access, rather than simply HAL calls. Because of this, these
register accesses would use the non-debug path in ah_osdep.h
as opt_ah.h isn't included.
With this, the correct register access methods are used,
so debugging traces show things such as TXDP checking and
TSF32 access.
Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
Reported by: Karim (fodillemlinkarimi <> gmail dot com)
Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
Reported by: Karim (fodillemlinkarimi <> gmail dot com)
That way the radar errors aren't enabled prematurely.
A DFS tester has reported that radar events are reported
during channel scanning, before DFS is actually enabled.
Use the offset into the device tree from fdtp as the phandle instead
of using pointer into the device tree. This will make sure that the
phandle fits into a uint32_t type, even when compiled for 64bit.
Reviewed by: raj, nathanw, marcel
on the largest multi-write size.
From the submitter:
==
I looked further into the magic 88-byte threshold after which the bug
occurs. It turns out that figure included the 24-byte tx_desc, and up
to 64 bytes of beacon frame (header+data).
rum_write_multi doesn't seem happy with writing >64 bytes at a time to
the MAC register. If I break it up into separate calls (e.g. bytes
0-63, then bytes 64-65, written at the appropriate offset) I see the
proper beacon frames being transmitted now.
==
Submitted by: Steven Chamberlain <steven@pyro.eu.org>
MFC after: 3 days
