* [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
* [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 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
* 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
* 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
* [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
* [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 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 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 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 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
* 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 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: [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
* 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: [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 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 8/9] dt-bindings: rtc: stmp3xxx-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-04-09 9:42 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
In-Reply-To: <89e7db2d-1de0-4e2e-a2d2-f00d45399b11@gmail.com>
On 09/04/2024 11:22, Javier Carrasco wrote:
> 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
I don't understand what driver matching to it has anything to do with
the problem discussed here.
You have DTS, so you can see how it should be written.
> 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.
Bindings are not correct. Many times.
>
> 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.
What do you mean "unused"? If these you call unused, then shall we
remove 90% of such "unused" compatibles from the binding? No. See
writing bindings or hundreds of other bindings as examples. You need
specific part.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: qcom: Add device tree for Motorola Moto G4 Play (harpia)
From: Konrad Dybcio @ 2024-04-09 9:45 UTC (permalink / raw)
To: Nikita Travkin, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ruby Iris Juric,
Stephan Gerhold
In-Reply-To: <20240405-msm8916-moto-init-v1-2-502b58176d34@trvn.ru>
On 4/5/24 16:06, Nikita Travkin wrote:
> From: Ruby Iris Juric <ruby@srxl.me>
>
> Motorola Moto G4 Play is an msm8916 based smartphone.
>
> Supported features:
>
> - eMMC and SD;
> - Buttons;
> - Touchscreen;
> - USB;
> - Fuel Gauge;
> - Sound;
> - Accelerometer.
>
> msm8916 Moto devices share significant portion of the design so the
> common parts are separated into a common dtsi.
>
> Signed-off-by: Ruby Iris Juric <ruby@srxl.me>
> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> [Nikita: Split up to common dtsi]
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Krzysztof Kozlowski @ 2024-04-09 9:45 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_anusha, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <ZhTxFVDH0xTSkw7r@hu-varada-blr.qualcomm.com>
On 09/04/2024 09:41, Varadarajan Narayanan wrote:
> On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote:
>> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote:
>>> On 03/04/2024 12:42, Varadarajan Narayanan wrote:
>>>> Add interconnect-cells to clock provider so that it can be
>>>> used as icc provider.
>>>>
>>>> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
>>>> interfaces. This will be used by the gcc-ipq9574 driver
>>>> that will for providing interconnect services using the
>>>> icc-clk framework.
>>>>
>>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>>> ---
>>>> v7:
>>>> Fix macro names to be consistent with other bindings
>>>> v6:
>>>> Removed Reviewed-by: Krzysztof Kozlowski
>>>> Redefine the bindings such that driver and DT can share them
>>>>
>>>> v3:
>>>> Squash Documentation/ and include/ changes into same patch
>>>>
>>>> qcom,ipq9574.h
>>>> Move 'first id' to clock driver
>>>>
>>>> ---
>>>> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
>>>> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
>>>> 2 files changed, 90 insertions(+)
>>>> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
>>>> index 944a0ea79cd6..824781cbdf34 100644
>>>> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
>>>> @@ -33,6 +33,9 @@ properties:
>>>> - description: PCIE30 PHY3 pipe clock source
>>>> - description: USB3 PHY pipe clock source
>>>>
>>>> + '#interconnect-cells':
>>>> + const: 1
>>>> +
>>>> required:
>>>> - compatible
>>>> - clocks
>>>> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h
>>>> new file mode 100644
>>>> index 000000000000..0b076b0cf880
>>>> --- /dev/null
>>>> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
>>>> @@ -0,0 +1,87 @@
>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>>>> +#ifndef INTERCONNECT_QCOM_IPQ9574_H
>>>> +#define INTERCONNECT_QCOM_IPQ9574_H
>>>> +
>>>> +#define ICC_ANOC_PCIE0 0
>>>> +#define ICC_SNOC_PCIE0 1
>>>> +#define ICC_ANOC_PCIE1 2
>>>> +#define ICC_SNOC_PCIE1 3
>>>> +#define ICC_ANOC_PCIE2 4
>>>> +#define ICC_SNOC_PCIE2 5
>>>> +#define ICC_ANOC_PCIE3 6
>>>> +#define ICC_SNOC_PCIE3 7
>>>> +#define ICC_SNOC_USB 8
>>>> +#define ICC_ANOC_USB_AXI 9
>>>> +#define ICC_NSSNOC_NSSCC 10
>>>> +#define ICC_NSSNOC_SNOC_0 11
>>>> +#define ICC_NSSNOC_SNOC_1 12
>>>> +#define ICC_NSSNOC_PCNOC_1 13
>>>> +#define ICC_NSSNOC_QOSGEN_REF 14
>>>> +#define ICC_NSSNOC_TIMEOUT_REF 15
>>>> +#define ICC_NSSNOC_XO_DCD 16
>>>> +#define ICC_NSSNOC_ATB 17
>>>> +#define ICC_MEM_NOC_NSSNOC 18
>>>> +#define ICC_NSSNOC_MEMNOC 19
>>>> +#define ICC_NSSNOC_MEM_NOC_1 20
>>>> +
>>>> +#define ICC_NSSNOC_PPE 0
>>>> +#define ICC_NSSNOC_PPE_CFG 1
>>>> +#define ICC_NSSNOC_NSS_CSR 2
>>>> +#define ICC_NSSNOC_IMEM_QSB 3
>>>> +#define ICC_NSSNOC_IMEM_AHB 4
>>>> +
>>>> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2)
>>>> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1)
>>>
>>> Which existing Qualcomm platform has such code?
>>
>> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm
>> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk.
>>
>> The icc_clk_register automatically creates master & slave nodes
>> for each clk entry provided as input with the node-ids 'n' and
>> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just
>> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these
>> calculations.
>>
>> However, ipq9574 gives an array of clock entries as input to
>> icc_clk_register. To tie the order/sequence of these clock
>> entries correctly with the node-ids, this calculation is needed.
>>
>>> This is the third time I am asking for consistent headers. Open
>>> existing, recently added headers and look how it is done there. Why?
>>> Because I am against such calculations and see no reason for them.
>>
>> Apologies. Regret that I have to trouble you.
>>
>> In this ipq9574 case, have to reconcile between the following
>> feedbacks.
>>
>> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/
>> We could probably use indexed identifiers here to avoid confusion:
>> [ICC_BINDING_NAME] = CLK_BINDING_NAME
>>
>> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/
>> Are these supposed to be in a dt-binding header?
>>
>> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/
>> Do you use them as well in the DTS?
>>
>> Having the defines (with the calculations) seemed to to comply
>> with the above three feedbacks.
>>
>> Please let me know if this can be handled in a different way that
>> would be consistent with other Qualcomm platforms.
>
> Krzysztof,
>
> Is this ok? Can I post a new version addressing other review comments?
I don't understand and you did not answered before, why you have to do
it differently than all other Qualcomm interconnect providers. Maybe the
code here needs it, maybe not, but I don't see any argument proving this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: Add Motorola Moto E 2015 LTE (surnia)
From: Konrad Dybcio @ 2024-04-09 9:46 UTC (permalink / raw)
To: Nikita Travkin, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Wiktor Strzębała, Valérie Roux, Stephan Gerhold
In-Reply-To: <20240405-msm8916-moto-init-v1-3-502b58176d34@trvn.ru>
On 4/5/24 16:06, Nikita Travkin wrote:
> From: Wiktor Strzębała <wiktorek140@gmail.com>
>
> Motorola Moto E 2015 LTE is an msm8916 based smartphone.
>
> Supported features:
>
> - eMMC and SD;
> - Buttons;
> - Touchscreen;
> - USB;
> - Fuel Gauge;
> - Sound.
>
> Signed-off-by: Wiktor Strzębała <wiktorek140@gmail.com>
> [Valérie: Sound and modem]
> Co-developed-by: Valérie Roux <undev@unixgirl.xyz>
> Signed-off-by: Valérie Roux <undev@unixgirl.xyz>
> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> [Nikita: Use common dtsi]
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: Add Motorola Moto G 2015 (osprey)
From: Konrad Dybcio @ 2024-04-09 9:46 UTC (permalink / raw)
To: Nikita Travkin, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Martijn Braam,
Stephan Gerhold
In-Reply-To: <20240405-msm8916-moto-init-v1-4-502b58176d34@trvn.ru>
On 4/5/24 16:06, Nikita Travkin wrote:
> From: Martijn Braam <martijn@brixit.nl>
>
> Motorola Moto G 2015 is an msm8916 based smartphone.
>
> Supported features:
>
> - eMMC and SD;
> - Buttons;
> - Touchscreen;
> - USB;
> - Fuel Gauge;
> - Sound.
>
> Signed-off-by: Martijn Braam <martijn@brixit.nl>
> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> [Nikita: Use common dtsi]
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Krzysztof Kozlowski @ 2024-04-09 9:47 UTC (permalink / raw)
To: michael.opdenacker, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen Wang, Inochi Amaoto, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: devicetree, linux-riscv, linux-kernel
In-Reply-To: <20240409064504.4010353-1-michael.opdenacker@bootlin.com>
On 09/04/2024 08:45, michael.opdenacker@bootlin.com wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>
> This adds initial support for the Milk-V Duo S board
> (https://milkv.io/duo-s), enabling the serial port and
> read-only SD card support, allowing to boot Linux to the
> command line.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
>
> ---
>
> Tested with linux-next as of Apr 9, 2024,
> using the risc-v "defconfig" configuration.
Please include in your tests what submitting patches and your maintainer
profile asks you. checkpatch and testing of DTS.
Please run scripts/checkpatch.pl and fix reported warnings. Then please
run `scripts/checkpatch.pl --strict` and (probably) fix more warnings.
Some warnings can be ignored, especially from --strict run, but the code
here looks like it needs a fix. Feel free to get in touch if the warning
is not clear.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH RFC] arm64: dts: mediatek: mt8183-kodama: Split into base and overlays
From: Chen-Yu Tsai @ 2024-04-09 9:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dianders, Chen-Yu Tsai, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
All the SKUs of Kodama share much of their .dts, as evident of the
inclusion of a common .dtsi file. However this scheme builds each
.dtb file as a complete device tree.
To deduplicate this, make the common .dtsi file a .dts file, and the
SKU specific .dts files into .dtso overlay source files. Have the build
system assemble the SKU specific .dtb files from these components.
The final composite .dtb files increase in size by around 54 kB, or 22.5%,
due to the inclusion of symbols and fixup tables, and extra phandle
properties. This could be slightly reduced by dropping the symbol and
fixup tables after the overlays are fully applied if desired.
However if the bootloader can assemble the end .dtb using the base .dtb
and overlays, and only those are counted, then the combined size
decreases by around 165 kB, or 68.7%.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Hi,
This is part of the work I'm looking into and will present at EOSS 2024
in Seattle [1].
The idea is to reorganize device trees so that devices within a common
family, instead of having a common .dtsi file, will share a base DTB
and apply one or more overlays on top. This allows an upstream [2] or
downstream [3] bundling script to be able to deduplicate the base DTB
and get some space savings, however minor they are compared to the
kernel binary executable.
This patch gives a simple conversion, but we could even look into
converting the entire MT8183 Kukui family, which are all based on the
"Kukui" hardware reference design.
There are some issues, hence the RFC:
1. The base .dtb doesn't have a valid board compatible string sequence
yet. Suppose we used the sequence
"google,kodama", "mediatek,mt8183"
for the base .dtb in this conversion, would that be acceptable? The
base .dtb would act like a fallback.
2. The composite .dtb files grow in size substantially, due to the base
.dtb file being built with overlay support. The symbols and fixup
tables could be trimmed out with `fdtput`, but there will still be
extra phandles, and also nodes with /omit-if-no-ref/ that would
have been removed.
For this I could maybe come up with a program to minify the DTB. That
would also work for existing composite .dtb files in-tree.
3. Such a scheme would require more awareness on the maintainer's part,
and of the .dtbo authors. The maintainer needs to be aware of how
the composite .dtb files are assembled. The authors need to know that
certain constructs, such as /delete-property/ or /delete-node/, won't
work.
[1] https://eoss24.sched.com/event/1aBGe/second-source-component-probing-on-device-tree-platforms-chen-yu-tsai-google-llc
[2] https://lore.kernel.org/linux-arm-kernel/20240329032836.141899-1-sjg@chromium.org/
[3] https://crrev.com/c/5412876
arch/arm64/boot/dts/mediatek/Makefile | 6 ++++++
...ukui-kodama-sku16.dts => mt8183-kukui-kodama-sku16.dtso} | 4 ++--
...ui-kodama-sku272.dts => mt8183-kukui-kodama-sku272.dtso} | 4 ++--
...ui-kodama-sku288.dts => mt8183-kukui-kodama-sku288.dtso} | 4 ++--
...ukui-kodama-sku32.dts => mt8183-kukui-kodama-sku32.dtso} | 4 ++--
.../{mt8183-kukui-kodama.dtsi => mt8183-kukui-kodama.dts} | 0
6 files changed, 14 insertions(+), 8 deletions(-)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku16.dts => mt8183-kukui-kodama-sku16.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku272.dts => mt8183-kukui-kodama-sku272.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku288.dts => mt8183-kukui-kodama-sku288.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku32.dts => mt8183-kukui-kodama-sku32.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama.dtsi => mt8183-kukui-kodama.dts} (100%)
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 9234dadfe1ad..6986d7a2efaa 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -46,6 +46,12 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu-sku22.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-katsu-sku32.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-katsu-sku38.dtb
+
+mt8183-kukui-kodama-sku16-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku16.dtbo
+mt8183-kukui-kodama-sku272-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku272.dtbo
+mt8183-kukui-kodama-sku288-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku288.dtbo
+mt8183-kukui-kodama-sku32-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku32.dtbo
+
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku288.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dtso
index 7213cdcca612..20675de68823 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku16 board";
chassis-type = "tablet";
compatible = "google,kodama-sku16", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dtso
index bbf0cd1aa66d..46ab97a18003 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku272 board";
chassis-type = "tablet";
compatible = "google,kodama-sku272", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dtso
index a429ffeac3bd..e27b56f1826d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku288 board";
chassis-type = "tablet";
compatible = "google,kodama-sku288", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dtso
index 5a416143b4a0..d9a13ff7abf2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku32 board";
chassis-type = "tablet";
compatible = "google,kodama-sku32", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dts
similarity index 100%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dts
--
2.44.0.478.gd926399ef9-goog
^ permalink raw reply related
* [PATCH v7 0/3] Add support for nuvoton ma35d1 pin control
From: Jacky Huang @ 2024-04-09 9:56 UTC (permalink / raw)
To: linus.walleij, robh+dt, krzysztof.kozlowski+dt, conor+dt, p.zabel,
j.neuschaefer
Cc: linux-arm-kernel, linux-gpio, devicetree, linux-kernel, ychuang3,
schung
From: Jacky Huang <ychuang3@nuvoton.com>
This patch series adds the pin control and GPIO driver for the nuvoton ma35d1
ARMv8 SoC. It includes DT binding documentation and the ma35d1 pin control driver.
This pin control driver has been tested on the ma35d1 som board with Linux 6.9.0.
v7:
- Replace the magic numbers appearing in the driver with defined constants, or
provide comments to explain them.
- Update the ma35_irq_irqtype()
- irq_set_handler_locked(d, handle_edge_irq) and
irq_set_handler_locked(d, handle_level_irq)
- add case IRQ_TYPE_EDGE_BOTH
- Use handle_bad_irq for girq->handler, instead of handle_level_irq
v6:
- Remove DTS from this patchset. The DTS will be submitted in another patchset.
v5:
- Update the pinctrl driver header file pinctrl-ma35.h
- Include platform_device.h to fix compile issues.
v4:
- Update the pinctrl driver Kconfig
- Add depends to CONFIG_PINCTRL_MA35D1 to prevent compilation errors.
- Update the pinctrl driver
- Utilize devm_kcalloc() instead of devm_kzalloc().
- Employ ARRAY_SIZE() instead of sizeof()/sizeof().
v3:
- Update DTS and YAML files
- Corrected the unit address of nodes gpioa ~ gpion.
- Removed the invalid "pin-default" node.
- Removed the phandle entry from "nuvoton,pins".
- Update pinctrl driver
- Fixed the Kconfig by using "depend on" instead of "if".
- Removed unused #include of header files.
- Utilized immutable irq_chip instead of dynamic irq_chip.
- Replaced ma35_dt_free_map() with pinconf_generic_dt_free_map().
- Implemented other minor fixes as suggested by the reviewer.
v2:
- Update nuvoton,ma35d1-pinctrl.yaml
- Update the 'nuvoton,pins' to follow the style of rockchip pinctrl approch.
- Use power-source to indicate the pin voltage selection which follow the
realtek pinctrl approch.
- Instead of integer, use drive-strength-microamp to specify the real driving
strength capability of IO pins.
- Update ma35d1 pinctrl driver
- Add I/O drive strength lookup table for translating device tree setting
into control register.
- Remove ma35d1-pinfunc.h which is unused after update definition of 'nuvoton,pins'.
Jacky Huang (3):
dt-bindings: reset: Add syscon to nuvoton ma35d1 system-management
node
dt-bindings: pinctrl: Document nuvoton ma35d1 pin control
pinctrl: nuvoton: Add ma35d1 pinctrl and GPIO driver
.../pinctrl/nuvoton,ma35d1-pinctrl.yaml | 163 ++
.../bindings/reset/nuvoton,ma35d1-reset.yaml | 3 +-
drivers/pinctrl/nuvoton/Kconfig | 19 +
drivers/pinctrl/nuvoton/Makefile | 2 +
drivers/pinctrl/nuvoton/pinctrl-ma35.c | 1233 +++++++++++
drivers/pinctrl/nuvoton/pinctrl-ma35.h | 51 +
drivers/pinctrl/nuvoton/pinctrl-ma35d1.c | 1797 +++++++++++++++++
7 files changed, 3267 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml
create mode 100644 drivers/pinctrl/nuvoton/pinctrl-ma35.c
create mode 100644 drivers/pinctrl/nuvoton/pinctrl-ma35.h
create mode 100644 drivers/pinctrl/nuvoton/pinctrl-ma35d1.c
--
2.34.1
^ permalink raw reply
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