[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Mc4AZR3aztmODtpgLt3P63=WGGfupjNSSJdFseH=pAhtg@mail.gmail.com>
Date: Tue, 24 Sep 2024 19:07:35 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Jeff Johnson <quic_jjohnson@...cinc.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Kalle Valo <kvalo@...nel.org>,
"David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Jeff Johnson <jjohnson@...nel.org>, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
ath11k@...ts.infradead.org, linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH net-next v2] dt-bindings: net: ath11k: document the inputs
of the ath11k on WCN6855
On Tue, Sep 24, 2024 at 6:46 PM Jeff Johnson <quic_jjohnson@...cinc.com> wrote:
>
> On 9/24/2024 1:06 AM, Krzysztof Kozlowski wrote:
> > On 20/09/2024 23:02, Jeff Johnson wrote:
> >> Again, since I'm a DT n00b:
> >> Just to make sure I understand, you are saying that with this change any
> >> existing .dts/.dtb files will still work with an updated driver, so the new
> >> properties are not required to be populated on existing devices.
> >
> > Did you folks rejected patches acked by DT maintainers on basis of not
> > understanding DT at all?
>
> I personally have not rejected any DT patches. Nor have I accepted any.
> I'm deferring to Kalle.
>
> >> However a new driver with support for these properties will utilize them when
> >> they are present, and the current ath11k .dts files will need to be updated to
> >
> > It is not related to drivers at all. Nothing in this thread is related
> > to drivers.
> >
> > Can we entirely drop the drivers from the discussion?
>
> I brought up drivers since in the discussion there was concern that this DT
> change would potentially break existing devices that have a DTS that defines
> qcom,ath11k-calibration-variant, and I wanted clarification on that point.
>
> /jeff
How could this happen? DT schema is used to validate device-tree
sources but is not used by the kernel code in any way. I've said it
several times over the course of this and the previous (qca6390)
discussion.
Bartosz
Powered by blists - more mailing lists