[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8e83bd1-89bf-4288-8953-15cdfd9549b5@ti.com>
Date: Wed, 9 Jul 2025 11:21:15 +0530
From: Vignesh Raghavendra <vigneshr@...com>
To: Rob Herring <robh@...nel.org>, Paresh Bhagat <p-bhagat@...com>
CC: <nm@...com>, <praneeth@...com>, <kristo@...nel.org>, <krzk+dt@...nel.org>,
<conor+dt@...nel.org>, <linux-arm-kernel@...ts.infradead.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<khasim@...com>, <v-singh1@...com>, <afd@...com>, <bb@...com>,
<devarsht@...com>, <s-vadapalli@...com>, <andrew@...n.ch>
Subject: Re: [PATCH v7 3/4] arm64: dts: ti: Add pinctrl entries for AM62D2
family of SoCs
Hi Rob,
On 09/07/25 01:52, Rob Herring wrote:
> On Tue, Jul 08, 2025 at 02:28:38PM +0530, Paresh Bhagat wrote:
>> Update k3-pinctrl file to include pin definitions for AM62D2 family of
>> SoCs.
>>
>> Signed-off-by: Paresh Bhagat <p-bhagat@...com>
>> Reviewed-by: Devarsh Thakkar <devarsht@...com>
>> ---
>> arch/arm64/boot/dts/ti/k3-pinctrl.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-pinctrl.h b/arch/arm64/boot/dts/ti/k3-pinctrl.h
>> index cac7cccc1112..0cf57179c974 100644
>> --- a/arch/arm64/boot/dts/ti/k3-pinctrl.h
>> +++ b/arch/arm64/boot/dts/ti/k3-pinctrl.h
>> @@ -63,6 +63,9 @@
>> #define AM62AX_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>> #define AM62AX_MCU_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>>
>> +#define AM62DX_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>> +#define AM62DX_MCU_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>> +
>> #define AM62PX_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>> #define AM62PX_MCU_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>
> Why is the same expression just repeated over and over? Looks like this
> needs some refactoring.
>
Is the comment wrt having another common macro (for better code reuse)
for the right hand side here?
Or is the comment wrt having differently named macros for each SoCs?
Having per SoC macro is intentional so to avoid backward compatibility
issues when these SoC macros deviate in future
--
Regards
Vignesh
https://ti.com/opensource
Powered by blists - more mailing lists