netdev - Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

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]

Message-ID: <CAOX2RU7VaxdU3VykTZER-pdpu6pnk3tbVrBmkGU=jPQo6rL3Xg@mail.gmail.com>
Date:   Thu, 14 Oct 2021 14:01:58 +0200
From:   Robert Marko <robimarko@...il.com>
To:     Christian Lamparter <chunkeey@...il.com>
Cc:     kvalo@...eaurora.org, davem@...emloft.net, kuba@...nel.org,
        ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection

On Thu, 14 Oct 2021 at 13:54, Christian Lamparter <chunkeey@...il.com> wrote:
>
> On 10/10/2021 00:17, Robert Marko wrote:
> > Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the
> > BDF-s to be extracted from the device storage instead of shipping packaged
> > API 2 BDF-s.
> >
> > This is required as MikroTik has started shipping boards that require BDF-s
> > to be updated, as otherwise their WLAN performance really suffers.
> > This is however impossible as the devices that require this are release
> > under the same revision and its not possible to differentiate them from
> > devices using the older BDF-s.
> >
> > In OpenWrt we are extracting the calibration data during runtime and we are
> > able to extract the BDF-s in the same manner, however we cannot package the
> > BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on
> > the fly.
> > This is an issue as the ath10k driver explicitly looks only for the
> > board.bin file and not for something like board-bus-device.bin like it does
> > for pre-cal data.
> > Due to this we have no way of providing correct BDF-s on the fly, so lets
> > extend the ath10k driver to first look for BDF-s in the
> > board-bus-device.bin format, for example: board-ahb-a800000.wifi.bin
> > If that fails, look for the default board file name as defined previously.
> >
> > Signed-off-by: Robert Marko <robimarko@...il.com>
> > ---
>
> As mentioned in Robert's OpenWrt Pull request:
> https://github.com/openwrt/openwrt/pull/4679
>
> It looks like the data comes from an mtd-partition parser.
> So the board data takes an extra detour through userspace
> for this.
>
> Maybe it would be great, if that BDF (and likewise pre-cal)
> files could be fetched via an nvmem-consumer there?
> (Kalle: like the ath9k-nvmem patches)

Christian, in this case, NVMEM wont work as this is not just read from
an MTD device, it first needs to be parsed from the MikroTik TLV, and
then decompressed as they use LZO with RLE to compress the caldata
and BDF-s.

>
> This would help with many other devices as well, since currently
> in OpenWrt all pre-cal data has to be extracted by userspace
> helpers, while it could be easily accessible through nvmem.

Yeah, for non-MikroTik stuff pre-cal data via NVMEM would be great.

Regards,
Robert
>
> What do you think?
>
> Cheers,
> Christian