Re: [PATCH 0/2] wifi: ath: Use static calibration variant table for devicetree platforms

On Mon, Nov 17, 2025 at 09:13:04AM -0800, Jeff Johnson wrote:
> On 11/17/2025 4:45 AM, Manivannan Sadhasivam wrote:
> > On Mon, Nov 17, 2025 at 05:40:06PM +0800, Baochen Qiang wrote:
> >> On 11/17/2025 5:00 PM, Manivannan Sadhasivam wrote:
> >>> On Mon, Nov 17, 2025 at 10:36:39AM +0800, Baochen Qiang wrote:
> >>>> On 11/14/2025 6:22 PM, Manivannan Sadhasivam wrote:
> >>>>> Hi,
> >>>>>
> >>>>> This series aims to deprecate the usage of "qcom,*calibration-variant"
> >>>>> devicetree property to select the calibration variant for the WLAN devices. This
> >>>>> is necessary for WLAN devices connected using PCI bus, as hardcoding the device
> >>>>> specific information in PCI devicetree node causes the node to be updated every
> >>>>> time when a new device variant is attached to the PCI slot. This approach is not
> >>>>> scalable and causes bad user experience.
> >>>>
> >>>> I am not very clear about the problem here: is calibration variant device/module specific,
> >>>> or platform specific? If it is module specific, why the lookup is based on the machine
> >>>> 'model' property? While if it is platform specific, why do we need to update devicetree
> >>>> node whenever a new device is attached?
> >>>>
> >>>
> >>> I think I mixed the usecase of the 'firmware-name' property in the above
> >>> description.
> >>>
> >>> But nevertheless, the calibration info platform specific, and hardcoding the DT
> >>> property fixes the location of the WLAN card with a specific slot. For instance,
> >>> if the board has a couple of M.2 slots, users should be free to plug the WLAN in
> >>> any slot, not just a single slot where the property was defined in DT.
> >>>
> >>> Also, if the users plug-in the WLAN card of another vendor, not Qcom, this
> >>> property is irrelevant/wrong.
> >>>
> >>> PCIe slots should be plug and play i.e., users should plug-in any M.2 card and
> >>> expect it to work.
> >>>
> >>
> >> correct
> >>
> >>> However, as I learned from Jeff, calibration variant property is also going to
> >>> be required in cases like router boards where each slot is dedicated to a fixed
> >>> band and the calibration variant is going to be different for each band for the
> >>> platform. So unlike I thought, this DT property cannot be deprecated. But going
> >>> forward, I'd like it to be used only in these special usecases. Most of the
> >>> upstream DTS have a single calibration variant for the platform and for those
> >>> generic usecases, this static table should be used.
> >>
> >> If that property is not going to be deprecated, should it take precedence?
> >>
> > 
> > If you mean 'it' by this static table, yes, it is going to take precedence as it
> > should cover the generic usecases. For special cases like the multi-band
> > routers, existing DT node fallback will cover.
> Does there need to be a PCI Vendor ID & Device ID as part of this lookup?
> 

I don't think so.

> For example, start with a device that has an ath11k chipset with calibration
> data for that chipset. If the end user replaces that chipset with an ath12k
> chipset then with the current proposal the same calibration variant will
> attempt to be used. But there will not be any calibration data with that
> variant for that chipset.
> 

ath12k doesn't seem to require a calibration variant. But even if the user
replaces ath11k chipset with ath10k one, the calibration variant should be the
same as it is platform specific except for WSI.

- Mani

-- 
மணிவண்ணன் சதாசிவம்