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: <9bca7d94-142e-4717-aea7-437805717a00@ti.com>
Date: Wed, 3 Apr 2024 12:18:10 +0530
From: Siddharth Vadapalli <s-vadapalli@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: Siddharth Vadapalli <s-vadapalli@...com>, <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 Wed, Apr 03, 2024 at 08:40:19AM +0200, Krzysztof Kozlowski wrote:
> 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.

Thank you for clarifying. I will post the DTS patches corresponding to
this patch and reference this patch in the DTS patch series.

Regards,
Siddharth.