From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1DF4DC369A9 for ; Wed, 25 Sep 2024 07:52:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:CC:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=PQ0co4Ma+pPlFS7bCsPfeWHITDOj9G31dJEWavo3etw=; b=Yd2FgKZuh3JSG24lqge8wt8AEt yTlBtNo9tZ036MkPZsj0QLdthDCRAx677pg+VPzh6OJnGP/YSssG7n5IVJYOAdMlrSG2g42xaANdW OMpzBMos2N2NfPml9SNQQuyxLAkzvAq4Z5shrnQrb2k4YtAKvfPxM41xFg+j6XaWFEpkYw9lDnP8m j+LqJhyvm8w8YMuPGXVgBXwCV4somAAlO27EjoXfw80ShDIPZIk0+jcbbtulziNvzZCGETnZhUvbC t9B+NRsBF8y/LL0c024bw9OgC0DPYkXAlB4QP2yPl+yRdy+fLZPt74MBdB4Z4+AdhnmMoO68fY2yB hdVIGxuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1stMod-00000004OqO-3GoE; Wed, 25 Sep 2024 07:52:03 +0000 Received: from lelv0143.ext.ti.com ([198.47.23.248]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1stMkX-00000004Nq2-1Dcg for linux-arm-kernel@lists.infradead.org; Wed, 25 Sep 2024 07:47:50 +0000 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 48P7leAh061514; Wed, 25 Sep 2024 02:47:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1727250460; bh=PQ0co4Ma+pPlFS7bCsPfeWHITDOj9G31dJEWavo3etw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=H14lax+p2Ua6WxXGAuQ36/mYKeRoJ60KNBXzfyuDDTTBlXg0Y6nINFFF5c/eWY5Es zUKfM8K8sbo3q3QJx/VT409QnN0xW7Dsjr0fa4jb3DeTE6dgEKtQkb74S4P5z5hsl7 qfJI530QHXRTcP2J2zY3fKnU3+RVVQA2o2+cPPtk= Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 48P7leSv093666 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Sep 2024 02:47:40 -0500 Received: from DFLE102.ent.ti.com (10.64.6.23) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 25 Sep 2024 02:47:39 -0500 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Wed, 25 Sep 2024 02:47:39 -0500 Received: from localhost (lcpd911.dhcp.ti.com [172.24.227.226]) by lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 48P7lcAW004872; Wed, 25 Sep 2024 02:47:39 -0500 Date: Wed, 25 Sep 2024 13:17:38 +0530 From: Dhruva Gole To: Nishanth Menon CC: Vignesh Raghavendra , Tero Kristo , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "Rafael J. Wysocki" , Viresh Kumar , , , , , Andrew Davis , Bryan Brattlof , Dhruva Gole Subject: Re: [PATCH v5 0/6] ti: k3-am62{a,p}x-sk: add opp frequencies Message-ID: <20240925074738.a43uwqen4dvbd5mc@lcpd911> References: <20240924-ti-cpufreq-fixes-v5-v5-0-cbe16b9ddb1b@ti.com> <20240924121544.62my7eqnudc76orl@subscribe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20240924121544.62my7eqnudc76orl@subscribe> X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240925_004749_492939_BDFB683A X-CRM114-Status: GOOD ( 30.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sep 24, 2024 at 07:15:44 -0500, Nishanth Menon wrote: > On 15:20-20240924, Dhruva Gole wrote: > [...] > > > > I am sorry that this breaks compatibility with older AM625 devicetree. > > However, the old devicetree was marking the entire wkup_conf as "syscon", > > "simple-mfd" which was wrong and needed to be fixed. > > > > This series finally tries to bring order to DT and the driver. > > > > However, if there is still any way to maintain the backward > > compatibility, then I am open to suggestions. Please try > > and understand here that the ask for backward compatibility here > > is to ask the driver to support a case where the register offset itself > > was to be picked from a different node. I am not sure if there's any > > cleaner way to do this. > > > Have you tried to handle this with quirks? I am not in favor of breaking > backward compatibility. I was thinking of something on those lines, but quirks makes sense for the case that there's a quirky behaviour in the SoC itself. Here it seems to me that we are adding a quirk to handle quirk in some old devicetree. There's no way to detect the devicetree version or somehow distinguish within the driver if it's an old or a new DT. One way I could think of is on these lines: 8<--------------------------------------------------------------------------- diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c index 870ab0b376c1..e1b22c5d4ab8 100644 --- a/drivers/cpufreq/ti-cpufreq.c +++ b/drivers/cpufreq/ti-cpufreq.c @@ -93,6 +93,7 @@ struct ti_cpufreq_soc_data { bool multi_regulator; /* Backward compatibility hack: Might have missing syscon */ #define TI_QUIRK_SYSCON_MAY_BE_MISSING 0x1 +#define TI_QUIRK_SYSCON_MAY_BE_INCORRECT 0x2 u8 quirks; }; @@ -317,6 +318,7 @@ static struct ti_cpufreq_soc_data am625_soc_data = { .efuse_mask = 0x07c0, .efuse_shift = 0x6, .multi_regulator = false, + .quirks = TI_QUIRK_SYSCON_MAY_BE_INCORRECT, }; static struct ti_cpufreq_soc_data am62a7_soc_data = { @@ -349,6 +351,9 @@ static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data, u32 efuse; int ret; + if (opp_data->soc_data->quirks & TI_QUIRK_SYSCON_MAY_BE_INCORRECT ) + opp_data->soc_data->efuse_offset = 0x0018; + ret = regmap_read(opp_data->syscon, opp_data->soc_data->efuse_offset, &efuse); if (opp_data->soc_data->quirks & TI_QUIRK_SYSCON_MAY_BE_MISSING && ret == -EIO) { ---------------------------------------------------------------------------->8 Then, additionally read the soc_data->syscon value, compare it against some hard coded value to check if the address needs the 0x0018 offset or not... All this feels extremely hackish and hence I was against doing this. Am I missing some other obvious way to distinguish between old/new DT? I don't suppose we can just go ahead and create a new binding just for this. -- Best regards, Dhruva Gole Texas Instruments Incorporated