netdev - Re: [PATCH] ath9k: fix calibration data endianness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 16 Apr 2023 12:50:00 +0200
From:   Toke Høiland-Jørgensen <toke@...e.dk>
To:     Christian Lamparter <chunkeey@...il.com>,
        Álvaro Fernández Rojas 
        <noltari@...il.com>, f.fainelli@...il.com, jonas.gorski@...il.com,
        nbd@....name, kvalo@...nel.org, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ath9k: fix calibration data endianness

Christian Lamparter <chunkeey@...il.com> writes:

> On 4/15/23 18:02, Christian Lamparter wrote:
>> Hi,
>> 
>> On 4/15/23 17:25, Toke Høiland-Jørgensen wrote:
>>> Álvaro Fernández Rojas <noltari@...il.com> writes:
>>>
>>>> BCM63xx (Big Endian MIPS) devices store the calibration data in MTD
>>>> partitions but it needs to be swapped in order to work, otherwise it fails:
>>>> ath9k 0000:00:01.0: enabling device (0000 -> 0002)
>>>> ath: phy0: Ignoring endianness difference in EEPROM magic bytes.
>>>> ath: phy0: Bad EEPROM VER 0x0001 or REV 0x00e0
>>>> ath: phy0: Unable to initialize hardware; initialization status: -22
>>>> ath9k 0000:00:01.0: Failed to initialize device
>>>> ath9k: probe of 0000:00:01.0 failed with error -22
>>>
>>> How does this affect other platforms? Why was the NO_EEP_SWAP flag set
>>> in the first place? Christian, care to comment on this?
>> 
>> I knew this would come up. I've written what I know and remember in the
>> pull-request/buglink.
>> 
>> Maybe this can be added to the commit?
>> Link: https://github.com/openwrt/openwrt/pull/12365
>> 
>> | From what I remember, the ah->ah_flags |= AH_NO_EEP_SWAP; was copied verbatim from ath9k_of_init's request_eeprom.
>> 
>> Since the existing request_firmware eeprom fetcher code set the flag,
>> the nvmem code had to do it too.
>> 
>> In theory, I don't think that not setting the AH_NO_EEP_SWAP flag will cause havoc.
>> I don't know if there are devices out there, which have a swapped magic (which is
>> used to detect the endianess), but the caldata is in the correct endiannes (or
>> vice versa - Magic is correct, but data needs swapping).
>> 
>> I can run tests with it on a Netzgear WNDR3700v2 (AR7161+2xAR9220)
>> and FritzBox 7360v2 (Lantiq XWAY+AR9220). (But these worked fine.
>> So I don't expect there to be a new issue there).
>
> Nope! This is a classic self-own!... Well at least, this now gets documented!
>
> Here are my findings. Please excuse the overlong lines.
>
> ## The good news / AVM FritzBox 7360v2 ##
>
> The good news: The AVM FritzBox 7360v2 worked the same as before.

[...]

> ## The not so good news / Netgear WNDR3700v2 ##
>
> But not the Netgar WNDR3700v2. One WiFi (The 2.4G, reported itself now as the 5G @0000:00:11.0 -
> doesn't really work now), and the real 5G WiFi (@0000:00:12.0) failed with:
> "phy1: Bad EEPROM VER 0x0001 or REV 0x06e0"

[...]

Alright, so IIUC, we have a situation where some devices only work
*with* the flag, and some devices only work *without* the flag? So we'll
need some kind of platform-specific setting? Could we put this in the
device trees, or is there a better solution?

-Toke