| Message ID | 20240402105708.4114146-1-s-vadapalli@ti.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible | expand |
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@ti.com> > --- > > This patch is based on linux-next tagged next-20240402. Where is the DTS using it? Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
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@ti.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. This implementation works only when the System Controller node (wkup_conf or its equivalent depending on the SoC) has the compatible "syscon". From AM62p SoC onwards, it was decided that the System Controller nodes have to be modelled as a "simple-bus", due to which the "syscon" based regmapping within the driver that uses the "ti,syscon-efuse" property will no longer work directly. Therefore, with this patch, the upcoming device-tree changes for AM62p will be: 1) Update in the System Controller node to use the newly added compatible for mapping the CTRLMMR_MAC_IDx registers: wkup_conf: bus@43000000 { compatible = "simple-bus"; reg = <0x00 0x43000000 0x00 0x20000>; #address-cells = <1>; #size-cells = <1>; ranges = <0x00 0x00 0x43000000 0x20000>; bootph-all; chipid: chipid@14 { reg = <0x14 0x4>; bootph-all; }; + + cpsw_mac_efuse: cpsw-mac-efuse@200 { + compatible = "ti,am62p-cpsw-mac-efuse", "syscon"; + reg = <0x200 0x8>; + }; }; 2) Update within the cpsw_port1 node for passing the "cpsw_mac_efuse" node: 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 = <&cpsw_mac_efuse 0x0>; }; > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Thank you for reviewing and acking this patch. Regards, Siddharth.
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@ti.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. Best regards, Krzysztof
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@ti.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 Regards, Siddharth.
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@ti.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. Please fix them and send when your DTS is ready. Best regards, Krzysztof
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@ti.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. Regards, Siddharth.
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@ti.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
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@ti.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.
On Wed, Apr 03, 2024 at 12:18:10PM +0530, Siddharth Vadapalli wrote: > 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@ti.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. I have posted the DTS patch at: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404081845.622707-1-s-vadapalli@ti.com/ indicating the dependency on this bindings patch. Regards, Siddharth.
On Thu, Apr 04, 2024 at 02:02:21PM +0530, Siddharth Vadapalli wrote: > On Wed, Apr 03, 2024 at 12:18:10PM +0530, Siddharth Vadapalli wrote: > > 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@ti.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. > > I have posted the DTS patch at: > https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404081845.622707-1-s-vadapalli@ti.com/ > indicating the dependency on this bindings patch. Hello Krzysztof, Do I have to post a v2 for this patch? You had Acked it initially but I am not sure if the discussion so far will make it unclear to readers regarding the acceptance of this patch. Thank you for Acking the v3 DTS patch at: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404124614.891416-1-s-vadapalli@ti.com/ Since the v3 DTS patch mentions this bindings patch as a dependency, I wanted to be sure whether I have to post a v2 for this or that won't be required. Regards, Siddharth.
On 05/04/2024 07:21, Siddharth Vadapalli wrote: >>>> 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. >> >> I have posted the DTS patch at: >> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404081845.622707-1-s-vadapalli@ti.com/ >> indicating the dependency on this bindings patch. > > Hello Krzysztof, > > Do I have to post a v2 for this patch? You had Acked it initially but I No, I acked it. All this unnecessary talk was because you did not post a user, but it is not a requirement, at least when we expect such user. Best regards, Krzysztof
On Fri, Apr 05, 2024 at 08:55:18AM +0200, Krzysztof Kozlowski wrote: > On 05/04/2024 07:21, Siddharth Vadapalli wrote: > >>>> 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. > >> > >> I have posted the DTS patch at: > >> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404081845.622707-1-s-vadapalli@ti.com/ > >> indicating the dependency on this bindings patch. > > > > Hello Krzysztof, > > > > Do I have to post a v2 for this patch? You had Acked it initially but I > > No, I acked it. All this unnecessary talk was because you did not post a > user, but it is not a requirement, at least when we expect such user. Lee, Could you please merge this patch? It applies cleanly on the latest linux-next tagged next-20240424. Regards, Siddharth.
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 9d55bee155ce..4936ac0b5936 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -73,6 +73,7 @@ properties: - rockchip,rv1126-qos - starfive,jh7100-sysmain - ti,am62-usb-phy-ctrl + - ti,am62p-cpsw-mac-efuse - ti,am654-dss-oldi-io-ctrl - ti,am654-serdes-ctrl - ti,j784s4-pcie-ctrl
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@ti.com> --- This patch is based on linux-next tagged next-20240402. Regards, Siddharth. Documentation/devicetree/bindings/mfd/syscon.yaml | 1 + 1 file changed, 1 insertion(+)