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. //Peter _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
