Message ID | 20230629231625.951744-1-wlooi@ucalgary.ca (mailing list archive) |
---|---|
Headers | show |
Series | wifi: ath9k: add support for QCN550x | expand |
I've started looking at this now. A few initial questions: > This patchset adds support for QCN550x. Compared to previous versions of > this patchset: > > - Removed hidden dependencies on ah macro > (see commit b3a663f0037d20e77bbafd9271a3d9dd0351059d) > - Done significantly more testing and performance improvements. In my > informal testing, the 3x3 performance of this driver generally meets > or exceeds the performance of stock firmwares, which was not the case > for previous patchsets. The main source of the improvement was > enabling the clock doubler. Did you do any regression tests on other types of ar9300 hardware to ensure these patches don't negatively affect existing systems? > 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? -Toke
> 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.
I've updated the following github pull request to show how this patch can be incorporated into OpenWrt to provide 2.4GHz wifi support for all QCN5502 devices: https://github.com/openwrt/openwrt/pull/9389 There are prebuilt images for all existing QCN5502 devices, and it is also possible to build from source for any device. Hopefully this can provide some context on how this driver can be useful, and can be a source of feedback from others who try out the driver.
Wenli Looi <wlooi@ucalgary.ca> writes: > I've updated the following github pull request to show how this patch > can be incorporated into OpenWrt to provide 2.4GHz wifi support for > all QCN5502 devices: https://github.com/openwrt/openwrt/pull/9389 > > There are prebuilt images for all existing QCN5502 devices, and it is > also possible to build from source for any device. > > Hopefully this can provide some context on how this driver can be > useful, and can be a source of feedback from others who try out the > driver. Thanks! FWIW, I don't have any objections in principle to merging this, but I'm not comfortable doing so until someone has reviewed it. So anything you can do to help find a reviewer will be helpful :) -Toke