Michael Schwingen wrote:
> 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.

Yes, that makes sense.

> 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.

I agree.

> However, I would consider this really bad practice.

I agree that violating the spec is bad practice. I don't agree that
permitted reset patterns are bad practice. Especially I do not agree
that doing anything quicker than normal, while staying compliant, is
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.

Thanks for the detailed information!

It makes perfect sense that the I²C transaction would be interrupted.

It would be very simple to investigate that on problematic hardware
with something quite low cost such as the $50 Openbench Logic Sniffer
or even a Logic Shrimp.

ath9k-devel mailing list

Reply via email to