Fix rtk_setmulti() so that it works correctly for PCIe chips where
the multicast hash table are in reverse order compared to older
devices.
Closes PR kern/35579 from Nino Dehne.
needs to be rewritten to use the scsipi layer. Additionally:
- Missing copyright years: 2000, 2001, 2002, 2003
- Missing attribution: Andrew Doran and Jason R. Thorpe
If we're handling system management interrupts ourselves, the system locks
solid when the ACPI timer SCI fires. Disable this interrupt so we can have
an uptime of more than ~10 minutes.
The "pci0 dev 1 function 2" aka "System Management" on the nForce chipset
isn't detected on the Xbox. If XBOX is defined and arch_i386_is_xbox is
true, force intrline to 12 and map the system management IO space at
0x8000. We can now call iic_smbus_intr when a system management interrupt
takes place.
While we're here, make amdpm_smbus honour the I2C_F_POLL flag.
The Xbox no longer resets when you press the eject button.
From John Nielsen on freebsd-mobile.
Not tested, but almost certainly better than attaching as ugen.
FreeBSD has a UQ_ASSUME_CM_OVER_DATA quirk for this device; I can't
figure out what that means.
Most Cardbus bridges supported by pccbb(4) fire a power-cycle
interrupt when the power state of a cardslot changes from 'off' to
'on'. TI bridges fire a power-cycle interrupt on both on->off and
off->on changes.
When pccbb_power() powered-down a cardslot, it did not wait around
for the power-cycle interrupt. When pccbb_power() powered-up a
cardslot, it did wait for the interrupt. If a pccbb_power(UP)
followed a pccbb_power(DOWN) very closely, pccbb_power() used to
interpret the power-cycle interrupt for the up->down transition as
"power-up complete," read the power-state bit and, finding that
power had NOT been activated, complain, "cbb0: power on failed?"
Then pccbb_power() exited before power-activation was complete,
falsely indicating that the power-activation *was* complete. After
that, a driver attach/enable routine would blithely configure a
card that was not fully powered-up. An operator who ran a command
such as 'ifconfig rtw0 down up' or 'ifconfig ath0 down up' would
read 'cbb0: power on failed?' in the system log, and their NIC
would misbehave.
This excerpt from a comment in the source should suffice to explain
how I fixed the bug,
/*
* Wait as long as 200ms for a power-cycle interrupt. If
* interrupts are enabled, but the socket has already
* changed to the desired status, keep waiting for the
* interrupt. "Consuming" the interrupt in this way keeps
* the interrupt from prematurely waking some subsequent
* pccbb_power call.
And this explains why this patch will work for Ricoh bridges that
do not fire an interrupt on the on->off transition:
* XXX Not every bridge interrupts on the ->OFF transition.
* XXX That's ok, we will time-out after 200ms.
*
* XXX The power cycle event will never happen when attaching
* XXX a 16-bit card. That's ok, we will time-out after
* XXX 200ms.
*/
M. Warner Losh and Charles M. Hannum provided valuable input on
this patch.
via Darrin B.Jewell.
XXX: maybe we should check this sc_rev on more place
- use RTK_TXCFG_HWREV (0x7cc00000) rather than 0x7c800000
to mask the hwrev value since bit 0x00400000 is used only by 8139D
which is not supported by this driver
- fix a tyop
