mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Kalle Valo <kvalo@kernel.org>
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 20:19:34 +0200	[thread overview]
Message-ID: <CAMRc=Mfes+=59WP8dcMsiUApqjsFrY9iVFEdKU6FbTKAFP1k_A@mail.gmail.com> (raw)
In-Reply-To: <87y146ayrm.fsf@kernel.org>

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.

Bart

  reply	other threads:[~2024-09-05 18:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-14  8:23 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 [this message]
2024-09-05 18:28         ` Kalle Valo
2024-09-05 21:27           ` Krzysztof Kozlowski
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='CAMRc=Mfes+=59WP8dcMsiUApqjsFrY9iVFEdKU6FbTKAFP1k_A@mail.gmail.com' \
    --to=brgl@bgdev.pl \
    --cc=ath11k@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=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

all inboxes | Powered by JetHome®