From: Krzysztof Kozlowski <krzk@kernel.org>
To: Kalle Valo <kvalo@kernel.org>, Bartosz Golaszewski <brgl@bgdev.pl>
Cc: "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Jeff Johnson <jjohnson@kernel.org>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, ath11k@lists.infradead.org,
linux-kernel@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH net-next v2] dt-bindings: net: ath11k: document the inputs of the ath11k on WCN6855
Date: Thu, 5 Sep 2024 23:27:30 +0200 [thread overview]
Message-ID: <c6fba73f-7bef-480b-b4c8-fb01cd2286e0@kernel.org> (raw)
In-Reply-To: <878qw6hs4s.fsf@kernel.org>
On 05/09/2024 20:28, Kalle Valo wrote:
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>
>> On Thu, Sep 5, 2024 at 5:47 PM Kalle Valo <kvalo@kernel.org> wrote:
>>>
>>> Bartosz Golaszewski <brgl@bgdev.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.
M.2 cards also have the same power sequencing troubles because of usage
of reserved or custom pins. Whether the properties here are required or
optional, depends not on the board but on the M.2 card. Therefore I
don't understand why you claim it should be optional, just because it is
M.2.
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-09-05 21:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-14 8:23 [PATCH net-next v2] dt-bindings: net: ath11k: document the inputs of the ath11k on WCN6855 Bartosz Golaszewski
2024-08-14 16:25 ` Conor Dooley
2024-08-16 8:26 ` Kalle Valo
2024-08-16 9:10 ` Bartosz Golaszewski
2024-09-02 8:34 ` Bartosz Golaszewski
2024-09-05 15:47 ` Kalle Valo
2024-09-05 18:19 ` Bartosz Golaszewski
2024-09-05 18:28 ` Kalle Valo
2024-09-05 21:27 ` Krzysztof Kozlowski [this message]
2024-09-06 7:44 ` Bartosz Golaszewski
2024-09-06 18:38 ` Jeff Johnson
2024-09-09 8:19 ` Bartosz Golaszewski
2024-09-09 8:39 ` Bartosz Golaszewski
2024-09-19 6:55 ` Krzysztof Kozlowski
2024-09-19 7:48 ` Kalle Valo
2024-09-19 8:59 ` Bartosz Golaszewski
2024-09-20 6:22 ` Kalle Valo
2024-09-20 7:58 ` Bartosz Golaszewski
2024-09-19 10:00 ` Krzysztof Kozlowski
2024-09-20 6:45 ` Kalle Valo
2024-09-20 8:22 ` Bartosz Golaszewski
2024-09-20 21:02 ` Jeff Johnson
2024-09-21 4:56 ` Bartosz Golaszewski
2024-09-24 8:06 ` Krzysztof Kozlowski
2024-09-24 16:46 ` Jeff Johnson
2024-09-24 17:07 ` Bartosz Golaszewski
2024-09-24 8:04 ` Krzysztof Kozlowski
2024-09-25 5:58 ` Kalle Valo
2024-09-25 7:10 ` Krzysztof Kozlowski
2024-09-28 9:22 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c6fba73f-7bef-480b-b4c8-fb01cd2286e0@kernel.org \
--to=krzk@kernel.org \
--cc=ath11k@lists.infradead.org \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=jjohnson@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox