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 -- மணிவண்ணன் சதாசிவம்
