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, 23 Jun 2022 22:16:38 +0200 From: Robert Marko <robimarko@...il.com> To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> Cc: Kalle Valo <kvalo@...nel.org>, davem@...emloft.net, Eric Dumazet <edumazet@...gle.com>, kuba@...nel.org, pabeni@...hat.com, Rob Herring <robh+dt@...nel.org>, krzysztof.kozlowski+dt@...aro.org, ath11k@...ts.infradead.org, linux-wireless@...r.kernel.org, netdev@...r.kernel.org, Devicetree List <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath11k: add new DT entry for board ID On Wed, 22 Jun 2022 at 16:55, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> wrote: > > On 21/06/2022 20:47, Robert Marko wrote: > > On Tue, 21 Jun 2022 at 17:58, Krzysztof Kozlowski > > <krzysztof.kozlowski@...aro.org> wrote: > >> > >> On 21/06/2022 15:53, Robert Marko wrote: > >>> bus + qmi-chip-id + qmi-board-id and optionally the variant are currently > >>> used for identifying the correct board data file. > >>> > >>> This however is sometimes not enough as all of the IPQ8074 boards that I > >>> have access to dont have the qmi-board-id properly fused and simply return > >>> the default value of 0xFF. > >>> > >>> So, to provide the correct qmi-board-id add a new DT property that allows > >>> the qmi-board-id to be overridden from DTS in cases where its not set. > >>> This is what vendors have been doing in the stock firmwares that were > >>> shipped on boards I have. > >>> > >>> Signed-off-by: Robert Marko <robimarko@...il.com> > >> > >> Thank you for your patch. There is something to discuss/improve. > >> > >>> --- > >>> .../devicetree/bindings/net/wireless/qcom,ath11k.yaml | 8 ++++++++ > >>> 1 file changed, 8 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml > >>> index a677b056f112..fe6aafdab9d4 100644 > >>> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml > >>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml > >>> @@ -41,6 +41,14 @@ properties: > >>> * reg > >>> * reg-names > >>> > >>> + qcom,ath11k-board-id: > >> > >> The "board" a bit confuses me because in the context of entire system it > >> means the entire hardware running Qualcomm SoC. This is sometimes > >> encoded as qcom,board-id property. > > > > Hi Krzysztof, > > I agree that the name is a bit confusing, it's not the same as > > qcom,board-id AFAIK > > and QCA as well as vendors are using a similar property in the wifi > > node to override > > the default qmi-board-id to the correct one as its rarely properly fused. > > > > I assume it would be better-called qcom,ath11k-qmi-board-id as you > > dont even have > > to be using a Qualcomm SoC as the same is used by PCI ath11k cards as well. > > > > Thanks for the explanation. What is the "board" in that context? The > card/hardware with ath11k? Then maybe qcom,ath11k-qmi-id or > qcom,ath11k-qmi-hw-id? Hi, I assume it started off as a numerical value to match the board design and was then simply carried off to the PCI cards as well. qcom,ath11k-qmi-hw-id is fine by me, will just expand the description to make it clear. Regards, Robert > > Best regards, > Krzysztof
Powered by blists - more mailing lists