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
| ||
|
Date: Fri, 7 Jan 2022 13:22:45 -0800 From: Doug Anderson <dianders@...omium.org> To: Abhishek Kumar <kuabhs@...omium.org> Cc: Kalle Valo <kvalo@...eaurora.org>, Rakesh Pillai <pillair@...eaurora.org>, LKML <linux-kernel@...r.kernel.org>, linux-wireless <linux-wireless@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Kalle Valo <kvalo@...nel.org>, ath10k <ath10k@...ts.infradead.org>, netdev <netdev@...r.kernel.org> Subject: Re: [PATCH 1/2] ath10k: search for default BDF name provided in DT Hi, On Fri, Jan 7, 2022 at 12:05 PM Abhishek Kumar <kuabhs@...omium.org> wrote: > > There can be cases where the board-2.bin does not contain > any BDF matching the chip-id+board-id+variant combination. > This causes the wlan probe to fail and renders wifi unusable. > For e.g. if the board-2.bin has default BDF as: > bus=snoc,qmi-board-id=67 but for some reason the board-id > on the wlan chip is not programmed and read 0xff as the > default value. In such cases there won't be any matching BDF > because the board-2.bin will be searched with following: > bus=snoc,qmi-board-id=ff > To address these scenarios, there can be an option to provide > fallback default BDF name in the device tree. If none of the > BDF names match then the board-2.bin file can be searched with > default BDF names assigned in the device tree. > > The default BDF name can be set as: > wifi@...0000 { > status = "okay"; > qcom,ath10k-default-bdf = "bus=snoc,qmi-board-id=67"; Rather than add a new device tree property, wouldn't it be good enough to leverage the existing variant? Right now I think that the board file contains: 'bus=snoc,qmi-board-id=67.bin' 'bus=snoc,qmi-board-id=67,qmi-chip-id=320,variant=GO_LAZOR.bin' 'bus=snoc,qmi-board-id=67,qmi-chip-id=320,variant=GO_POMPOM.bin' 'bus=snoc,qmi-board-id=67,qmi-chip-id=4320,variant=GO_LAZOR.bin' 'bus=snoc,qmi-board-id=67,qmi-chip-id=4320,variant=GO_POMPOM.bin' ...and, on lazor for instance, we have: qcom,ath10k-calibration-variant = "GO_LAZOR"; The problem you're trying to solve is that on some early lazor prototype hardware we didn't have the "board-id" programmed we could get back 0xff from the hardware. As I understand it 0xff always means "unprogrammed". It feels like you could just have a special case such that if the hardware reports board ID of 0xff and you don't get a "match" that you could just treat 0xff as a wildcard. That means that you'd see the "variant" in the device tree and pick one of the "GO_LAZOR" entries. Anyway, I guess it's up to the people who spend more time in this file which they'd prefer, but that seems like it'd be simple and wouldn't require a bindings addition... -Doug
Powered by blists - more mailing lists