public inbox for ath12k@lists.infradead.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Cc: Jeff Johnson <jjohnson@kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	ath10k@lists.infradead.org, ath11k@lists.infradead.org,
	devicetree@vger.kernel.org, ath12k@lists.infradead.org,
	Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Subject: Re: [PATCH 2/2] dt-bindings: wireless: ath: Deprecate 'qcom,calibration-variant' property
Date: Fri, 14 Nov 2025 12:04:55 +0100	[thread overview]
Message-ID: <1703d8d7-5105-4585-b8f0-82bb54809718@kernel.org> (raw)
In-Reply-To: <fmumja63j3xvbvfxlmtnkfubgw4jwo5f43srrpfgqrxyqknrj4@izsqazgbiehp>

On 14/11/2025 12:02, Manivannan Sadhasivam wrote:
> On Fri, Nov 14, 2025 at 11:47:25AM +0100, Krzysztof Kozlowski wrote:
>> On 14/11/2025 11:22, Manivannan Sadhasivam wrote:
>>> On devicetree platforms, ath{10k/11k} drivers rely on the presence of the
>>> 'qcom,calibration-variant' property to select the correct calibration data
>>> for device variants with colliding IDs.
>>>
>>> But this property based selection has its own downside that it needs to be
>>> added to the devicetree node of the WLAN device, especially for PCI based
>>> devices. Currently, the users/vendors are forced to hardcode this property
>>> in the PCI device node. If a different device need to be attached to the
>>> slot, then the devicetree node also has to be changed. This approach is not
>>> scalable and creates a bad user experience.
>>>
>>> So deprecate this property from WLAN devicetree nodes and let the drivers
>>> do the devicetree model based calibration variant lookup using a static
>>> table.
>>>
>>> This also warrants removing the property from examples in the binding.
>>>
>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>>> ---
>>
>> The problem - visible in one of the examples here - is that one board
>> has multiple WiFi chips and they use different calibration-variant
>> properties. How do you find the right calibration variant for such case
>> based on board machine match?
>>
> 
> I suspect the legitimacy of the example here. I don't understand how a single
> machine can have same devices with 3 different calibration data.

Me neither but I am not the domain expert here.

> 
> AFAIU, calibration data is specific to the platform design. And I don't see any
> upstream supported devicetree having similar properties.
Deprecating these is fine with me, but I would prefer if we get here
some clear answers that mentioned case cannot happen. If you are sure of
that, please mention it in commit msg.


Best regards,
Krzysztof


  reply	other threads:[~2025-11-14 11:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14 10:22 [PATCH 0/2] wifi: ath: Use static calibration variant table for devicetree platforms Manivannan Sadhasivam
2025-11-14 10:22 ` [PATCH 1/2] " Manivannan Sadhasivam
2025-11-14 10:45   ` Krzysztof Kozlowski
2025-11-14 11:16     ` Manivannan Sadhasivam
2025-11-14 11:24       ` Krzysztof Kozlowski
2025-11-14 11:44         ` Srinivas Kandagatla
2025-11-14 11:48           ` Krzysztof Kozlowski
2025-11-15  9:51   ` kernel test robot
2025-11-14 10:22 ` [PATCH 2/2] dt-bindings: wireless: ath: Deprecate 'qcom,calibration-variant' property Manivannan Sadhasivam
2025-11-14 10:47   ` Krzysztof Kozlowski
2025-11-14 11:02     ` Manivannan Sadhasivam
2025-11-14 11:04       ` Krzysztof Kozlowski [this message]
2025-11-14 11:18         ` Manivannan Sadhasivam
2025-11-14 17:29           ` Jeff Johnson
2025-11-17  9:03             ` Manivannan Sadhasivam
2025-11-17  2:36 ` [PATCH 0/2] wifi: ath: Use static calibration variant table for devicetree platforms Baochen Qiang
2025-11-17  9:00   ` Manivannan Sadhasivam
2025-11-17  9:40     ` Baochen Qiang
2025-11-17 12:45       ` Manivannan Sadhasivam
2025-11-17 17:13         ` Jeff Johnson
2025-11-18  6:53           ` Manivannan Sadhasivam
2025-11-25  9:57             ` Ernest Van Hoecke
2026-04-08  6:06               ` Baochen Qiang
2026-04-13  9:32                 ` Ernest Van Hoecke

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=1703d8d7-5105-4585-b8f0-82bb54809718@kernel.org \
    --to=krzk@kernel.org \
    --cc=ath10k@lists.infradead.org \
    --cc=ath11k@lists.infradead.org \
    --cc=ath12k@lists.infradead.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jjohnson@kernel.org \
    --cc=johannes@sipsolutions.net \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=manivannan.sadhasivam@oss.qualcomm.com \
    --cc=miaoqing.pan@oss.qualcomm.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