[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Mc_Qy6-Rgsw_uOweUXtoiZGMR0D22Ou9nXUJDDdPCZqLw@mail.gmail.com>
Date: Fri, 6 Sep 2024 09:44:32 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Kalle Valo <kvalo@...nel.org>
Cc: "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>
Subject: Re: [PATCH net-next v2] dt-bindings: net: ath11k: document the inputs
of the ath11k on WCN6855
On Thu, Sep 5, 2024 at 8:28 PM Kalle Valo <kvalo@...nel.org> wrote:
>
> Bartosz Golaszewski <brgl@...ev.pl> writes:
>
> > On Thu, Sep 5, 2024 at 5:47 PM Kalle Valo <kvalo@...nel.org> wrote:
> >>
> >> Bartosz Golaszewski <brgl@...ev.pl> writes:
> >>
> >> >> > + - if:
> >> >> > + properties:
> >> >> > + compatible:
> >> >> > + contains:
> >> >> > + const: pci17cb,1103
> >> >> > + then:
> >> >> > + required:
> >> >> > + - vddrfacmn-supply
> >> >> > + - vddaon-supply
> >> >> > + - vddwlcx-supply
> >> >> > + - vddwlmx-supply
> >> >> > + - vddrfa0p8-supply
> >> >> > + - vddrfa1p2-supply
> >> >> > + - vddrfa1p8-supply
> >> >> > + - vddpcie0p9-supply
> >> >> > + - vddpcie1p8-supply
> >> >>
> >> >> Like we discussed before, shouldn't these supplies be optional as not
> >> >> all modules need them?
> >> >>
> >> >
> >> > The answer is still the same: the ATH11K inside a WCN6855 does - in
> >> > fact - always need them. The fact that the X13s doesn't define them is
> >> > bad representation of HW and I'm fixing it in a subsequent DTS patch.
> >>
> >> But, like we discussed earlier, M.2 boards don't need these so I think
> >> this should be optional.
> >>
> >
> > If they are truly dynamic, plug-and-play M.2 boards then they
> > shouldn't need any description in device-tree. If they are M.2 sockets
> > that use custom, vendor-specific pins (like what is the case on
> > sc8280xp-crd and X13s) then the HW they carry needs to be described
> > correctly. We've discussed that before.
>
> Sigh. Please reread the previous discussion. In some cases we need to
> set qcom,ath11k-calibration-variant even for M.2 boards.
>
Maybe instead of posting patronizing comments and forcing me to
reiterate all my previous points, you should reread the discussion as
well?
DT describes hardware and the WNC6855 package is composed of several
modules which we represent as separate DT nodes - currently: PMU,
WLAN, Bluetooth. The WLAN module takes inputs from the PMU so it
*DOES* need the supplies. The fact that you only want to specify the
qcom,ath11k-calibration-variant property is irrelevant because the HW
is what it is. Device-tree source is not a configuration file - it's a
description of hardware.
For upstream - if you're using the WCN6855, you must specify the
inputs for the WLAN module so it's only fair they be described as
"required". For out-of-tree DTS I couldn't care less.
You are not correct saying that "M.2 boards don't need these" because
as a matter of fact: the WLAN module on your M.2 card takes these
inputs from the PMU inside the WCN6855 package.
Bartosz
Powered by blists - more mailing lists