[ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd

[Michael Schwingen <rincewind@discworld.dascon.de>]

Am 27.03.2013 23:33, schrieb Adrian Chadd:
> Sure, here's what's going on:
>
> * There's a PCI bus reset. It's a pin. On the PCI bus.
> * The BIOS can yank that down to reset all the devices.
> * There's timing requirements for how long that pin can be pulled down
> to reset and release.
> * After the PCI bus is reset, the atheros MAC initialises the PCI
> space by reading a bunch of values from EEPROM/OTP and writing them
> into the register space. Most of these are PCI space registers but
> there can be others.
> * Some vendors do daft things, like multiple quick PCI bus resets
> back-to-back rather than doing a reset and waiting for whatever the
> standard requires or the best practice is; or just asserting reset
> quickly rather than holding it down for the required time is;
> * .. and this can interrupt / confuse the MAC during this whole
> register initialisation path.
I have had this on an ambedded design - IIRC with an AR5414, back when
Atheros switched from 3-wire EEPROMs to I2C EEPROMs on the MiniPCI modules.

If you do a PCI reset just at the time when the MAC is doing an I2C
read, the I2C EEPROM will hang in the middle of a bus cycle, with no
possibility to reset it when the MAC does the next read access, so at
least the first read will get corrupt data.

AFAIK, the PCI standard does not forbid this (there are only minimum
times for *assertion* of the reset signal), so technically, the card
violates the PCI spec if it can't cope with two PCI resets in direct order.

However, I would consider this really bad practice.

In our case, inserting a minimum delay between the point where the
hardware de-asserts reset and the point where the code re-asserts it
(because it might be a warm boot) fixed the problem reliably.

cu
Michael