From: Kalle Valo <kvalo@kernel.org>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
"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>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH net-next v2] dt-bindings: net: ath11k: document the inputs of the ath11k on WCN6855
Date: Fri, 20 Sep 2024 09:45:56 +0300 [thread overview]
Message-ID: <87a5g2bz6j.fsf@kernel.org> (raw)
In-Reply-To: <ed6aceb6-4954-43ad-b631-6c6fda209411@kernel.org> (Krzysztof Kozlowski's message of "Thu, 19 Sep 2024 12:00:53 +0200")
Krzysztof Kozlowski <krzk@kernel.org> writes:
> On 19/09/2024 09:48, Kalle Valo wrote:
>> Krzysztof Kozlowski <krzk@kernel.org> writes:
>>
>>> On 14/08/2024 10:23, Bartosz Golaszewski wrote:
>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>
>>>> Describe the inputs from the PMU of the ath11k module on WCN6855.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>> ---
>>>> v1 -> v2:
>>>> - update the example
>>>
>>> I don't understand why this patch is no being picked up. The code
>>> correct represents the piece of hardware. The supplies should be
>>> required, because this one particular device - the one described in this
>>> binding - cannot work without them.
>>
>> I have already explained the situation. With supplies changed to
>> optional I'm happy take the patch.
>
> You did not provide any relevant argument to this case. Your concerns
> described quite different case and are no applicable to DT based platforms.
Ok, I'll try to explain my concerns one more time. I'll try to be
thorough so will be a longer mail.
In ath11k we have board files, it's basically board/product specific
calibration data which is combined with the calibration data from chip's
OTP. Choosing the correct board file is essential as otherwise the
performance can be bad or the device doesn't work at all.
The board files are stored in board-2.bin file in /lib/firmware. ath11k
chooses the correct board file based on the information provided by the
ath11k firmware and then transfers the board file to firmware. From
board-2.bin the correct board file is search based on strings like this:
bus=pci,vendor=17cb,device=1103,subsystem-vendor=105b,subsystem-device=e0ca,qmi-chip-id=2,qmi-board-id=255
bus=pci,vendor=17cb,device=1103,subsystem-vendor=105b,subsystem-device=e0ca,qmi-chip-id=2,qmi-board-id=255,variant=HO_BNM
But the firmware does not always provide unique enough information for
choosing the correct board file and that's why we added the variant
property (the second example above). This variant property gives us the
means to name the board files uniquely and not have any conflicts. In
x86 systems we retrieve it from SMBIOS and in DT systems using
qcom,ath11k-calibration-variant property.
If WCN6855 supplies are marked as required, it means that we cannot use
qcom,ath11k-calibration-variant DT property anymore with WCN6855 M.2
boards. So if we have devices which don't provide unique information
then for those devices it's impossible to automatically to choose the
correct board file.
So based on this, to me the correct solution here is to make the
supplies optional so that qcom,ath11k-calibration-variant DT property
can continue to be used with WCN6855 M.2 boards.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-09-20 6:46 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
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 [this message]
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=87a5g2bz6j.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=arnd@arndb.de \
--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=krzk@kernel.org \
--cc=kuba@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).