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?
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. /jeff
