> Did you do any regression tests on other types of ar9300 hardware to > ensure these patches don't negatively affect existing systems? I've tried this new driver on a QCA9558 SoC (Netgear EX7300v1) which is another ar9300 device, and the access point performance didn't seem to be affected. I could do more detailed tests if desired. > > > Revert "ath9k_hw: fall back to OTP ROM when platform data has no valid > > eeprom data" > > This revert seems a bit dodgy; the commit message states "Users > currently relying on this silent fallback will need to stop providing > invalid EEPROM data to the driver." - which kinda sounds like a > kernel-to-userspace regression to me? Do any such systems actually > exist? I'm not sure if such systems exist. They shouldn't for the SoC devices like QCA9558, because i don't think they support EEPROM at all. It's possible that they exist for pcie devices, but I expect the vast majority of users would not be overriding the eeprom. Arguably, if they are setting qca,no-eeprom and this silent fallback ignores and uses eeprom anyways, that could be considered a bug that is fixed here? We could also choose to keep the fallback except for this new device. I cc'ed Felix Fietkau here. If you remember the context for this change, that would probably be helpful.
