From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 712E333507F for ; Mon, 17 Nov 2025 17:13:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763399592; cv=none; b=b9Omk2yFWaWr38a5dtD5HZ+EmqKz3ieOLMDQhd4O5LgkAIvgqPJOJbhSaJCZWEUvh0dYJocFVFC+h/qn7ySCKdQz9MoaSs27F3RjkEh/oh6wnVPqeHYZnLXQ4NZffZ9sjAUk7sM86SicSBvKIdCn5Cn4xIN3KvempA4e8dSF+NQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763399592; c=relaxed/simple; bh=G6Xd+JXPPWved5fE1RTFaLQkWu3Udn2L7Snmw6lPCQY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ai7BKMxfZYGrghZ294TeB2N6d7nhCMW+iyn+INpW410AA3wZ3HG4Gd/cLHjRsd/poR7GnnzFZSRtjw/nGpf8ZBC8r2gk1p12ytGPAg2PB/FGxcIPYvi+AbFuNosDs8Zs/EqJR5aDlufwoHxUWwqUqtdZhmWnBgO9JfaZnM11gfk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=C7XIowE7; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=I9XGV3n1; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="C7XIowE7"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="I9XGV3n1" Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 5AHAC2MW3571499 for ; Mon, 17 Nov 2025 17:13:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= v/0skEami5ruCiAE/IK+mq+8/OKgh1FsdYkgBHL+f2A=; b=C7XIowE7CqFAg7jL gOVi782I/DXeZEo7tFffIC/G6XYPRfzYKR7s70SEIaSgAAY4yAzjGp7Kky2P1W75 Ssi1FO1zyRM9oj3IoK6uE12gAFX9PXgZ6yd6//+8iEl6K+F7bgCMgOnPAmSZQ33A FZ7KaLXn+CRsI2POf7bn0ROuJYUtsLa+/HXHvEMmuzzzmVe8/uwIlBFgq9xObQPo 45PMGvV4p+hE8GvTGd+uSl183wxiSE7TTLBgEs2EvxVGXkfzhBd7v6DpwL8/o52e IoyvPVK2wWRtxJl1FaB4x7YllpDXNmZwILYVKsLIKmiEBEY9xeDF2FmsBzcuw2XJ 4oz5sQ== Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ag1rbs729-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 17 Nov 2025 17:13:09 +0000 (GMT) Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-7b8ed43cd00so4818055b3a.2 for ; Mon, 17 Nov 2025 09:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1763399589; x=1764004389; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=v/0skEami5ruCiAE/IK+mq+8/OKgh1FsdYkgBHL+f2A=; b=I9XGV3n1TJ5bV6bAvyhsjikM1LcWCL+91Uhi4EScP+1OvqKZ3MoxziY/szl6zi1fDx xdl+ummne5LdeEY1P9jTJa/vFjY7VXBh+WpbSykY8pHyHSs46UYgO83X+GdtzDToXlBw Pozi/Cwvh2h7Mhuxwic4lVLRHrSoyuIV0+P6OkYsP2jb8XWYvBtLzRI5Ix3vpA6bAtu7 JTt+1N4kGm75F7paxuTc+2LfNxfoxjf3EVFCErz1yJkB+mIPdht08rVeRf2++gIB7FSE aOo/lnGPw83aTwQLYu+OFjWe8qSD+y6xUKtxAK6vCn91v4xqzaDjW46z8qKIkVaL+MHO NoVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763399589; x=1764004389; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=v/0skEami5ruCiAE/IK+mq+8/OKgh1FsdYkgBHL+f2A=; b=WC/GPxAPzhjHJrUWNc4YnzShhm5TijYYbFrxMVQQdGVb8wIK98K8ElfQK7LgL2rDG7 c3XuF0SD9mPC9IjpI6C3Lr8febhUBXj2xOFUqby/lZgcjhFZf0KJ0WhVA8M2pAdwEeu5 etb5AsNOnzZrTy0sRGhtHO+FAoajjqxoZZnds8JY7GYWi0fTQQxPFSZeyjTqME0VckQ/ ULIq2t6AnLNHZxOpEI21EigTnTXu5nGSC61zUaGyzkJCIE7BtoSYlObl4mwMay5R9bAw lOrVL7iO5DBVVs77J2r1TWcnHrz/kYEe8sJRwgtNXc6kgHjASPLnn2lDy7BEzHD5cvNM M24Q== X-Forwarded-Encrypted: i=1; AJvYcCVTdYuNsjj733+SEOyY8X7qNVCS+sD4e59eYeuz6zD3g9/m+yStdsvX74IrOh5N6ab2SlG8ChX50ivu4B8=@vger.kernel.org X-Gm-Message-State: AOJu0YxUvCXykLo5UUruv1eSQJfIYKKjo821h8qPARt+Tpt7T0IHvOCi eE+9LfOM6uYFIHoWOXrI5jg70hRaECfJ/27jgnwPbf1UpvwQ23h1eMbMlO76LyRmeY+YX4W4ps8 VL1SEHZaJpe2y1He7EwrjzuoCTwrCh3Q6efUw+a0Zmk4alB1pxTSxUyRhco4mbaw48y0= X-Gm-Gg: ASbGncvKsJsiDA1LxSmIct/0lDLbvZ82aFk0v7HNvolCeN5O5k8WL2PlPxmemGo3Zra jOMSouQUFQ9wazeV088FgjY1E4ZKOQR1C3a09G0ZsqlwFRPjfnyd9W/iJdd/5HsMzpcbK0Ps9cM 7SEBEQBvPvfD3BFBseECFz7f3UY9qIH0b9cRbKXOraoEIcoDgXfPe6WwYZTQVqLQ5Ihc76rQAYu afmyPZdSVXtr6piaT8HjUbCri5aDjcCsRD+6XSknAsvfufdyW4CPtN9OWgdzYVJDO6W+7sD4yRj BlmzYyI2zwUVZRL7aTQ2t9iJbgEN+IkxKYSM1VDhiyGl6T7H4egcmj6Ad77GjurcwxebSNKi/3I UxGtc303IPChZOZ0rQNaWLp9DuJorCv3DgE1x1pvhabgZPT/Y9GCnrCHNpqdVCGOdJlroEImtqp nW X-Received: by 2002:aa7:8885:0:b0:7b9:d2ad:bebf with SMTP id d2e1a72fcca58-7ba3c478736mr14829460b3a.22.1763399588623; Mon, 17 Nov 2025 09:13:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IGXwUwPLWo7AJoocw7BW6CSXi/Qe1/n+JtC2PtqJDxbVtQW440K/74J4a2w0JSqqv+hvkmGBQ== X-Received: by 2002:aa7:8885:0:b0:7b9:d2ad:bebf with SMTP id d2e1a72fcca58-7ba3c478736mr14829425b3a.22.1763399588141; Mon, 17 Nov 2025 09:13:08 -0800 (PST) Received: from [192.168.1.3] (c-24-130-122-79.hsd1.ca.comcast.net. [24.130.122.79]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7b9250d332asm13915017b3a.25.2025.11.17.09.13.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Nov 2025 09:13:05 -0800 (PST) Message-ID: Date: Mon, 17 Nov 2025 09:13:04 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] wifi: ath: Use static calibration variant table for devicetree platforms To: Manivannan Sadhasivam , Baochen Qiang Cc: Jeff Johnson , Johannes Berg , Rob Herring , Krzysztof Kozlowski , Conor Dooley , 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 References: <20251114-ath-variant-tbl-v1-0-a9adfc49e3f3@oss.qualcomm.com> <2fd84ab2-2e3e-4d05-add5-17930a35fedf@oss.qualcomm.com> From: Jeff Johnson Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: LSi7E-T1gDw9JT8U9EPeoKLxFE3Z7srl X-Proofpoint-ORIG-GUID: LSi7E-T1gDw9JT8U9EPeoKLxFE3Z7srl X-Authority-Analysis: v=2.4 cv=FPAWBuos c=1 sm=1 tr=0 ts=691b57a5 cx=c_pps a=m5Vt/hrsBiPMCU0y4gIsQw==:117 a=Tg7Z00WN3eLgNEO9NLUKUQ==:17 a=IkcTkHD0fZMA:10 a=6UeiqGixMTsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=prETkiTXWOWpwK33hF0A:9 a=QEXdDO2ut3YA:10 a=IoOABgeZipijB_acs4fv:22 a=HhbK4dLum7pmb74im6QT:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMTE3MDE0NiBTYWx0ZWRfX5Xu/B2qvzrFF GwbdG5WiuIeQrnGa8dXwpKJCta8bfN0jY0ENC/fXq2nawHCz+LhuBFSz8Rcgbvl4wRGJRtyOfKW KIa46BjjT+zOjIiLnSLq+TXUaKxJWT4UnA/KjgTblwq5I05GOiB93ZlgYrUONWOL8Tx5Xv/T3ts CrfK7sPdS7i8kqwcNDKd6a7cwHlnn/FADQzzcbF+DcWXPjHA/0UEkP1RNW0/ZsDR3cwq44xpOAY PCde54gQPrldF6WIz/iU5Zk3d4uEGKuazgEMz+Kt3eDJKo2Wnsv4dyalj6kgN4oVwkzc+Tkw5oF eym9/ASJ67lhuVjKmy4SVvkrMbTDMuu33/zCS+8jSNE4gcsz2Hhl/vcUzc7H30O1Iy0R/mnWMsl NyKw5jZ6tr45L7InIB2QIrXkIjyZLw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-11-17_03,2025-11-13_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2510240001 definitions=main-2511170146 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