* Re: [PATCH 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 9:40 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <6dc808bf-682f-4e91-aac7-7ce6f05a0ab4@gmail.com>
On 09/04/2024 10:52, Javier Carrasco wrote:
> On 4/9/24 09:34, Krzysztof Kozlowski wrote:
>> On 08/04/2024 17:53, Javier Carrasco wrote:
>>> This RTC requires a compatible, a reg and a single interrupt,
>>> which makes it suitable for a direct conversion into trivial-rtc.
>>>
>>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>>> ---
>>> Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 ---------------
>>> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
>>> 2 files changed, 2 insertions(+), 15 deletions(-)
>>
>> This one no... and if you tested DTS you would see errors, although you
>> need to test specific lpc config, not multi_v7.
>>
>> It does not look like you tested the DTS against bindings. Please run
>> `make dtbs_check W=1` (see
>> Documentation/devicetree/bindings/writing-schema.rst or
>> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
>> for instructions).
>>
>> Anyway, you *must* check all DTS before moving anything to trivial.
>>
>> Does it mean all other bindings were not checked against DTS at all?
>>
>> Best regards,
>> Krzysztof
>>
> Hi,
>
> I did check the conversion against nxp/lpc/lpc3250-phy3250.dts, which
> throws a message about the 'clocks' property.
>
> That property is not documented in the original binding, and even though
> it could be missing, I could not find any function to get a clock (i.e.
Old bindings are not really accurate.
> any form of clk_get()) in rtc-lpc32xx.c, which is the only file where
> the compatible can be found.
>
> Is therefore the property not useless in the dts? My apologies if I am
> missing something here.
Useless for whom? For Linux yes. For U-Boot or out-of-tree users of DTS,
I don't know. Anyway the true question is if there is a clock or there
is no. If there is a clock, then it should be in the binding even if
Linux driver does not use it.
I propose to add it and be done with it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 0/7] Coresight for Kernel panic and watchdog reset
From: James Clark @ 2024-04-09 9:28 UTC (permalink / raw)
To: Linu Cherian
Cc: linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, Sunil Kovvuri Goutham, George Cherian,
suzuki.poulose@arm.com, mike.leach@linaro.org, leo.yan@linaro.org
In-Reply-To: <PH0PR18MB5002D016166F97E665BB0F39CE072@PH0PR18MB5002.namprd18.prod.outlook.com>
On 09/04/2024 01:10, Linu Cherian wrote:
> Hi Suzuki/James,
>
>> -----Original Message-----
>> From: Linu Cherian <lcherian@marvell.com>
>> Sent: Thursday, March 7, 2024 9:06 AM
>> To: suzuki.poulose@arm.com; mike.leach@linaro.org; james.clark@arm.com;
>> leo.yan@linaro.org
>> Cc: linux-arm-kernel@lists.infradead.org; coresight@lists.linaro.org; linux-
>> kernel@vger.kernel.org; robh+dt@kernel.org;
>> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
>> devicetree@vger.kernel.org; Sunil Kovvuri Goutham
>> <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com>; Linu
>> Cherian <lcherian@marvell.com>
>> Subject: [PATCH v7 0/7] Coresight for Kernel panic and watchdog reset
>>
>> This patch series is rebased on v6.8-rc4 from coresisght tree,[1], since latest
>> changes are dependent on coresight_get/set_mode APIs.
>>
>
>
> Do you have any feedback on this version ?
>
> Thanks.
>
Hi Linu,
Sorry it was on my list, I'll take a look this week.
^ permalink raw reply
* RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Peng Fan @ 2024-04-09 9:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DU0PR04MB9417C8C5013C72AB1F61F1C588002@DU0PR04MB9417.eurprd04.prod.outlook.com>
Hi Krzysztof,
> Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > additionalProperties to true
> >
> > On 08/04/2024 08:08, Peng Fan wrote:
> > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > >> additionalProperties to true
> > >>
> > >> On 08/04/2024 01:50, Peng Fan wrote:
> > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > >>>> additionalProperties to true
> > >>>>
> > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > >>>>>> set additionalProperties to true
> > >>>>>>
> > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > >>>>>>>> set additionalProperties to true
> > >>>>>>>>
> > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> > >>>>>>>>>
> > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > >> warning:
> > >>>>>>>>> "
> > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > >>>>>>>>> "
> > >>>>>>>>>
> > >>>>>>>>> Set additionalProperties to true to address the issue.
> > >>>>>>>>
> > >>>>>>>> I do not see anything addressed here, except making the
> > >>>>>>>> binding accepting anything anywhere...
> > >>>>>>>
> > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > >>>>>>> protocol
> > >> extension.
> > >>>>>>>
> > >>>>>>> With additionalProperties set to false, I not know how, please
> > suggest.
> > >>>>>>
> > >>>>>> First of all, you cannot affect negatively existing devices
> > >>>>>> (their
> > >>>>>> bindings) and your patch does exactly that. This should make
> > >>>>>> you thing what is the correct approach...
> > >>>>>>
> > >>>>>> Rob gave you the comment about missing compatible - you still
> > >>>>>> did not address that.
> > >>>>>
> > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > >>>>> =
> > >>>> "arm,scmi";"
> > >>>>
> > >>>> So you claim that your vendor extensions are the same or fully
> > >>>> compatible with arm,scmi and you add nothing... Are your
> > >>>> extensions/protocol valid for arm,scmi?
> > >>>
> > >>> Yes. They are valid for arm,scmi.
> > >>>
> > >>> If yes, why is this in separate binding. If no, why you use
> > >>> someone
> > >>>> else's compatible?
> > >>>
> > >>> Per SCMI Spec
> > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > >>> this interface
> > >>>
> > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > >>> the id for their own protocol.
> > >>
> > >> So how are they valid for arm,scmi? I don't understand.
> > >
> > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > to implement the protocols.
> > >
> > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > implement their own usage, so from firmware level, it is ARM SCMI
> > > spec
> > compatible.
> >
> > That's not the point. It is obvious that your firmware is compatible
> > with arm,scmi, but what you try to say in this and revised patch is
> > that every arm,scmi is compatible with your implementation. What you
> > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > NXP, Samsung, TI, Mediatek etc.
> >
> > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
>
> You are right. I am lost now on how to add vendor ID support, using
> arm,scmi.yaml or adding a new imx,scmi.yaml or else.
Do you have any suggestions on how to add vendor protocol in
dt-schema? I am not sure what to do next, still keep imx,scmi.yaml
or add vendor stuff in arm,scmi.yaml?
Thanks,
Peng.
>
> Please suggest.
>
> Thanks,
> Peng
> >
> > Best regards,
> > Krzysztof
^ permalink raw reply
* RE: [EXT] Re: [PATCH v3] arm64: dts: imx8ulpx`
From: Pankaj Gupta @ 2024-04-09 9:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx, Peng Fan,
Jacky Bai, Bough Chen, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Varun Sethi
In-Reply-To: <e63cd9ec-45f3-4ae7-8d68-e923b35d05f6@linaro.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Tuesday, April 9, 2024 12:57 PM
> To: Pankaj Gupta <pankaj.gupta@nxp.com>; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de;
> festevam@gmail.com; dl-linux-imx <linux-imx@nxp.com>; Peng Fan
> <peng.fan@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Bough Chen
> <haibo.chen@nxp.com>; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: Varun Sethi <V.Sethi@nxp.com>
> Subject: [EXT] Re: [PATCH v3] arm64: dts: imx8ulpx`
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> On 09/04/2024 09:06, Pankaj Gupta wrote:
> > Add crypto node in device tree for:
> > - CAAM job-ring
> >
> > Signed-off-by: Varun Sethi <v.sethi@nxp.com>
> > Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
>
> v3? Where is the changelog? What was happening here?
[Accepted] Added in v4.
>
> > ---
> > arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 32
> ++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > index 8a6596d5a581..946f2b68d16f 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > @@ -252,6 +252,38 @@ pcc3: clock-controller@292d0000 {
> > #reset-cells = <1>;
> > };
> >
> > + crypto: crypto@292e0000 {
> > + compatible = "fsl,sec-v4.0";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0x292e0000 0x10000>;
> > + ranges = <0 0x292e0000 0x10000>;
>
> Keep the order as requested in DTS coding style.
[Accepted] Corrected in v4.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v4] arm64: dts: imx8ulp: add caam jr
From: Pankaj Gupta @ 2024-04-09 9:20 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, peng.fan, ping.bai, haibo.chen,
devicetree, linux-arm-kernel, linux-kernel
Cc: Pankaj Gupta, Varun Sethi
Add crypto node in device tree for:
- CAAM job-ring
Signed-off-by: Varun Sethi <v.sethi@nxp.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
---
v4:
- Order of node properties changed.
v3:
- Commit message title is changed from "imx8ulp-evk" to "imx8ulp".
v2:
- As requested, this patch is separated from the larger patch-set of 9
patches.
Commit
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 8a6596d5a581..ed86854a59c3 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -252,6 +252,38 @@ pcc3: clock-controller@292d0000 {
#reset-cells = <1>;
};
+ crypto: crypto@292e0000 {
+ compatible = "fsl,sec-v4.0";
+ reg = <0x292e0000 0x10000>;
+ ranges = <0 0x292e0000 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
tpm5: tpm@29340000 {
compatible = "fsl,imx8ulp-tpm", "fsl,imx7ulp-tpm";
reg = <0x29340000 0x1000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 8/9] dt-bindings: rtc: stmp3xxx-rtc: convert to dtschema
From: Javier Carrasco @ 2024-04-09 9:22 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <f0467c4f-45e2-4cae-b1b5-3867e5b9bf08@linaro.org>
On 4/9/24 09:40, Krzysztof Kozlowski wrote:
> On 08/04/2024 17:53, Javier Carrasco wrote:
>> Convert existing binding to dtschema to support validation.
>>
>> The 'fsl,imx28-rtc' compatible is currently not supported, and it is
>> only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore,
>> that compatible has been dropped, which triggers a warning when testing
>> the DT against the new binding.
>
> Instead document missing compatibles and mention this in commit msg.
>
There is no driver that will match 'fsl,imx28-rtc', only
'fsl,stmp3xxx-rtc', so I am not sure how to document the missing
compatible in a sensible way. My first suggestion to account for
undocumented strings would be:
compatible:
oneOf:
- items:
- enum:
- fsl,imx23-rtc
- fsl,imx28-rtc
- const: fsl,stmp3xxx-rtc
- const: fsl,stmp3xxx-rtc
Any suggestions or improvements?
>>
>> There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi,
>> where another unsupported compatible 'fsl,imx23-rtc' is used, and the
>> same problem would arise when testing the file against the new binding.
>
> Please write concise messages... you have to paragraphs about the same?
> What is the difference here?
>
The difference is that 'fsl,imx23-rtc' was not even mentioned in any
binding, and it can only be found in imx23.dtsi. 'fsl,imx28-rtc' was
indeed mentioned in the txt binding.
My understanding after your comment is that we should gather
undocumented compatibles and add them to the bindings they would belong
to,no matter if they are used anywhere or not. I added this one to the
suggestion above as well.
>>
>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> ---
>> .../devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml | 45 ++++++++++++++++++++++
>> .../devicetree/bindings/rtc/stmp3xxx-rtc.txt | 21 ----------
>> 2 files changed, 45 insertions(+), 21 deletions(-)
>>
>
>
> Best regards,
> Krzysztof
>
Best regards,
Javier Carrasco
^ permalink raw reply
* [PATCH net-next v2 5/5] ARM: dts: r9a06g032: describe GMAC1
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: Clément Léger <clement.leger@bootlin.com>
The r9a06g032 SoC of the RZ/N1 family features two GMAC devices named
GMAC1/2, that are based on Synopsys cores. GMAC1 is connected to a
RGMII/RMII converter that is already described in this device tree.
Signed-off-by: "Clément Léger" <clement.leger@bootlin.com>
[rgantois: commit log]
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/renesas/r9a06g032.dtsi b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
index fa63e1afc4ef..cab7a641f95b 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
@@ -316,6 +316,25 @@ dma1: dma-controller@40105000 {
data-width = <8>;
};
+ gmac1: ethernet@44000000 {
+ compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac";
+ reg = <0x44000000 0x2000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ clocks = <&sysctrl R9A06G032_HCLK_GMAC0>;
+ clock-names = "stmmaceth";
+ power-domains = <&sysctrl>;
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ tx-fifo-depth = <2048>;
+ rx-fifo-depth = <4096>;
+ pcs-handle = <&mii_conv1>;
+ status = "disabled";
+ };
+
gmac2: ethernet@44002000 {
compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac";
reg = <0x44002000 0x2000>;
--
2.44.0
^ permalink raw reply related
* [PATCH net-next v2 4/5] net: stmmac: add support for RZ/N1 GMAC
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: Clément Léger <clement.leger@bootlin.com>
Add support for the Renesas RZ/N1 GMAC. This support can make use of a
custom RZ/N1 PCS which is fetched by parsing the pcs-handle device tree
property.
Signed-off-by: "Clément Léger" <clement.leger@bootlin.com>
Co-developed-by: Romain Gantois <romain.gantois@bootlin.com>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
MAINTAINERS | 6 ++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 12 ++++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c | 88 ++++++++++++++++++++++++
4 files changed, 107 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4745ea94d463..40bd3eb355fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18848,6 +18848,12 @@ F: include/dt-bindings/net/pcs-rzn1-miic.h
F: include/linux/pcs-rzn1-miic.h
F: net/dsa/tag_rzn1_a5psw.c
+RENESAS RZ/N1 DWMAC GLUE LAYER
+M: Romain Gantois <romain.gantois@bootlin.com>
+S: Maintained
+F: Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
+F: drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c
+
RENESAS RZ/N1 RTC CONTROLLER DRIVER
M: Miquel Raynal <miquel.raynal@bootlin.com>
L: linux-rtc@vger.kernel.org
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 4ec61f1ee71a..05cc07b8f48c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -142,6 +142,18 @@ config DWMAC_ROCKCHIP
This selects the Rockchip RK3288 SoC glue layer support for
the stmmac device driver.
+config DWMAC_RZN1
+ tristate "Renesas RZ/N1 dwmac support"
+ default ARCH_RZN1
+ depends on OF && (ARCH_RZN1 || COMPILE_TEST)
+ select PCS_RZN1_MIIC
+ help
+ Support for Ethernet controller on Renesas RZ/N1 SoC family.
+
+ This selects the Renesas RZ/N1 SoC glue layer support for
+ the stmmac device driver. This support can make use of a custom MII
+ converter PCS device.
+
config DWMAC_SOCFPGA
tristate "SOCFPGA dwmac support"
default ARCH_INTEL_SOCFPGA
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 26cad4344701..c2f0e91f6bf8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_DWMAC_MEDIATEK) += dwmac-mediatek.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
obj-$(CONFIG_DWMAC_QCOM_ETHQOS) += dwmac-qcom-ethqos.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
+obj-$(CONFIG_DWMAC_RZN1) += dwmac-rzn1.o
obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STARFIVE) += dwmac-starfive.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c
new file mode 100644
index 000000000000..e85524c2017c
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2024 Schneider-Electric
+ *
+ * Clément Léger <clement.leger@bootlin.com>
+ */
+
+#include <linux/of.h>
+#include <linux/pcs-rzn1-miic.h>
+#include <linux/phylink.h>
+#include <linux/platform_device.h>
+
+#include "stmmac_platform.h"
+#include "stmmac.h"
+
+static int rzn1_dwmac_pcs_init(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ struct device_node *np = priv->device->of_node;
+ struct device_node *pcs_node;
+ struct phylink_pcs *pcs;
+
+ pcs_node = of_parse_phandle(np, "pcs-handle", 0);
+
+ if (pcs_node) {
+ pcs = miic_create(priv->device, pcs_node);
+ of_node_put(pcs_node);
+ if (IS_ERR(pcs))
+ return PTR_ERR(pcs);
+
+ priv->hw->phylink_pcs = pcs;
+ }
+
+ return 0;
+}
+
+static void rzn1_dwmac_pcs_exit(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ if (priv->hw->phylink_pcs)
+ miic_destroy(priv->hw->phylink_pcs);
+}
+
+static int rzn1_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = devm_stmmac_probe_config_dt(pdev, stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ plat_dat->bsp_priv = plat_dat;
+ plat_dat->pcs_init = rzn1_dwmac_pcs_init;
+ plat_dat->pcs_exit = rzn1_dwmac_pcs_exit;
+
+ ret = stmmac_dvr_probe(dev, plat_dat, &stmmac_res);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static const struct of_device_id rzn1_dwmac_match[] = {
+ { .compatible = "renesas,rzn1-gmac" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rzn1_dwmac_match);
+
+static struct platform_driver rzn1_dwmac_driver = {
+ .probe = rzn1_dwmac_probe,
+ .remove_new = stmmac_pltfr_remove,
+ .driver = {
+ .name = "rzn1-dwmac",
+ .of_match_table = rzn1_dwmac_match,
+ },
+};
+module_platform_driver(rzn1_dwmac_driver);
+
+MODULE_AUTHOR("Clément Léger <clement.leger@bootlin.com>");
+MODULE_DESCRIPTION("Renesas RZN1 DWMAC specific glue layer");
+MODULE_LICENSE("GPL");
--
2.44.0
^ permalink raw reply related
* [PATCH net-next v2 3/5] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel,
Russell King (Oracle), Maxime Chevallier, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Use the newly introduced pcs_init() and pcs_exit() operations to
create and destroy the PCS instance at a more appropriate moment during
the driver lifecycle, thereby avoiding publishing a network device to
userspace that has not yet finished its PCS initialisation.
There are other similar issues with this driver which remain
unaddressed, but these are out of scope for this patch.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 109 +++++++++++----------
1 file changed, 55 insertions(+), 54 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 12b4a80ea3aa..67ca163936c8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -379,6 +379,58 @@ static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
return 0;
}
+static int socfpga_dwmac_pcs_init(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ struct socfpga_dwmac *dwmac = priv->plat->bsp_priv;
+ struct regmap_config pcs_regmap_cfg = {
+ .reg_bits = 16,
+ .val_bits = 16,
+ .reg_shift = regmap_upshift(1),
+ };
+ struct mdio_regmap_config mrc;
+ struct regmap *pcs_regmap;
+ struct phylink_pcs *pcs;
+ struct mii_bus *pcs_bus;
+
+ if (!dwmac->tse_pcs_base)
+ return 0;
+
+ pcs_regmap = devm_regmap_init_mmio(priv->device, dwmac->tse_pcs_base,
+ &pcs_regmap_cfg);
+ if (IS_ERR(pcs_regmap))
+ return PTR_ERR(pcs_regmap);
+
+ memset(&mrc, 0, sizeof(mrc));
+ mrc.regmap = pcs_regmap;
+ mrc.parent = priv->device;
+ mrc.valid_addr = 0x0;
+ mrc.autoscan = false;
+
+ /* Can't use ndev->name here because it will not have been initialised,
+ * and in any case, the user can rename network interfaces at runtime.
+ */
+ snprintf(mrc.name, MII_BUS_ID_SIZE, "%s-pcs-mii",
+ dev_name(priv->device));
+ pcs_bus = devm_mdio_regmap_register(priv->device, &mrc);
+ if (IS_ERR(pcs_bus))
+ return PTR_ERR(pcs_bus);
+
+ pcs = lynx_pcs_create_mdiodev(pcs_bus, 0);
+ if (IS_ERR(pcs))
+ return PTR_ERR(pcs);
+
+ hw->phylink_pcs = pcs;
+ return 0;
+}
+
+static void socfpga_dwmac_pcs_exit(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ if (hw->phylink_pcs)
+ lynx_pcs_destroy(hw->phylink_pcs);
+}
+
static int socfpga_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -426,6 +478,8 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
dwmac->ops = ops;
plat_dat->bsp_priv = dwmac;
plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
+ plat_dat->pcs_init = socfpga_dwmac_pcs_init;
+ plat_dat->pcs_exit = socfpga_dwmac_pcs_exit;
ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
if (ret)
@@ -444,48 +498,6 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
if (ret)
goto err_dvr_remove;
- /* Create a regmap for the PCS so that it can be used by the PCS driver,
- * if we have such a PCS
- */
- if (dwmac->tse_pcs_base) {
- struct regmap_config pcs_regmap_cfg;
- struct mdio_regmap_config mrc;
- struct regmap *pcs_regmap;
- struct mii_bus *pcs_bus;
-
- memset(&pcs_regmap_cfg, 0, sizeof(pcs_regmap_cfg));
- memset(&mrc, 0, sizeof(mrc));
-
- pcs_regmap_cfg.reg_bits = 16;
- pcs_regmap_cfg.val_bits = 16;
- pcs_regmap_cfg.reg_shift = REGMAP_UPSHIFT(1);
-
- pcs_regmap = devm_regmap_init_mmio(&pdev->dev, dwmac->tse_pcs_base,
- &pcs_regmap_cfg);
- if (IS_ERR(pcs_regmap)) {
- ret = PTR_ERR(pcs_regmap);
- goto err_dvr_remove;
- }
-
- mrc.regmap = pcs_regmap;
- mrc.parent = &pdev->dev;
- mrc.valid_addr = 0x0;
- mrc.autoscan = false;
-
- snprintf(mrc.name, MII_BUS_ID_SIZE, "%s-pcs-mii", ndev->name);
- pcs_bus = devm_mdio_regmap_register(&pdev->dev, &mrc);
- if (IS_ERR(pcs_bus)) {
- ret = PTR_ERR(pcs_bus);
- goto err_dvr_remove;
- }
-
- stpriv->hw->phylink_pcs = lynx_pcs_create_mdiodev(pcs_bus, 0);
- if (IS_ERR(stpriv->hw->phylink_pcs)) {
- ret = PTR_ERR(stpriv->hw->phylink_pcs);
- goto err_dvr_remove;
- }
- }
-
return 0;
err_dvr_remove:
@@ -494,17 +506,6 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
return ret;
}
-static void socfpga_dwmac_remove(struct platform_device *pdev)
-{
- struct net_device *ndev = platform_get_drvdata(pdev);
- struct stmmac_priv *priv = netdev_priv(ndev);
- struct phylink_pcs *pcs = priv->hw->phylink_pcs;
-
- stmmac_pltfr_remove(pdev);
-
- lynx_pcs_destroy(pcs);
-}
-
#ifdef CONFIG_PM_SLEEP
static int socfpga_dwmac_resume(struct device *dev)
{
@@ -576,7 +577,7 @@ MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);
static struct platform_driver socfpga_dwmac_driver = {
.probe = socfpga_dwmac_probe,
- .remove_new = socfpga_dwmac_remove,
+ .remove_new = stmmac_pltfr_remove,
.driver = {
.name = "socfpga-dwmac",
.pm = &socfpga_dwmac_pm_ops,
--
2.44.0
^ permalink raw reply related
* [PATCH net-next v2 2/5] net: stmmac: introduce pcs_init/pcs_exit stmmac operations
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel,
Russell King (Oracle), Maxime Chevallier, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Introduce a mechanism whereby platforms can create their PCS instances
prior to the network device being published to userspace, but after
some of the core stmmac initialisation has been completed. This means
that the data structures that platforms need will be available.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 ++++++++++++++
include/linux/stmmac.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fe3498e86de9..25fa33ae7017 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7208,6 +7208,12 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
if (ret)
return ret;
+ if (priv->plat->pcs_init) {
+ ret = priv->plat->pcs_init(priv, priv->hw);
+ if (ret)
+ return ret;
+ }
+
/* Get the HW capability (new GMAC newer than 3.50a) */
priv->hw_cap_support = stmmac_get_hw_features(priv);
if (priv->hw_cap_support) {
@@ -7290,6 +7296,12 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
return 0;
}
+static void stmmac_hw_exit(struct stmmac_priv *priv)
+{
+ if (priv->plat->pcs_exit)
+ priv->plat->pcs_exit(priv, priv->hw);
+}
+
static void stmmac_napi_add(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
@@ -7804,6 +7816,7 @@ int stmmac_dvr_probe(struct device *device,
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
error_mdio_register:
+ stmmac_hw_exit(priv);
stmmac_napi_del(ndev);
error_hw_init:
destroy_workqueue(priv->wq);
@@ -7844,6 +7857,7 @@ void stmmac_dvr_remove(struct device *dev)
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
+ stmmac_hw_exit(priv);
destroy_workqueue(priv->wq);
mutex_destroy(&priv->lock);
bitmap_free(priv->af_xdp_zc_qps);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index dfa1828cd756..941fde506e51 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -285,6 +285,8 @@ struct plat_stmmacenet_data {
int (*crosststamp)(ktime_t *device, struct system_counterval_t *system,
void *ctx);
void (*dump_debug_regs)(void *priv);
+ int (*pcs_init)(struct stmmac_priv *priv, struct mac_device_info *hw);
+ void (*pcs_exit)(struct stmmac_priv *priv, struct mac_device_info *hw);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
--
2.44.0
^ permalink raw reply related
* [PATCH net-next v2 1/5] dt-bindings: net: renesas,rzn1-gmac: Document RZ/N1 GMAC support
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: Clément Léger <clement.leger@bootlin.com>
The RZ/N1 series of MPUs feature up to two Gigabit Ethernet controllers.
These controllers are based on Synopsys IPs. They can be connected to
RZ/N1 RGMII/RMII converters.
Add a binding that describes these GMAC devices.
Signed-off-by: "Clément Léger" <clement.leger@bootlin.com>
[rgantois: commit log]
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
.../devicetree/bindings/net/renesas,rzn1-gmac.yaml | 66 ++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
new file mode 100644
index 000000000000..d9a8d586e260
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/renesas,rzn1-gmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas GMAC
+
+maintainers:
+ - Romain Gantois <romain.gantois@bootlin.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a06g032-gmac
+ - renesas,rzn1-gmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a06g032-gmac
+ - const: renesas,rzn1-gmac
+ - const: snps,dwmac
+
+ pcs-handle:
+ description:
+ phandle pointing to a PCS sub-node compatible with
+ renesas,rzn1-miic.yaml#
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@44000000 {
+ compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac";
+ reg = <0x44000000 0x2000>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ clock-names = "stmmaceth";
+ clocks = <&sysctrl R9A06G032_HCLK_GMAC0>;
+ power-domains = <&sysctrl>;
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ tx-fifo-depth = <2048>;
+ rx-fifo-depth = <4096>;
+ pcs-handle = <&mii_conv1>;
+ phy-mode = "mii";
+ };
+
+...
--
2.44.0
^ permalink raw reply related
* [PATCH net-next v2 0/5] net: stmmac: Add support for RZN1 GMAC devices
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois,
Russell King (Oracle), Maxime Chevallier
Hello everyone,
This is version two of my series that adds support for a Gigabit Ethernet
controller featured in the Renesas r9a06g032 SoC, of the RZ/N1 family. This
GMAC device is based on a Synopsys IP and is compatible with the stmmac driver.
My former colleague Clément Léger originally sent a series for this driver,
but an issue in bringing up the PCS clock had blocked the upstreaming
process. This issue has since been resolved by the following series:
https://lore.kernel.org/all/20240326-rxc_bugfix-v6-0-24a74e5c761f@bootlin.com/
This series consists of a devicetree binding describing the RZN1 GMAC
controller IP, a node for the GMAC1 device in the r9a06g032 SoC device
tree, and the GMAC driver itself which is a glue layer in stmmac.
There are also two patches by Russell that improve pcs initialization handling
in stmmac.
Best Regards,
Romain Gantois
---
Changes in v2:
- Add pcs_init/exit callbacks in stmmac to solve race condition
- Use pcs_init/exit callbacks in dwmac_socfpga glue layer
- Miscellaneous device tree binding corrections
- Link to v1: https://lore.kernel.org/r/20240402-rzn1-gmac1-v1-0-5be2b2894d8c@bootlin.com
---
Clément Léger (3):
dt-bindings: net: renesas,rzn1-gmac: Document RZ/N1 GMAC support
net: stmmac: add support for RZ/N1 GMAC
ARM: dts: r9a06g032: describe GMAC1
Russell King (Oracle) (2):
net: stmmac: introduce pcs_init/pcs_exit stmmac operations
net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
.../devicetree/bindings/net/renesas,rzn1-gmac.yaml | 66 +++++++++++++
MAINTAINERS | 6 ++
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 19 ++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 12 +++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c | 88 +++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 109 +++++++++++----------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 +++
include/linux/stmmac.h | 2 +
9 files changed, 263 insertions(+), 54 deletions(-)
---
base-commit: 87c33315af380ca12a2e59ac94edad4fe0481b4c
change-id: 20240402-rzn1-gmac1-685cf8793d0e
Best regards,
--
Romain Gantois <romain.gantois@bootlin.com>
^ permalink raw reply
* RE: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Peng Fan @ 2024-04-09 9:13 UTC (permalink / raw)
To: Sudeep Holla, Peng Fan (OSS)
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ZhUDZGJilhczKlDD@bogus>
Hi Sudeep,
> Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX
> BBM protocol
>
> On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote:
> > On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > The i.MX BBM protocol is for managing i.MX BBM module which provides
> > > RTC and BUTTON feature.
> > >
> >
> > I appreciate that you added versioning but I think a bit of
> > documentation about what the protocol and its comamnds purpose is
> > still lacking, as asked by Sudeep previously
> >
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flinux-arm-
> kernel%2FZeGtoJ7ztSe8Kg8R%40bogus%2F%23t&data=
> >
> 05%7C02%7Cpeng.fan%40nxp.com%7Ce92ff78b9126447afe9708dc587358d
> 4%7C686e
> >
> a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638482499632395762%7C
> Unknown%7C
> >
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVC
> >
> I6Mn0%3D%7C0%7C%7C%7C&sdata=7QP%2BkkjHA3Sa0CdcbbObGG4kgYYK
> XAGA2r%2F%2F
> > x0MogqU%3D&reserved=0
> >
>
> I have decided to ignore all these vendor protocol patches until they have
> some documentation to understand what these protocol are for, what are the
> commands, their input/output parameter details, any conditions are the
> caller and callee,..etc very similar to SCMI spec.
Where do you expect the documentation to be put?
similar as scmi_protocol.h, put in scmi_imx_protcol.h?
>
> To start with can you please expand what is BBM or MISC protocol is ?
ok. Sorry for missing your previous comment in v1. Let me write here briefly
first.
The Battery Backup (BB) Domain contains the Battery Backed Security
Module (BBSM) and the Battery Backed Non-Secure Module (BBNSM).
BBM protocol is to manage i.MX BBSM and BBNSM. This protocol supports
#define COMMAND_PROTOCOL_VERSION 0x0U
#define COMMAND_PROTOCOL_ATTRIBUTES 0x1U
#define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U
#define COMMAND_BBM_GPR_SET 0x3U
#define COMMAND_BBM_GPR_GET 0x4U
#define COMMAND_BBM_RTC_ATTRIBUTES 0x5U
#define COMMAND_BBM_RTC_TIME_SET 0x6U
#define COMMAND_BBM_RTC_TIME_GET 0x7U
#define COMMAND_BBM_RTC_ALARM_SET 0x8U
#define COMMAND_BBM_BUTTON_GET 0x9U
#define COMMAND_BBM_RTC_NOTIFY 0xAU
#define COMMAND_BBM_BUTTON_NOTIFY 0xBU
#define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U
For now in this patchset for linux, we only use RTC, and BUTTON
for system wakeup
For MISC protocol, it is for various misc things, such as discover
build info, get rom passed data, get reset reason, get i.mx
cfg name, control set(for gpio expander under m33 control and
etc). The command as below:
51 #define COMMAND_PROTOCOL_VERSION 0x0U
52 #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U
53 #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U
54 #define COMMAND_MISC_CONTROL_SET 0x3U
55 #define COMMAND_MISC_CONTROL_GET 0x4U
56 #define COMMAND_MISC_CONTROL_ACTION 0x5U
57 #define COMMAND_MISC_DISCOVER_BUILD_INFO 0x6U
58 #define COMMAND_MISC_ROM_PASSOVER_GET 0x7U
59 #define COMMAND_MISC_CONTROL_NOTIFY 0x8U
60 #define COMMAND_MISC_REASON_ATTRIBUTES 0x9U
61 #define COMMAND_MISC_RESET_REASON 0xAU
62 #define COMMAND_MISC_SI_INFO 0xBU
63 #define COMMAND_MISC_CFG_INFO 0xCU
64 #define COMMAND_MISC_SYSLOG 0xDU
65 #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U
I will add the information in v3.
But as of now I am not sure
how to proceed with dt-binding, add in vendor stuff
in arm,scmi.yaml or add imx,scmi.yaml
Thanks,
Peng.
> Don't expect me to respond if the requested details are still missing in the
> future versions, I am going to ignore it silently.
>
> I have asked for these in atleast 2 different threads may be not just NXP
> patches but in one instance Qcom patches, but they apply equally here.
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Lucas Stach @ 2024-04-09 9:13 UTC (permalink / raw)
To: Vitor Soares, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20240409085802.290439-1-ivitro@gmail.com>
Hi Vitor,
Am Dienstag, dem 09.04.2024 um 09:58 +0100 schrieb Vitor Soares:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The pgc_vpu_* nodes miss the reference to the power domain parent,
> leading the system to hang during the resume.
>
This change is not correct. The vpumix domain is controlled through the
imx8mm-vpu-blk-ctrl and must not be directly triggered by the child
domains in order to guarantee proper power sequencing.
If the sequencing is incorrect for resume, it needs to be fixed in the
blk-ctrl driver. I'll happily assist if you have any questions about
this intricate mix between GPC and blk-ctrl hardware/drivers.
Regards,
Lucas
> As these PU domains are nested inside the vpumix domain, let's reference
> it accordingly. After this change, the suspend/resume is working.
>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: <stable@vger.kernel.org>
> Closes: https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
> Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index 8a1b42b94dce..97d0c6d23ad8 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
> pgc_vpu_g1: power-domain@7 {
> #power-domain-cells = <0>;
> reg = <IMX8MM_POWER_DOMAIN_VPUG1>;
> + power-domains = <&pgc_vpumix>;
> };
>
> pgc_vpu_g2: power-domain@8 {
> #power-domain-cells = <0>;
> reg = <IMX8MM_POWER_DOMAIN_VPUG2>;
> + power-domains = <&pgc_vpumix>;
> };
>
> pgc_vpu_h1: power-domain@9 {
> #power-domain-cells = <0>;
> reg = <IMX8MM_POWER_DOMAIN_VPUH1>;
> + power-domains = <&pgc_vpumix>;
> };
>
> pgc_dispmix: power-domain@10 {
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: imx6: exchange fallback and specific compatible string
From: Shengjiu Wang @ 2024-04-09 8:50 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
In-Reply-To: <1712652644-28887-1-git-send-email-shengjiu.wang@nxp.com>
exchange fallback and specific compatible string for spdif sound card.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 4 ++--
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
index 68e97180d33e..51517e27418c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
@@ -144,8 +144,8 @@ sound-cs42888 {
};
sound-spdif {
- compatible = "fsl,imx-audio-spdif",
- "fsl,imx-sabreauto-spdif";
+ compatible = "fsl,imx-sabreauto-spdif",
+ "fsl,imx-audio-spdif";
model = "imx-spdif";
spdif-controller = <&spdif>;
spdif-in;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
index c6e85e4a0883..67872c16372a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
@@ -184,8 +184,8 @@ panel_in: endpoint {
};
sound-spdif {
- compatible = "fsl,imx-audio-spdif",
- "fsl,imx6sx-sdb-spdif";
+ compatible = "fsl,imx6sx-sdb-spdif",
+ "fsl,imx-audio-spdif";
model = "imx-spdif";
spdif-controller = <&spdif>;
spdif-out;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Shengjiu Wang @ 2024-04-09 8:50 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
In-Reply-To: <1712652644-28887-1-git-send-email-shengjiu.wang@nxp.com>
Convert the imx-audio-spdif binding to YAML.
When testing dtbs_check, found below compatible strings
are not listed in document:
fsl,imx-sabreauto-spdif
fsl,imx6sx-sdb-spdif
So add them in yaml file to pass the test.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
.../bindings/sound/fsl,imx-audio-spdif.yaml | 67 +++++++++++++++++++
.../bindings/sound/imx-audio-spdif.txt | 36 ----------
2 files changed, 67 insertions(+), 36 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
new file mode 100644
index 000000000000..fec008ffae43
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,imx-audio-spdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX audio complex with S/PDIF transceiver
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx-sabreauto-spdif
+ - fsl,imx6sx-sdb-spdif
+ - enum:
+ - fsl,imx-audio-spdif
+ - enum:
+ - fsl,imx-audio-spdif
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ spdif-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the i.MX S/PDIF controller
+
+ spdif-out:
+ type: boolean
+ description:
+ If present, the transmitting function of S/PDIF will be enabled,
+ indicating there's a physical S/PDIF out connector or jack on the
+ board or it's connecting to some other IP block, such as an HDMI
+ encoder or display-controller.
+
+ spdif-in:
+ type: boolean
+ description:
+ If present, the receiving function of S/PDIF will be enabled,
+ indicating there is a physical S/PDIF in connector/jack on the board.
+
+required:
+ - compatible
+ - model
+ - spdif-controller
+
+anyOf:
+ - required:
+ - spdif-in
+ - required:
+ - spdif-out
+
+additionalProperties: false
+
+examples:
+ - |
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-out;
+ spdif-in;
+ };
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
deleted file mode 100644
index da84a442ccea..000000000000
--- a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Freescale i.MX audio complex with S/PDIF transceiver
-
-Required properties:
-
- - compatible : "fsl,imx-audio-spdif"
-
- - model : The user-visible name of this sound complex
-
- - spdif-controller : The phandle of the i.MX S/PDIF controller
-
-
-Optional properties:
-
- - spdif-out : This is a boolean property. If present, the
- transmitting function of S/PDIF will be enabled,
- indicating there's a physical S/PDIF out connector
- or jack on the board or it's connecting to some
- other IP block, such as an HDMI encoder or
- display-controller.
-
- - spdif-in : This is a boolean property. If present, the receiving
- function of S/PDIF will be enabled, indicating there
- is a physical S/PDIF in connector/jack on the board.
-
-* Note: At least one of these two properties should be set in the DT binding.
-
-
-Example:
-
-sound-spdif {
- compatible = "fsl,imx-audio-spdif";
- model = "imx-spdif";
- spdif-controller = <&spdif>;
- spdif-out;
- spdif-in;
-};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/2] convert imx-audio-spdif.txt to YAML
From: Shengjiu Wang @ 2024-04-09 8:50 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
convert imx-audio-spdif.txt to YAML
changes in v3:
- change file name to fsl,imx-audio-spdif.yaml
- change example name back to sound-spdif
- exchange the fallback and specific compatible string
- update anyOf content
changes in v2:
- change file name to imx-spdif.yaml
- remove |
- add anyof for spdif-in and spdif-out requirement
- change example name to sound
Shengjiu Wang (2):
ASoC: dt-bindings: imx-audio-spdif: convert to YAML
ARM: dts: imx6: exchange fallback and specific compatible string
.../bindings/sound/fsl,imx-audio-spdif.yaml | 67 +++++++++++++++++++
.../bindings/sound/imx-audio-spdif.txt | 36 ----------
.../boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 4 +-
4 files changed, 71 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Sudeep Holla @ 2024-04-09 8:59 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Peng Fan, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ZhQxu8LVNKf5QDLm@pluto>
On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote:
> On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The i.MX BBM protocol is for managing i.MX BBM module which provides
> > RTC and BUTTON feature.
> >
>
> I appreciate that you added versioning but I think a bit of documentation
> about what the protocol and its comamnds purpose is still lacking, as asked
> by Sudeep previously
>
> https://lore.kernel.org/linux-arm-kernel/ZeGtoJ7ztSe8Kg8R@bogus/#t
>
I have decided to ignore all these vendor protocol patches until they have
some documentation to understand what these protocol are for, what are
the commands, their input/output parameter details, any conditions are the
caller and callee,..etc very similar to SCMI spec.
To start with can you please expand what is BBM or MISC protocol is ?
Don't expect me to respond if the requested details are still missing in
the future versions, I am going to ignore it silently.
I have asked for these in atleast 2 different threads may be not just NXP
patches but in one instance Qcom patches, but they apply equally here.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Vitor Soares @ 2024-04-09 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
Lucas Stach, stable
From: Vitor Soares <vitor.soares@toradex.com>
The pgc_vpu_* nodes miss the reference to the power domain parent,
leading the system to hang during the resume.
As these PU domains are nested inside the vpumix domain, let's reference
it accordingly. After this change, the suspend/resume is working.
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: <stable@vger.kernel.org>
Closes: https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 8a1b42b94dce..97d0c6d23ad8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
pgc_vpu_g1: power-domain@7 {
#power-domain-cells = <0>;
reg = <IMX8MM_POWER_DOMAIN_VPUG1>;
+ power-domains = <&pgc_vpumix>;
};
pgc_vpu_g2: power-domain@8 {
#power-domain-cells = <0>;
reg = <IMX8MM_POWER_DOMAIN_VPUG2>;
+ power-domains = <&pgc_vpumix>;
};
pgc_vpu_h1: power-domain@9 {
#power-domain-cells = <0>;
reg = <IMX8MM_POWER_DOMAIN_VPUH1>;
+ power-domains = <&pgc_vpumix>;
};
pgc_dispmix: power-domain@10 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-04-09 8:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <dd5e9837-0dcf-4b0e-8d11-f8bed868cdf2@linaro.org>
On 4/9/24 09:34, Krzysztof Kozlowski wrote:
> On 08/04/2024 17:53, Javier Carrasco wrote:
>> This RTC requires a compatible, a reg and a single interrupt,
>> which makes it suitable for a direct conversion into trivial-rtc.
>>
>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> ---
>> Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 ---------------
>> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
>> 2 files changed, 2 insertions(+), 15 deletions(-)
>
> This one no... and if you tested DTS you would see errors, although you
> need to test specific lpc config, not multi_v7.
>
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
>
> Anyway, you *must* check all DTS before moving anything to trivial.
>
> Does it mean all other bindings were not checked against DTS at all?
>
> Best regards,
> Krzysztof
>
Hi,
I did check the conversion against nxp/lpc/lpc3250-phy3250.dts, which
throws a message about the 'clocks' property.
That property is not documented in the original binding, and even though
it could be missing, I could not find any function to get a clock (i.e.
any form of clk_get()) in rtc-lpc32xx.c, which is the only file where
the compatible can be found.
Is therefore the property not useless in the dts? My apologies if I am
missing something here.
Thanks and best regards,
Javier Carrasco
^ permalink raw reply
* Re: [PATCH net-next v6 00/10] Support ICSSG-based Ethernet on AM65x SR1.0 devices
From: patchwork-bot+netdevbpf @ 2024-04-09 8:50 UTC (permalink / raw)
To: Diogo Ivo
Cc: danishanwar, rogerq, davem, edumazet, kuba, pabeni, andrew,
dan.carpenter, jacob.e.keller, robh, robh+dt,
krzysztof.kozlowski+dt, conor+dt, vigneshr, wsa+renesas,
hkallweit1, arnd, vladimir.oltean, linux-arm-kernel, netdev,
devicetree, jan.kiszka
In-Reply-To: <20240403104821.283832-1-diogo.ivo@siemens.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 3 Apr 2024 11:48:10 +0100 you wrote:
> Hello,
>
> This series extends the current ICSSG-based Ethernet driver to support
> AM65x Silicon Revision 1.0 devices.
>
> Notable differences between the Silicon Revisions are that there is
> no TX core in SR1.0 with this being handled by the firmware, requiring
> extra DMA channels to manage communication with the firmware (with the
> firmware being different as well) and in the packet classifier.
>
> [...]
Here is the summary with links:
- [net-next,v6,01/10] dt-bindings: net: Add support for AM65x SR1.0 in ICSSG
https://git.kernel.org/netdev/net-next/c/dc073430db8d
- [net-next,v6,02/10] eth: Move IPv4/IPv6 multicast address bases to their own symbols
https://git.kernel.org/netdev/net-next/c/e1900d7ba9c9
- [net-next,v6,03/10] net: ti: icssg-prueth: Move common functions into a separate file
https://git.kernel.org/netdev/net-next/c/e2dc7bfd677f
- [net-next,v6,04/10] net: ti: icssg-prueth: Add SR1.0-specific configuration bits
https://git.kernel.org/netdev/net-next/c/6d6a5751cd8e
- [net-next,v6,05/10] net: ti: icssg-prueth: Add SR1.0-specific description bits
https://git.kernel.org/netdev/net-next/c/8623dea207a7
- [net-next,v6,06/10] net: ti: icssg-prueth: Adjust IPG configuration for SR1.0
https://git.kernel.org/netdev/net-next/c/95c2e689331e
- [net-next,v6,07/10] net: ti: icssg-prueth: Adjust the number of TX channels for SR1.0
https://git.kernel.org/netdev/net-next/c/604e603d73ec
- [net-next,v6,08/10] net: ti: icssg-prueth: Add functions to configure SR1.0 packet classifier
https://git.kernel.org/netdev/net-next/c/0a74a9de79c1
- [net-next,v6,09/10] net: ti: icssg-prueth: Modify common functions for SR1.0
https://git.kernel.org/netdev/net-next/c/ce95cb4c8d26
- [net-next,v6,10/10] net: ti: icssg-prueth: Add ICSSG Ethernet driver for AM65x SR1.0 platforms
https://git.kernel.org/netdev/net-next/c/e654b85a693e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: arm: qcom: Add msm8916 based Motorola devices
From: Krzysztof Kozlowski @ 2024-04-09 8:29 UTC (permalink / raw)
To: Nikita Travkin, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240405-msm8916-moto-init-v1-1-502b58176d34@trvn.ru>
On 05/04/2024 16:06, Nikita Travkin wrote:
> Add compatible values for the msm8916 based Motorola smartphones.
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Krzysztof Kozlowski @ 2024-04-09 8:27 UTC (permalink / raw)
To: Mike Looijmans, linux-pm
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, Sebastian Reichel,
devicetree, linux-kernel
In-Reply-To: <20240408064905.20298-1-mike.looijmans@topic.nl>
On 08/04/2024 08:49, Mike Looijmans wrote:
> The LTC3350 is a backup power controller that can charge and monitor
> a series stack of one to four supercapacitors.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
> ---
>
> .../bindings/power/supply/ltc3350.yaml | 55 +++++++++++++++++++
Missing vendor prefix, use compatible as filename.
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/ltc3350.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/supply/ltc3350.yaml b/Documentation/devicetree/bindings/power/supply/ltc3350.yaml
> new file mode 100644
> index 000000000000..607a62fd25ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/ltc3350.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (C) 2024 Topic Embedded Products
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/supply/ltc3350.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Linear Technology (Analog Devices) LTC3350 Supercap Charger
> +
> +maintainers:
> + - Mike Looijmans <mike.looijmans@topic.nl>
> +
> +description: |
> + The LTC3350 is a High Current Supercapacitor Backup Controller and System
Just one space after 'a'.
> + Monitor.
> + Specifications about the charger can be found at:
> + https://www.analog.com/en/products/ltc3350.html
> +
> +properties:
> + compatible:
> + enum:
> + - lltc,ltc3350
> +
> + reg:
> + maxItems: 1
> + description: I2C address of the charger.
Drop description, it is obvious.
> +
> + lltc,rsnsc-micro-ohms:
> + description: Capacitor charger sense resistor in microohm.
> + minimum: 1000
> +
> + lltc,rsnsi-micro-ohms:
> + description: Input current sense resistor in microohm.
> + minimum: 1000
Looks like it is shunt-resistor-micro-ohms. Unless it is something
different?
> +
> +required:
> + - compatible
> + - reg
> + - lltc,rsnsc-micro-ohms
> + - lltc,rsnsi-micro-ohms
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + charger: battery-charger@9 {
> + compatible = "lltc,ltc3350";
Messed indentation. Keep it consistent.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] dt-bindings: panel-simple-dsi: add New Khadas TS050 panel bindings
From: Jacobe Zang @ 2024-04-09 8:26 UTC (permalink / raw)
To: neil.armstrong, narmstrong, airlied, daniel, maarten.lankhorst,
mripard, tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt
Cc: quic_jesszhan, sam, nick, thierry.reding, dri-devel, devicetree,
linux-kernel, linux-amlogic, Jacobe Zang
This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel
designed to work with the Khadas VIM3 and VIM3L Single Board Computers.
Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com>
---
.../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
index f9160d7bac3ca..e194309f31b72 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -36,6 +36,8 @@ properties:
- jdi,fhd-r63452
# Khadas TS050 5" 1080x1920 LCD panel
- khadas,ts050
+ # Khadas NEW TS050 5" 1080x1920 LCD panel
+ - khadas,newts050
# Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
- kingdisplay,kd097d04
# LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
--
2.34.1
^ permalink raw reply related
* [PATCH] dt-bindings: host1x: Add missing 'dma-coherent'
From: Jon Hunter @ 2024-04-09 8:23 UTC (permalink / raw)
To: Thierry Reding, Mikko Perttunen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-tegra, devicetree, Jon Hunter
The dtbs_check reports that the 'dma-coherent' property is "unevaluated
and invalid" for the host1x@13e00000 device on Tegra194 and Tegra234
platforms. Fix this by updating the dt-binding document for host1x to
add the 'dma-coherent' property for these devices.
Fixes: 361238cdc525 ("arm64: tegra: Mark host1x as dma-coherent on Tegra194/234")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
.../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
index 94c5242c03b2..3563378a01af 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -177,6 +177,15 @@ allOf:
required:
- reg-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-host1x
+ then:
+ properties:
+ dma-coherent: true
- if:
properties:
compatible:
@@ -226,6 +235,8 @@ allOf:
use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to
usable stream IDs.
+ dma-coherent: true
+
required:
- reg-names
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox