linux-kernel - Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <083e50de-1c99-4a58-8b55-4dec26d97c1b@kernel.org>
Date: Wed, 3 Apr 2024 08:40:19 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Siddharth Vadapalli <s-vadapalli@...com>
Cc: lee@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, srk@...com
Subject: Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse
 compatible

On 03/04/2024 08:32, Siddharth Vadapalli wrote:
> On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
>> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
>>> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
>>>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
>>>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>>>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>>>>>> registers within the System Controller device-tree node. The default MAC
>>>>>>> Address for the interface corresponding to the first MAC port will be set
>>>>>>> to the value programmed in the eFuse.
>>>>>>>
>>>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@...com>
>>>>>>> ---
>>>>>>>
>>>>>>> This patch is based on linux-next tagged next-20240402.
>>>>>>
>>>>>> Where is the DTS using it?
>>>>>
>>>>> The current implementation in the device-tree for older TI K3 SoCs is as
>>>>> follows:
>>>>>
>>>>> 	cpsw_port1: port@1 {
>>>>> 		reg = <1>;
>>>>> 		ti,mac-only;
>>>>> 		label = "port1";
>>>>> 		phys = <&phy_gmii_sel 1>;
>>>>> 		mac-address = [00 00 00 00 00 00];
>>>>> 		ti,syscon-efuse = <&wkup_conf 0x200>;
>>>>> 	};
>>>>>
>>>>> The "ti,syscon-efuse" property passes the reference to the System
>>>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
>>>>> within the CTRL_MMR space.
>>>>
>>>> Please reference upstream DTS or lore link to patch under review.
>>>
>>> An example of the existing implementation in the device-tree for AM64x
>>> is:
>>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
>>> It uses:
>>> 	ti,syscon-efuse = <&main_conf 0x200>;
>>>
>>> and "main_conf" node is defined at:
>>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
>>
>> It is quite different than your bindings, so your bindings are incorrect.
> 
> Sorry I didn't understand what you mean. The references I have provided
> are for existing DTS where "main_conf"/"wkup_conf" (System Controller
> nodes) have the compatible "syscon", unlike in AM62p at:
> https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
> which has the "simple-bus" compatible for the "wkup_conf" node.
> 
> Also, shouldn't the device-tree bindings patches be posted first and get
> merged before I post the device-tree patches that utilize the
> compatible/properties that have been added in the bindings? That is the
> reason why I had shared the "DIFF" for the DTS changes that I will be
> posting once this patch for the new compatible is accepted.
> 

That's not the process. I will be NAKing bindings which do not have any
users, because I do not trust you test them.

The process is almost always:
1. Send bindings,
2. Send driver changes (if applicable) in the same patchset.
3. Send DTS, usually in separate patches and provide lore link to the
bindings in the changelog or cover letter.

Best regards,
Krzysztof