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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 3 Dec 2020 17:03:02 +0530 From: "Rakesh Pillai" <pillair@...eaurora.org> To: "'Doug Anderson'" <dianders@...omium.org> Cc: "'Abhishek Kumar'" <kuabhs@...omium.org>, "'Kalle Valo'" <kvalo@...eaurora.org>, "'LKML'" <linux-kernel@...r.kernel.org>, "'ath10k'" <ath10k@...ts.infradead.org>, "'Brian Norris'" <briannorris@...omium.org>, "'linux-wireless'" <linux-wireless@...r.kernel.org>, "'David S. Miller'" <davem@...emloft.net>, "'Jakub Kicinski'" <kuba@...nel.org>, "'netdev'" <netdev@...r.kernel.org> Subject: RE: [PATCH v2 1/1] ath10k: add option for chip-id based BDF selection > -----Original Message----- > From: Doug Anderson <dianders@...omium.org> > Sent: Tuesday, December 1, 2020 12:49 AM > To: Rakesh Pillai <pillair@...eaurora.org> > Cc: Abhishek Kumar <kuabhs@...omium.org>; Kalle Valo > <kvalo@...eaurora.org>; LKML <linux-kernel@...r.kernel.org>; ath10k > <ath10k@...ts.infradead.org>; Brian Norris <briannorris@...omium.org>; > linux-wireless <linux-wireless@...r.kernel.org>; David S. Miller > <davem@...emloft.net>; Jakub Kicinski <kuba@...nel.org>; netdev > <netdev@...r.kernel.org> > Subject: Re: [PATCH v2 1/1] ath10k: add option for chip-id based BDF > selection > > Hi, > > On Tue, Nov 24, 2020 at 7:44 PM Rakesh Pillai <pillair@...eaurora.org> > wrote: > > > > > > I missed on reviewing this change. Also I agree with Doug that this is not > > > the change I was looking for. > > > > > > > > The argument "with_variant" can be renamed to "with_extra_params". > > > There is no need for any new argument to this function. > > > > Case 1: with_extra_params=0, ar->id.bdf_ext[0] = 0 -> The > default > > > name will be used (bus=snoc,qmi_board_id=0xab) > > > > Case 2: with_extra_params=1, ar->id.bdf_ext[0] = 0 -> > > > bus=snoc,qmi_board_id=0xab,qmi_chip_id=0xcd > > > > Case 3: with_extra_params=1, ar->id.bdf_ext[0] = "xyz" -> > > > bus=snoc,qmi_board_id=0xab,qmi_chip_id=0xcd,variant=xyz > > > > > > > > ar->id.bdf_ext[0] depends on the DT entry for variant field. > > > > > > I'm confused about your suggestion. Maybe you can help clarify. Are > > > you suggesting: > > > > > > a) Only two calls to ath10k_core_create_board_name() > > > > > > I'm pretty sure this will fail in some cases. Specifically consider > > > the case where the device tree has a "variant" defined but the BRD > > > file only has one entry for (board-id) and one for (board-id + > > > chip-id) but no entry for (board-id + chip-id + variant). If you are > > > only making two calls then I don't think you'll pick the right one. > > > > > > Said another way... > > > > > > If the device tree has a variant: > > > 1. We should prefer a BRD entry that has board-id + chip-id + variant > > > 2. If #1 isn't there, we should prefer a BRD entry that has board-id + chip- > id > > > 3. If #1 and #2 aren't there we fall back to a BRD entry that has board-id. > > > > > > ...without 3 calls to ath10k_core_create_board_name() we can't handle > > > all 3 cases. > > > > This can be handled by two calls to ath10k_core_create_board_name > > 1) ath10k_core_create_board_name(ar, boardname, sizeof(boardname), > true) : As per my suggestions, this can result in two possible board names > > a) If DT have the "variant" node, it outputs the #1 from your suggestion > (1. We should prefer a BRD entry that has board-id + chip-id + variant) > > b) If DT does not have the "variant" node, it outputs the #2 from your > suggestion (2. If #1 isn't there, we should prefer a BRD entry that has board- > id + chip-id) > > > > 2) ath10k_core_create_board_name(ar, boardname, sizeof(boardname), > false) : This is the second call to this function and outputs the #3 from your > suggestion (3. If #1 and #2 aren't there we fall back to a BRD entry that has > board-id) > > What I'm trying to say is this. Imagine that: > > a) the device tree has the "variant" property. > > b) the BRD file has two entries, one for "board-id" (1) and one for > "board-id + chip-id" (2). It doesn't have one for "board-id + chip-id > + variant" (3). > > With your suggestion we'll see the "variant" property in the device > tree. That means we'll search for (1) and (3). (3) isn't there, so > we'll pick (1). ...but we really should have picked (2), right? Do we expect board-2.bin to not be populated with the bdf with variant field (if its necessary ?) Seems fine for me, if we have 2 fallback names if that is needed. > > -Doug
Powered by blists - more mailing lists