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: <7DCB1B9A-D08E-4837-B2FE-6DA476B54B0D@slashdirt.org>
Date:   Wed, 16 Feb 2022 22:55:11 +0100
From:   Thibaut <hacks@...shdirt.org>
To:     Christian Lamparter <chunkeey@...il.com>
Cc:     Robert Marko <robimarko@...il.com>, Kalle Valo <kvalo@...nel.org>,
        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

Hi,

> Le 16 févr. 2022 à 22:19, Christian Lamparter <chunkeey@...il.com> a écrit :
> 
> Hi,
> 
> On 16/02/2022 14:38, Robert Marko wrote:
>> Silent ping,
>> Does anybody have an opinion on this?
> 
> As a fallback, I've cobbled together from the old scripts that
> "concat board.bin into a board-2.bin. Do this on the device
> in userspace on the fly" idea. This was successfully tested
> on one of the affected devices (MikroTik SXTsq 5 ac (RBSXTsqG-5acD))
> and should work for all MikroTik.
> 
> "ipq40xx: dynamically build board-2.bin for Mikrotik"
> <https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=52f3407d94da62b99ba6c09f3663464cccd29b4f>
> (though I don't think this link will stay active for
> too long.)

IMHO Robert’s patch addresses an actual bug in ath10k whereby the driver sends the same devpath for two different devices when requesting board-1 BDF, which doesn’t seem right.

Your proposal is less straightforward than using unmodified board-1 data (as could be done if the above bug did not occur) and negates the previous efforts not to store this data on flash (using instead the kernel’s documented firmware sysfs loading facility - again possible without the above issue).

HTH
T-Bone