From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Kalle Valo <kvalo@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
"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, ath12k@lists.infradead.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Subject: Re: [PATCH v9 1/2] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
Date: Wed, 12 Jun 2024 14:52:23 +0200 [thread overview]
Message-ID: <CAMRc=MdPQu-r4aaeag9apYP1-FoQ2-_GAk_qnHqDz-jWibRDFQ@mail.gmail.com> (raw)
In-Reply-To: <87ikyenx5c.fsf@kernel.org>
On Wed, Jun 12, 2024 at 2:49 PM Kalle Valo <kvalo@kernel.org> wrote:
>
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>
> >> >> Sure, I don't need DT but that's not my point. My point is why require
> >> >> these supplies for _all_ devices having PCI id 17cb:1101 (ie. QCA6390)
> >> >> then clearly there are such devices which don't need it? To me that's
> >> >> bad design and, if I'm understanding correctly, prevents use of
> >> >> qcom,ath11k-calibration-variant property. To me having the supplies
> >> >> optional in DT is more approriate.
> >> >>
> >> >
> >> > We require them because *they are physically there*.
> >>
> >> I understand that for all known DT QCA6390 hardware, the supplies should
> >> be provided thus they should be required. If in the future we have
> >> different design or we represent some pluggable PCI card, then:
> >> 1. Probably that PCI card does not need power sequencing, thus no DT
> >> description,
> >> 2. If still needs power sequencing, you can always amend bindings and
> >> un-require the supplies.
> >>
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >
> > Kalle, does the above answer your questions? Are these bindings good to go?
>
> To me most important is that we are on the same page that in some cases
> (eg. with M.2 boards) the supplies can be optional and we can update the
> bindings doc once such need arises (but we don't make any changes right
> now). Based on point 2 from Krzysztof I think we all agree, right?
>
> Just making sure: if we later change the supplies optional does that
> create any problems with backwards compatibility? It's important that
> updates go smoothly.
No, you can always relax the requirements alright. It's only when you
make them more strict that you'll run into backward compatibility
issues.
Bart
next prev parent reply other threads:[~2024-06-12 12:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 12:21 [PATCH v9 0/2] dt-bindings: describe the ath1X modules on QCom BT/WLAN chipsets Bartosz Golaszewski
2024-06-05 12:21 ` [PATCH v9 1/2] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390 Bartosz Golaszewski
2024-06-06 13:30 ` Kalle Valo
2024-06-06 13:35 ` Bartosz Golaszewski
2024-06-06 14:01 ` Kalle Valo
2024-06-06 14:29 ` Bartosz Golaszewski
2024-06-06 16:16 ` Kalle Valo
2024-06-06 18:08 ` Bartosz Golaszewski
2024-06-07 6:40 ` Krzysztof Kozlowski
2024-06-11 20:05 ` Bartosz Golaszewski
2024-06-12 12:49 ` Kalle Valo
2024-06-12 12:52 ` Bartosz Golaszewski [this message]
2024-06-14 7:18 ` Bartosz Golaszewski
2024-06-17 9:09 ` Kalle Valo
2024-06-12 12:42 ` Kalle Valo
2024-06-17 11:09 ` Kalle Valo
2024-06-24 7:00 ` Krzysztof Kozlowski
2024-06-24 9:15 ` Kalle Valo
2024-06-24 9:26 ` Krzysztof Kozlowski
2024-06-05 12:21 ` [PATCH v9 2/2] dt-bindings: net: wireless: describe the ath12k PCI module Bartosz Golaszewski
2024-06-06 13:34 ` Kalle Valo
2024-06-06 13:37 ` Bartosz Golaszewski
2024-06-06 13:35 ` [PATCH v9 0/2] dt-bindings: describe the ath1X modules on QCom BT/WLAN chipsets Kalle Valo
2024-06-06 18:19 ` Jeff Johnson
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='CAMRc=MdPQu-r4aaeag9apYP1-FoQ2-_GAk_qnHqDz-jWibRDFQ@mail.gmail.com' \
--to=brgl@bgdev.pl \
--cc=ath11k@lists.infradead.org \
--cc=ath12k@lists.infradead.org \
--cc=bartosz.golaszewski@linaro.org \
--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=krzk@kernel.org \
--cc=krzysztof.kozlowski@linaro.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;
as well as URLs for NNTP newsgroup(s).