* Re: [PATCH v4 0/9] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Geert Uytterhoeven @ 2026-03-18 8:11 UTC (permalink / raw)
To: Biju Das
Cc: biju.das.au, Greg Kroah-Hartman, Jiri Slaby, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB11346876072AAF91064B2700D8641A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi Biju,
On Tue, 17 Mar 2026 at 20:59, Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Please ignore this series . I missed to addresses for Patch#4. I have sent a new
> version[1] fixing it. Sorry for the noise.
>
> [1] https://lore.kernel.org/linux-renesas-soc/20260317195650.468330-1-biju.das.jz@bp.renesas.com/T/#t
You have sent two "v4" versions with different Message-IDs,
which are treated as different series by both b4 and lore.
Please bump to v5 and resend.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH v4 0/9] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Biju Das @ 2026-03-18 8:16 UTC (permalink / raw)
To: geert
Cc: biju.das.au, Greg Kroah-Hartman, Jiri Slaby, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <CAMuHMdUiomf+6O5eDUBAt-41D-Lhvnda7w_bbdj-EQppapjdUg@mail.gmail.com>
Hi Geert,
> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 18 March 2026 08:11
> Subject: Re: [PATCH v4 0/9] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
>
> Hi Biju,
>
> On Tue, 17 Mar 2026 at 20:59, Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > Please ignore this series . I missed to addresses for Patch#4. I have
> > sent a new version[1] fixing it. Sorry for the noise.
> >
> > [1]
> > https://lore.kernel.org/linux-renesas-soc/20260317195650.468330-1-biju
> > .das.jz@bp.renesas.com/T/#t
>
> You have sent two "v4" versions with different Message-IDs, which are treated as different series by
> both b4 and lore.
> Please bump to v5 and resend.
OK will send v5.
Thanks,
Biju
^ permalink raw reply
* [PATCH v5 0/9] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Biju @ 2026-03-18 8:41 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, devicetree, linux-clk,
linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Hi all,
This patch series adds initial support for the Renesas RZ/G3L SoC and
RZ/G3L SMARC EVK platform. The RZ/G3L device is a general-purpose
microprocessor with a quad-core CA-55, single core CM-33, Mali-G31
3-D Graphics and other peripherals.
Support for the below list of blocks is added in the SoC DTSI (r9a08g046.dtsi):
- EXT CLK
- 4X CA55
- SCIF
- CPG
- GIC
- ARMv8 Timer
This series also adds SCIF support for the RZ/G3L SMARC EVK board (r9a08g046l48-smarc.dts).
v4->v5:
* Rebased to next-20260317.
v3->v4:
* Dropped SoC identification patches as it is accepted for renesas-devel.
* Updated commit description related to core clocks section in the
hardware manual
* Dropped CLK_P4_DIV2 from core clocks
* Added MIPI_DSI_PLLCLK and USB_SCLK to core clocks
* Dropped LVDS_PCLK module clock
* Added BSC_X_PRESET_BSC reset
* Moved the patch series from [1] to here as it is boot-dependent.
* Updated commit description
* Updated LAST_DT_CORE_CLK with R9A08G046_USB_SCLK
* Fixed typo 2->8 in dtable_4_128[].
* Added critical reset table r9a08g046_critical_resets[]
* Updated num_resets
* Added crit_resets and num_crit_resets to r9a08g046_cpg_info.
* Fixed typo R0A08G046L->R9A08G046L in commit description
* Dropped R9A08G046L46 from commit description
* Dropped unused audio_clk{1,2} andcan_clk device nodes
* Reordered i2c device node and updated reg entries by using lower-case
hexadecimal number
* Added placeholder in pinctrl node
* Dropped unused DMAC device node
* Added pcie node with placeholder
* Collected the tags.
* Updated commit description for patch#8
[1] https://lore.kernel.org/all/20260306134228.871815-1-biju.das.jz@bp.renesas.com/
v2->v3:
* Added macros R9A08G046_ETH{0,1}_CLK_{TX,RX}_I_RMII in r9a08g046-cpg.h.
* Keep the tag from Conor as it is trivial change for just adding macros.
v1->v2:
* Dropped scif bindings patch as it is accepted.
* Collected tags.
* Squashed the patch#3 and #4
* Documented GE3D/VCP for all SoC variants
* Documented external ethernet clocks as it is a clock source for MUX
inside CPG
* Updated commit description for bindings.
* Keep the tag from Conor as it is trivial change for adding more
clks.
* Added CLK_ETH{0,1}_TXC_TX_CLK_IN and CLK_ETH{0,1}_RXC_RX_CLK_IN clocks
in clk table.
* Dropped R9A08G046_IA55_PCLK from critical clock list.
* Added external clocks eth{0,1}_txc_tx_clk and eth{0,1}_rxc_rx_clk
in soc dtsi as it needed for cpg as it is a clock source for mux.
* Updated cpg node.
* Dropped gpio.h header from SoM dtsi.
* Dropped scif node as it is already included in common platform
file.
Test logs:
/ # uname -r
7.0.0-rc4-next-20260317-g8e0ac8206088
/ # cat /proc/cpuinfo
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 1
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 2
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
/ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 104 191 429 62 GICv3 27 Level arch_timer
14: 0 0 0 0 GICv3 418 Level 100ac000.serial:rx err
15: 4 0 0 0 GICv3 420 Level 100ac000.serial:rx full
16: 229 0 0 0 GICv3 421 Level 100ac000.serial:tx empty
17: 0 0 0 0 GICv3 419 Level 100ac000.serial:break
18: 17 0 0 0 GICv3 422 Level 100ac000.serial:rx ready
IPI0: 3 16 13 21 Rescheduling interrupts
IPI1: 315 240 180 217 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop NMIs
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU backtrace interrupts
IPI7: 0 0 0 0 KGDB roundup interrupts
Err: 0
/ # cat /proc/meminfo
MemTotal: 1887304 kB
MemFree: 1852164 kB
MemAvailable: 1819524 kB
/ # cat /sys/devices/soc0/family
RZ/G3L
/ # cat /sys/devices/soc0/machine
Renesas SMARC EVK version 2 based on r9a08g046l48
/ # cat /sys/devices/soc0/soc_id
r9a08g046
/ # cat /sys/devices/soc0/revision
0
dmesg | grep r9a
[ 0.000000] Machine model: Renesas SMARC EVK version 2 based on r9a08g046l48
[ 0.066480] renesas-rz-sysc 11020000.system-controller: Detected Renesas RZ/G3L r9a08g046 Rev 0
Biju Das (9):
dt-bindings: clock: Document RZ/G3L SoC
clk: renesas: rzg2l-cpg: Add support for critical resets
clk: renesas: r9a07g04{3,4}/r9a08g045-cpg: Add critical reset entries
clk: renesas: rzg2l-cpg: Re-enable critical module clocks during
resume
clk: renesas: Add support for RZ/G3L SoC
arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
arm64: dts: renesas: Add initial support for RZ/G3L SMARC SoM
arm64: dts: renesas: renesas-smarc2: Move usb3 nodes to board DTS
arm64: dts: renesas: Add initial device tree for RZ/G3L SMARC EVK
board
.../bindings/clock/renesas,rzg2l-cpg.yaml | 40 +-
arch/arm64/boot/dts/renesas/Makefile | 2 +
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 215 +++++++++++
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 37 ++
arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi | 13 +
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 6 +
.../boot/dts/renesas/renesas-smarc2.dtsi | 8 -
.../boot/dts/renesas/rzg3l-smarc-som.dtsi | 20 +
drivers/clk/renesas/Kconfig | 7 +-
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a07g043-cpg.c | 8 +
drivers/clk/renesas/r9a07g044-cpg.c | 13 +
drivers/clk/renesas/r9a08g045-cpg.c | 9 +
drivers/clk/renesas/r9a08g046-cpg.c | 153 ++++++++
drivers/clk/renesas/rzg2l-cpg.c | 80 ++++
drivers/clk/renesas/rzg2l-cpg.h | 8 +
include/dt-bindings/clock/r9a08g046-cpg.h | 342 ++++++++++++++++++
17 files changed, 948 insertions(+), 14 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
create mode 100644 drivers/clk/renesas/r9a08g046-cpg.c
create mode 100644 include/dt-bindings/clock/r9a08g046-cpg.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao (陶志勇) @ 2026-03-18 12:12 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, Vasanth Reddy,
linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <434e34f05bb5f87b59402811012e3a2f56f2182e.camel@mediatek.com>
On Wed, 2026-01-21 at 14:23 +0800, Zhiyong Tao wrote:
> On Tue, 2026-01-06 at 11:02 +0100, Greg KH wrote:
> > On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> > > From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
> > >
> > > Add ACPI support to 8250_mtk driver. This makes it possible to
> > > use UART on ARM-based desktops with EDK2 UEFI firmware.
> > >
> > > Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> > > Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
> > > ---
> > > drivers/tty/serial/8250/8250_mtk.c | 23 +++++++++++++++++++----
> > > 1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > This is a resend of the previous version, right? Or did something
> > change?
> >
> > confused,
> >
> > greg k-h
>
> ==> Hi Greg,
> Yes, previously Yenchia Chen helped to send out a version. Currently,
> this solution is specifically for the GB10 project and was made to
> support Windows ACPI settings.
>
> In actual application scenarios, the apdma clk will not be turned off
> in normal mode. It is only turned off in the SSPM microprocessor
> after
> entering standby, and when resuming, the apdma clk is re-enabled by
> SSPM.
>
> As for other Linux projects, apdma still uses the DTS node.
>
> Thanks
>
Hi Greg,
Do you have other suggestion for this?
Thanks
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: gregkh @ 2026-03-18 14:19 UTC (permalink / raw)
To: Zhiyong Tao (陶志勇)
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, Vasanth Reddy,
linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <6478a71ffca65e58fa19a5edbc25eb5f51a8cc12.camel@mediatek.com>
On Wed, Mar 18, 2026 at 12:12:36PM +0000, Zhiyong Tao (陶志勇) wrote:
> On Wed, 2026-01-21 at 14:23 +0800, Zhiyong Tao wrote:
> > On Tue, 2026-01-06 at 11:02 +0100, Greg KH wrote:
> > > On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> > > > From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
> > > >
> > > > Add ACPI support to 8250_mtk driver. This makes it possible to
> > > > use UART on ARM-based desktops with EDK2 UEFI firmware.
> > > >
> > > > Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> > > > Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
> > > > ---
> > > > drivers/tty/serial/8250/8250_mtk.c | 23 +++++++++++++++++++----
> > > > 1 file changed, 19 insertions(+), 4 deletions(-)
> > >
> > > This is a resend of the previous version, right? Or did something
> > > change?
> > >
> > > confused,
> > >
> > > greg k-h
> >
> > ==> Hi Greg,
> > Yes, previously Yenchia Chen helped to send out a version. Currently,
> > this solution is specifically for the GB10 project and was made to
> > support Windows ACPI settings.
> >
> > In actual application scenarios, the apdma clk will not be turned off
> > in normal mode. It is only turned off in the SSPM microprocessor
> > after
> > entering standby, and when resuming, the apdma clk is re-enabled by
> > SSPM.
> >
> > As for other Linux projects, apdma still uses the DTS node.
> >
> > Thanks
> >
>
> Hi Greg,
> Do you have other suggestion for this?
You can't just resend something and not say why you are resending it.
Also, the authorship information seems to be backwards.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] hvc/xen: Check console connection flag
From: Jason Andryuk @ 2026-03-18 23:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko
Cc: Jason Andryuk, linuxppc-dev, linux-kernel, linux-serial,
xen-devel
When the console out buffer is filled, __write_console() will return 0
as it cannot send any data. domU_write_console() will then spin in
`while (len)` as len doesn't decrement until xenconsoled attaches. This
would block a domU and nullify the parallelism of Hyperlaunch until dom0
userspace starts xenconsoled, which empties the buffer.
Xen 4.21 added a connection field to the xen console page. This is set
to XENCONSOLE_DISCONNECTED (1) when a domain is built, and xenconsoled
will set it to XENCONSOLE_CONNECTED (0) when it connects.
Update the hvc_xen driver to check the field. When the field is
disconnected, drop the write with -ENOTCONN. We only drop the write
when the field is XENCONSOLE_DISCONNECTED (1) to try for maximum
compatibility. The Xen toolstack has historically zero initialized the
console, so it should see XENCONSOLE_CONNECTED (0) by default. If an
implemenation used uninitialized memory, only checking for
XENCONSOLE_DISCONNECTED could have the lowest chance of not connecting.
This lets the hyperlaunched domU boot without stalling. Once dom0
starts xenconsoled, xl console can be used to access the domU's hvc0.
Paritally sync console.h from xen.git to bring in the new field.
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
v2:
s/XENCONSOLED/XENCONSOLE/ in commit message
Mention sync from xen.git in commit message
R-b: Stefano
---
drivers/tty/hvc/hvc_xen.c | 3 +++
include/xen/interface/io/console.h | 13 +++++++++++++
2 files changed, 16 insertions(+)
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 7f0b6262488c..c407592442cd 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -139,6 +139,9 @@ static ssize_t domU_write_console(uint32_t vtermno, const u8 *data, size_t len)
if (cons == NULL)
return -EINVAL;
+ if (cons->intf->connection == XENCONSOLE_DISCONNECTED)
+ return -ENOTCONN;
+
/*
* Make sure the whole buffer is emitted, polling if
* necessary. We don't ever want to rely on the hvc daemon
diff --git a/include/xen/interface/io/console.h b/include/xen/interface/io/console.h
index cf17e89ed861..687949bdebb1 100644
--- a/include/xen/interface/io/console.h
+++ b/include/xen/interface/io/console.h
@@ -19,6 +19,19 @@ struct xencons_interface {
char out[2048];
XENCONS_RING_IDX in_cons, in_prod;
XENCONS_RING_IDX out_cons, out_prod;
+/*
+ * Flag values signaling from backend to frontend whether the console is
+ * connected. i.e. Whether it will be serviced and emptied.
+ *
+ * The flag starts as disconnected.
+ */
+#define XENCONSOLE_DISCONNECTED 1
+/*
+ * The flag is set to connected when the backend connects and the console
+ * will be serviced.
+ */
+#define XENCONSOLE_CONNECTED 0
+ uint8_t connection;
};
#endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
--
2.34.1
^ permalink raw reply related
* [PATCH] serial: qcom-geni: drop stray newline format specifier
From: Kathiravan Thirumoorthy @ 2026-03-19 9:48 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-arm-msm, linux-kernel, linux-serial,
Kathiravan Thirumoorthy
Drop the newline character from the middle of the printk message.
This avoids breaking the message into two lines unnecessarily.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
drivers/tty/serial/qcom_geni_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 9854bb2406e3fc830323ebbfdef1e471f00fa416..b365dd5da3cb799c4ec241724310c23d6bf7e16a 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1282,7 +1282,7 @@ static int geni_serial_set_rate(struct uart_port *uport, unsigned int baud)
return -EINVAL;
}
- dev_dbg(port->se.dev, "desired_rate = %u, clk_rate = %lu, clk_div = %u\n, clk_idx = %u\n",
+ dev_dbg(port->se.dev, "desired_rate = %u, clk_rate = %lu, clk_div = %u, clk_idx = %u\n",
baud * sampling_rate, clk_rate, clk_div, clk_idx);
uport->uartclk = clk_rate;
---
base-commit: 8e42d2514a7e8eb8d740d0ba82339dd6c0b6463f
change-id: 20260319-drop_stray_n-ebd7ad277f9d
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH] serial: qcom-geni: drop stray newline format specifier
From: Konrad Dybcio @ 2026-03-19 10:19 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-arm-msm, linux-kernel, linux-serial
In-Reply-To: <20260319-drop_stray_n-v1-1-37fb619538bb@oss.qualcomm.com>
On 3/19/26 10:48 AM, Kathiravan Thirumoorthy wrote:
> Drop the newline character from the middle of the printk message.
> This avoids breaking the message into two lines unnecessarily.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v6 00/10] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Biju @ 2026-03-19 12:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, devicetree, linux-clk,
linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Hi all,
This patch series adds initial support for the Renesas RZ/G3L SoC and
RZ/G3L SMARC EVK platform. The RZ/G3L device is a general-purpose
microprocessor with a quad-core CA-55, single core CM-33, Mali-G31
3-D Graphics and other peripherals.
Support for the below list of blocks is added in the SoC DTSI (r9a08g046.dtsi):
- EXT CLK
- 4X CA55
- SCIF
- CPG
- GIC
- ARMv8 Timer
This series also adds SCIF support for the RZ/G3L SMARC EVK board (r9a08g046l48-smarc.dts).
v5->v6:
* Collected tags
* Moved loop variable declaration inside for loops in
__rzg2l_cpg_assert() and rzg2l_cpg_deassert_crit_resets()
* Replaced r9a07g043_critical_resets[] -> r9a07g043_crit_resets[] for
consistency
* Introduced rzg2l_mod_clock_init_mstop_helper() for code reuse
in probe() and resume().
* Dropped the list implementation.
* Replaced rzg2l_mod_clock_init_mstop->rzg2l_mod_enable_crit_clock_init_mstop()
for enabling critical clks and restoring mstop state during resume.
* Dropped dma-ranges, bus-range and comment from the pcie device node
v4->v5:
* Rebased to next-20260317.
v3->v4:
* Dropped SoC identification patches as it is accepted for renesas-devel.
* Updated commit description related to core clocks section in the
hardware manual
* Dropped CLK_P4_DIV2 from core clocks
* Added MIPI_DSI_PLLCLK and USB_SCLK to core clocks
* Dropped LVDS_PCLK module clock
* Added BSC_X_PRESET_BSC reset
* Moved the patch series from [1] to here as it is boot-dependent.
* Updated commit description
* Updated LAST_DT_CORE_CLK with R9A08G046_USB_SCLK
* Fixed typo 2->8 in dtable_4_128[].
* Added critical reset table r9a08g046_critical_resets[]
* Updated num_resets
* Added crit_resets and num_crit_resets to r9a08g046_cpg_info.
* Fixed typo R0A08G046L->R9A08G046L in commit description
* Dropped R9A08G046L46 from commit description
* Dropped unused audio_clk{1,2} andcan_clk device nodes
* Reordered i2c device node and updated reg entries by using lower-case
hexadecimal number
* Added placeholder in pinctrl node
* Dropped unused DMAC device node
* Added pcie node with placeholder
* Collected the tags.
* Updated commit description for patch#8
[1] https://lore.kernel.org/all/20260306134228.871815-1-biju.das.jz@bp.renesas.com/
v2->v3:
* Added macros R9A08G046_ETH{0,1}_CLK_{TX,RX}_I_RMII in r9a08g046-cpg.h.
* Keep the tag from Conor as it is trivial change for just adding macros.
v1->v2:
* Dropped scif bindings patch as it is accepted.
* Collected tags.
* Squashed the patch#3 and #4
* Documented GE3D/VCP for all SoC variants
* Documented external ethernet clocks as it is a clock source for MUX
inside CPG
* Updated commit description for bindings.
* Keep the tag from Conor as it is trivial change for adding more
clks.
* Added CLK_ETH{0,1}_TXC_TX_CLK_IN and CLK_ETH{0,1}_RXC_RX_CLK_IN clocks
in clk table.
* Dropped R9A08G046_IA55_PCLK from critical clock list.
* Added external clocks eth{0,1}_txc_tx_clk and eth{0,1}_rxc_rx_clk
in soc dtsi as it needed for cpg as it is a clock source for mux.
* Updated cpg node.
* Dropped gpio.h header from SoM dtsi.
* Dropped scif node as it is already included in common platform
file.
Test logs:
/ # uname -r
7.0.0-rc4-next-20260317-gb478da6183c1
/ # cat /proc/cpuinfo
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 1
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 2
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
/ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 104 191 429 62 GICv3 27 Level arch_timer
14: 0 0 0 0 GICv3 418 Level 100ac000.serial:rx err
15: 4 0 0 0 GICv3 420 Level 100ac000.serial:rx full
16: 229 0 0 0 GICv3 421 Level 100ac000.serial:tx empty
17: 0 0 0 0 GICv3 419 Level 100ac000.serial:break
18: 17 0 0 0 GICv3 422 Level 100ac000.serial:rx ready
IPI0: 3 16 13 21 Rescheduling interrupts
IPI1: 315 240 180 217 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop NMIs
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU backtrace interrupts
IPI7: 0 0 0 0 KGDB roundup interrupts
Err: 0
/ # cat /proc/meminfo
MemTotal: 1887304 kB
MemFree: 1852164 kB
MemAvailable: 1819524 kB
/ # cat /sys/devices/soc0/family
RZ/G3L
/ # cat /sys/devices/soc0/machine
Renesas SMARC EVK version 2 based on r9a08g046l48
/ # cat /sys/devices/soc0/soc_id
r9a08g046
/ # cat /sys/devices/soc0/revision
0
dmesg | grep r9a
[ 0.000000] Machine model: Renesas SMARC EVK version 2 based on r9a08g046l48
[ 0.066480] renesas-rz-sysc 11020000.system-controller: Detected Renesas RZ/G3L r9a08g046 Rev 0
Biju Das (10):
dt-bindings: clock: Document RZ/G3L SoC
clk: renesas: rzg2l-cpg: Add support for critical resets
clk: renesas: r9a07g04{3,4}/r9a08g045-cpg: Add critical reset entries
clk: renesas: rzg2l-cpg: Add rzg2l_mod_clock_init_mstop_helper()
clk: renesas: rzg2l-cpg: Re-enable critical module clocks during
resume
clk: renesas: Add support for RZ/G3L SoC
arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
arm64: dts: renesas: Add initial support for RZ/G3L SMARC SoM
arm64: dts: renesas: renesas-smarc2: Move usb3 nodes to board DTS
arm64: dts: renesas: Add initial device tree for RZ/G3L SMARC EVK
board
.../bindings/clock/renesas,rzg2l-cpg.yaml | 40 +-
arch/arm64/boot/dts/renesas/Makefile | 2 +
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 212 +++++++++++
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 37 ++
arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi | 13 +
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 6 +
.../boot/dts/renesas/renesas-smarc2.dtsi | 8 -
.../boot/dts/renesas/rzg3l-smarc-som.dtsi | 20 +
drivers/clk/renesas/Kconfig | 7 +-
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a07g043-cpg.c | 8 +
drivers/clk/renesas/r9a07g044-cpg.c | 13 +
drivers/clk/renesas/r9a08g045-cpg.c | 9 +
drivers/clk/renesas/r9a08g046-cpg.c | 153 ++++++++
drivers/clk/renesas/rzg2l-cpg.c | 79 +++-
drivers/clk/renesas/rzg2l-cpg.h | 8 +
include/dt-bindings/clock/r9a08g046-cpg.h | 342 ++++++++++++++++++
17 files changed, 934 insertions(+), 24 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
create mode 100644 drivers/clk/renesas/r9a08g046-cpg.c
create mode 100644 include/dt-bindings/clock/r9a08g046-cpg.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH v6 0/6] Add support for Microchip LAN969x
From: Claudiu Beznea @ 2026-03-20 9:11 UTC (permalink / raw)
To: Robert Marko, robh, krzk+dt, conor+dt, nicolas.ferre,
alexandre.belloni, olivia, herbert, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, horatiu.vultur, Ryan.Wanner,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
linux-spi, linux-serial, daniel.machon
Cc: luka.perkov
In-Reply-To: <20260302112153.464422-1-robert.marko@sartura.hr>
On 3/2/26 13:20, Robert Marko wrote:
> Robert Marko (6):
> arm64: dts: microchip: add LAN969x clock header file
> arm64: dts: microchip: add LAN969x support
> dt-bindings: arm: AT91: document EV23X71A board
> arm64: dts: microchip: add EV23X71A board
Applied to microchip-dt64, thanks!
^ permalink raw reply
* [PATCH v7 00/10] Add support for Renesas RZ/G3L SoC and SMARC-EVK platform
From: Biju @ 2026-03-20 10:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, devicetree, linux-clk,
linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Hi all,
This patch series adds initial support for the Renesas RZ/G3L SoC and
RZ/G3L SMARC EVK platform. The RZ/G3L device is a general-purpose
microprocessor with a quad-core CA-55, single core CM-33, Mali-G31
3-D Graphics and other peripherals.
Support for the below list of blocks is added in the SoC DTSI (r9a08g046.dtsi):
- EXT CLK
- 4X CA55
- SCIF
- CPG
- GIC
- ARMv8 Timer
This series also adds SCIF support for the RZ/G3L SMARC EVK board (r9a08g046l48-smarc.dts).
v6->v7:
* Collected tag
* Updated r9a07g043_cpg_info by inserting a blank line before
.has_clk_mon_regs
* Replaced r9a07g044_critical_resets->r9a07g044_crit_resets,
r9a08g045_critical_resets->r9a08g045_crit_resets and
r9a08g046_critical_resets->r9a08g046_crit_resets for consistency
* RZ/V2M has critical clocks but no mstop, so move the mstop check after
enabling critical clocks. After this, we need to restore only mstop for
module clocks, so remove the inverted logic and continue statement and
directly call rzg2l_mod_clock_init_mstop_helper() if the clock has
mstop.
v5->v6:
* Collected tags
* Moved loop variable declaration inside for loops in
__rzg2l_cpg_assert() and rzg2l_cpg_deassert_crit_resets()
* Replaced r9a07g043_critical_resets[] -> r9a07g043_crit_resets[] for
consistency
* Introduced rzg2l_mod_clock_init_mstop_helper() for code reuse
in probe() and resume().
* Dropped the list implementation.
* Replaced rzg2l_mod_clock_init_mstop->rzg2l_mod_enable_crit_clock_init_mstop()
for enabling critical clks and restoring mstop state during resume.
* Dropped dma-ranges, bus-range and comment from the pcie device node
v4->v5:
* Rebased to next-20260317.
v3->v4:
* Dropped SoC identification patches as it is accepted for renesas-devel.
* Updated commit description related to core clocks section in the
hardware manual
* Dropped CLK_P4_DIV2 from core clocks
* Added MIPI_DSI_PLLCLK and USB_SCLK to core clocks
* Dropped LVDS_PCLK module clock
* Added BSC_X_PRESET_BSC reset
* Moved the patch series from [1] to here as it is boot-dependent.
* Updated commit description
* Updated LAST_DT_CORE_CLK with R9A08G046_USB_SCLK
* Fixed typo 2->8 in dtable_4_128[].
* Added critical reset table r9a08g046_critical_resets[]
* Updated num_resets
* Added crit_resets and num_crit_resets to r9a08g046_cpg_info.
* Fixed typo R0A08G046L->R9A08G046L in commit description
* Dropped R9A08G046L46 from commit description
* Dropped unused audio_clk{1,2} andcan_clk device nodes
* Reordered i2c device node and updated reg entries by using lower-case
hexadecimal number
* Added placeholder in pinctrl node
* Dropped unused DMAC device node
* Added pcie node with placeholder
* Collected the tags.
* Updated commit description for patch#8
[1] https://lore.kernel.org/all/20260306134228.871815-1-biju.das.jz@bp.renesas.com/
v2->v3:
* Added macros R9A08G046_ETH{0,1}_CLK_{TX,RX}_I_RMII in r9a08g046-cpg.h.
* Keep the tag from Conor as it is trivial change for just adding macros.
v1->v2:
* Dropped scif bindings patch as it is accepted.
* Collected tags.
* Squashed the patch#3 and #4
* Documented GE3D/VCP for all SoC variants
* Documented external ethernet clocks as it is a clock source for MUX
inside CPG
* Updated commit description for bindings.
* Keep the tag from Conor as it is trivial change for adding more
clks.
* Added CLK_ETH{0,1}_TXC_TX_CLK_IN and CLK_ETH{0,1}_RXC_RX_CLK_IN clocks
in clk table.
* Dropped R9A08G046_IA55_PCLK from critical clock list.
* Added external clocks eth{0,1}_txc_tx_clk and eth{0,1}_rxc_rx_clk
in soc dtsi as it needed for cpg as it is a clock source for mux.
* Updated cpg node.
* Dropped gpio.h header from SoM dtsi.
* Dropped scif node as it is already included in common platform
file.
Test logs:
/ # uname -r
7.0.0-rc4-next-20260319-g870eaaba5d4a
/ # cat /proc/cpuinfo
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 1
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 2
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
/ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 104 191 429 62 GICv3 27 Level arch_timer
14: 0 0 0 0 GICv3 418 Level 100ac000.serial:rx err
15: 4 0 0 0 GICv3 420 Level 100ac000.serial:rx full
16: 229 0 0 0 GICv3 421 Level 100ac000.serial:tx empty
17: 0 0 0 0 GICv3 419 Level 100ac000.serial:break
18: 17 0 0 0 GICv3 422 Level 100ac000.serial:rx ready
IPI0: 3 16 13 21 Rescheduling interrupts
IPI1: 315 240 180 217 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop NMIs
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU backtrace interrupts
IPI7: 0 0 0 0 KGDB roundup interrupts
Err: 0
/ # cat /proc/meminfo
MemTotal: 1887304 kB
MemFree: 1852164 kB
MemAvailable: 1819524 kB
/ # cat /sys/devices/soc0/family
RZ/G3L
/ # cat /sys/devices/soc0/machine
Renesas SMARC EVK version 2 based on r9a08g046l48
/ # cat /sys/devices/soc0/soc_id
r9a08g046
/ # cat /sys/devices/soc0/revision
0
dmesg | grep r9a
[ 0.000000] Machine model: Renesas SMARC EVK version 2 based on r9a08g046l48
[ 0.066480] renesas-rz-sysc 11020000.system-controller: Detected Renesas RZ/G3L r9a08g046 Rev 0
Biju Das (10):
dt-bindings: clock: Document RZ/G3L SoC
clk: renesas: rzg2l-cpg: Add support for critical resets
clk: renesas: r9a07g04{3,4}/r9a08g045-cpg: Add critical reset entries
clk: renesas: rzg2l-cpg: Add rzg2l_mod_clock_init_mstop_helper()
clk: renesas: rzg2l-cpg: Re-enable critical module clocks during
resume
clk: renesas: Add support for RZ/G3L SoC
arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
arm64: dts: renesas: Add initial support for RZ/G3L SMARC SoM
arm64: dts: renesas: renesas-smarc2: Move usb3 nodes to board DTS
arm64: dts: renesas: Add initial device tree for RZ/G3L SMARC EVK
board
.../bindings/clock/renesas,rzg2l-cpg.yaml | 40 +-
arch/arm64/boot/dts/renesas/Makefile | 2 +
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 212 +++++++++++
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 37 ++
arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi | 13 +
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 6 +
.../boot/dts/renesas/renesas-smarc2.dtsi | 8 -
.../boot/dts/renesas/rzg3l-smarc-som.dtsi | 20 +
drivers/clk/renesas/Kconfig | 7 +-
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a07g043-cpg.c | 9 +
drivers/clk/renesas/r9a07g044-cpg.c | 13 +
drivers/clk/renesas/r9a08g045-cpg.c | 9 +
drivers/clk/renesas/r9a08g046-cpg.c | 153 ++++++++
drivers/clk/renesas/rzg2l-cpg.c | 77 +++-
drivers/clk/renesas/rzg2l-cpg.h | 8 +
include/dt-bindings/clock/r9a08g046-cpg.h | 342 ++++++++++++++++++
17 files changed, 933 insertions(+), 24 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
create mode 100644 arch/arm64/boot/dts/renesas/r9a08g046l48.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
create mode 100644 drivers/clk/renesas/r9a08g046-cpg.c
create mode 100644 include/dt-bindings/clock/r9a08g046-cpg.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: mediatek: add device-tree for Genio 720-EVK board
From: Louis-Alexis Eyraud @ 2026-03-20 12:37 UTC (permalink / raw)
To: David Lechner, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sean Wang
Cc: kernel, linux-kernel, linux-serial, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <c2618423-2466-47bb-a8cf-7c849e7e231e@baylibre.com>
Hi David,
On Thu, 2026-03-12 at 19:26 -0500, David Lechner wrote:
> On 12/3/25 7:59 AM, Louis-Alexis Eyraud wrote:
> > Add support for MediaTek MT8189 SoC and its variants, and a device-
> > tree
> > for the basic hardware enablement of the Genio 720-EVK board, based
> > on
> > MT8391 SoC.
> >
>
> ...
>
> > + mmc0_default_pins: mmc0-default-pins {
> > + pins-clk {
> > + pinmux = <PINMUX_GPIO162__FUNC_MSDC0_CLK>;
> > + drive-strength = <6>;
> > + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> > + };
> > +
> > + pins-cmd-dat {
> > + pinmux =
> > <PINMUX_GPIO166__FUNC_MSDC0_DAT0>,
> > +
> > <PINMUX_GPIO165__FUNC_MSDC0_DAT1>,
> > +
> > <PINMUX_GPIO164__FUNC_MSDC0_DAT2>,
> > +
> > <PINMUX_GPIO163__FUNC_MSDC0_DAT3>,
> > +
> > <PINMUX_GPIO159__FUNC_MSDC0_DAT4>,
> > +
> > <PINMUX_GPIO158__FUNC_MSDC0_DAT5>,
> > +
> > <PINMUX_GPIO157__FUNC_MSDC0_DAT6>,
> > +
> > <PINMUX_GPIO156__FUNC_MSDC0_DAT7>,
> > + <PINMUX_GPIO161__FUNC_MSDC0_CMD>;
> > + input-enable;
> > + drive-strength = <6>;
> > + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> > + };
>
> Should we also have pins-ds here to match mmc0-uhs-pins?
>
The data strobe pin is only used for the HS modes, that is why it is
only declared for uhs state.
No other mediatek board devicetrees have it for default state too, so I
don't think it is needed here.
> > +
> > + pins-rst {
> > + pinmux =
> > <PINMUX_GPIO160__FUNC_MSDC0_RSTB>;
> > + drive-strength = <6>;
> > + bias-pull-up = <MTK_PUPD_SET_R1R0_00>;
> > + };
> > + };
> > +
> > + mmc0_uhs_pins: mmc0-uhs-pins {
> > + pins-clk {
> > + pinmux = <PINMUX_GPIO162__FUNC_MSDC0_CLK>;
> > + drive-strength = <8>;
> > + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> > + };
> > +
> > + pins-cmd-dat {
> > + pinmux =
> > <PINMUX_GPIO166__FUNC_MSDC0_DAT0>,
> > +
> > <PINMUX_GPIO165__FUNC_MSDC0_DAT1>,
> > +
> > <PINMUX_GPIO164__FUNC_MSDC0_DAT2>,
> > +
> > <PINMUX_GPIO163__FUNC_MSDC0_DAT3>,
> > +
> > <PINMUX_GPIO159__FUNC_MSDC0_DAT4>,
> > +
> > <PINMUX_GPIO158__FUNC_MSDC0_DAT5>,
> > +
> > <PINMUX_GPIO157__FUNC_MSDC0_DAT6>,
> > +
> > <PINMUX_GPIO156__FUNC_MSDC0_DAT7>,
> > + <PINMUX_GPIO161__FUNC_MSDC0_CMD>;
> > + input-enable;
> > + drive-strength = <8>;
> > + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> > + };
> > +
> > + pins-ds {
> > + pinmux = <PINMUX_GPIO167__FUNC_MSDC0_DSL>;
> > + drive-strength = <8>;
> > + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> > + };
> > +
> > + pins-rst {
> > + pinmux =
> > <PINMUX_GPIO160__FUNC_MSDC0_RSTB>;
> > + bias-pull-up = <MTK_PUPD_SET_R1R0_00>;
> > + };
> > + };
> > +
> > + mmc1_default_pins: mmc1-default-pins {
> > + pins-clk {
> > + pinmux = <PINMUX_GPIO169__FUNC_MSDC1_CLK>;
> > + drive-strength = <6>;
> > + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> > + };
> > +
> > + pins-cmd-dat {
> > + pinmux =
> > <PINMUX_GPIO170__FUNC_MSDC1_DAT0>,
> > +
> > <PINMUX_GPIO171__FUNC_MSDC1_DAT1>,
> > +
> > <PINMUX_GPIO172__FUNC_MSDC1_DAT2>,
> > +
> > <PINMUX_GPIO173__FUNC_MSDC1_DAT3>,
> > + <PINMUX_GPIO168__FUNC_MSDC1_CMD>;
> > + input-enable;
> > + drive-strength = <6>;
> > + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> > + };
> > +
> > + pins-insert {
> > + pinmux = <PINMUX_GPIO2__FUNC_GPIO2>;
> > + bias-pull-up;
> > + };
> > + };
> > +
> > + mmc1_uhs_pins: mmc1-uhs-pins {
> > + pins-clk {
> > + pinmux = <PINMUX_GPIO169__FUNC_MSDC1_CLK>;
> > + drive-strength = <8>;
> > + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> > + };
> > +
> > + pins-cmd-dat {
> > + pinmux =
> > <PINMUX_GPIO170__FUNC_MSDC1_DAT0>,
> > +
> > <PINMUX_GPIO171__FUNC_MSDC1_DAT1>,
> > +
> > <PINMUX_GPIO172__FUNC_MSDC1_DAT2>,
> > +
> > <PINMUX_GPIO173__FUNC_MSDC1_DAT3>,
> > + <PINMUX_GPIO168__FUNC_MSDC1_CMD>;
> > + input-enable;
> > + drive-strength = <8>;
> > + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
> > + };
>
> Don't we also need pins-insert here? (to match mmc1-default-pins)
>
From what I've found, it was done this way for other board devicetrees
to avoid possible reconfiguration happen for the card detection pin
while switching to UHS and causing a switch failure.
Also, what you declare in pinmux nodes is how the pin configuration
should change in a specific mode and you declare only what changes, and
not what stay the same.
> I was having trouble with the CD input pin not working in U-Boot
> until I added it.
I checked and debugged this on my board and did not get that kind of
issue, whether this pin config is not present for uhs state or if I add
it.
When inserting my sd card or when I boot with it already inserted, the
mtk-sd driver first sets the pinctrl state to default before switching
to ufs. The GPIO02 pin config is also OK in both states.
The mt8189 pinctrl driver seems to apply a default config for this pin
that is the same as the one that is set here.
There might be u-boot particularities that could explain it fixes your
issue.
Regards,
Louis-Alexis
>
> > + };
> > +
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: mediatek: add device-tree for Genio 720-EVK board
From: David Lechner @ 2026-03-20 13:35 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sean Wang
Cc: kernel, linux-kernel, linux-serial, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <7d1e52c0b9c3a6d30e9db617b9bcfa23ed9046b5.camel@collabora.com>
On 3/20/26 7:37 AM, Louis-Alexis Eyraud wrote:
> Hi David,
>
> On Thu, 2026-03-12 at 19:26 -0500, David Lechner wrote:
>> On 12/3/25 7:59 AM, Louis-Alexis Eyraud wrote:
>>> Add support for MediaTek MT8189 SoC and its variants, and a device-
>>> tree
>>> for the basic hardware enablement of the Genio 720-EVK board, based
>>> on
>>> MT8391 SoC.
>>>
>>
>> ...
>>
>>> + mmc0_default_pins: mmc0-default-pins {
>>> + pins-clk {
>>> + pinmux = <PINMUX_GPIO162__FUNC_MSDC0_CLK>;
>>> + drive-strength = <6>;
>>> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
>>> + };
>>> +
>>> + pins-cmd-dat {
>>> + pinmux =
>>> <PINMUX_GPIO166__FUNC_MSDC0_DAT0>,
>>> +
>>> <PINMUX_GPIO165__FUNC_MSDC0_DAT1>,
>>> +
>>> <PINMUX_GPIO164__FUNC_MSDC0_DAT2>,
>>> +
>>> <PINMUX_GPIO163__FUNC_MSDC0_DAT3>,
>>> +
>>> <PINMUX_GPIO159__FUNC_MSDC0_DAT4>,
>>> +
>>> <PINMUX_GPIO158__FUNC_MSDC0_DAT5>,
>>> +
>>> <PINMUX_GPIO157__FUNC_MSDC0_DAT6>,
>>> +
>>> <PINMUX_GPIO156__FUNC_MSDC0_DAT7>,
>>> + <PINMUX_GPIO161__FUNC_MSDC0_CMD>;
>>> + input-enable;
>>> + drive-strength = <6>;
>>> + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
>>> + };
>>
>> Should we also have pins-ds here to match mmc0-uhs-pins?
>>
> The data strobe pin is only used for the HS modes, that is why it is
> only declared for uhs state.
> No other mediatek board devicetrees have it for default state too, so I
> don't think it is needed here.
>
>>> +
>>> + pins-rst {
>>> + pinmux =
>>> <PINMUX_GPIO160__FUNC_MSDC0_RSTB>;
>>> + drive-strength = <6>;
>>> + bias-pull-up = <MTK_PUPD_SET_R1R0_00>;
>>> + };
>>> + };
>>> +
>>> + mmc0_uhs_pins: mmc0-uhs-pins {
>>> + pins-clk {
>>> + pinmux = <PINMUX_GPIO162__FUNC_MSDC0_CLK>;
>>> + drive-strength = <8>;
>>> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
>>> + };
>>> +
>>> + pins-cmd-dat {
>>> + pinmux =
>>> <PINMUX_GPIO166__FUNC_MSDC0_DAT0>,
>>> +
>>> <PINMUX_GPIO165__FUNC_MSDC0_DAT1>,
>>> +
>>> <PINMUX_GPIO164__FUNC_MSDC0_DAT2>,
>>> +
>>> <PINMUX_GPIO163__FUNC_MSDC0_DAT3>,
>>> +
>>> <PINMUX_GPIO159__FUNC_MSDC0_DAT4>,
>>> +
>>> <PINMUX_GPIO158__FUNC_MSDC0_DAT5>,
>>> +
>>> <PINMUX_GPIO157__FUNC_MSDC0_DAT6>,
>>> +
>>> <PINMUX_GPIO156__FUNC_MSDC0_DAT7>,
>>> + <PINMUX_GPIO161__FUNC_MSDC0_CMD>;
>>> + input-enable;
>>> + drive-strength = <8>;
>>> + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
>>> + };
>>> +
>>> + pins-ds {
>>> + pinmux = <PINMUX_GPIO167__FUNC_MSDC0_DSL>;
>>> + drive-strength = <8>;
>>> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
>>> + };
>>> +
>>> + pins-rst {
>>> + pinmux =
>>> <PINMUX_GPIO160__FUNC_MSDC0_RSTB>;
>>> + bias-pull-up = <MTK_PUPD_SET_R1R0_00>;
>>> + };
>>> + };
>>> +
>>> + mmc1_default_pins: mmc1-default-pins {
>>> + pins-clk {
>>> + pinmux = <PINMUX_GPIO169__FUNC_MSDC1_CLK>;
>>> + drive-strength = <6>;
>>> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
>>> + };
>>> +
>>> + pins-cmd-dat {
>>> + pinmux =
>>> <PINMUX_GPIO170__FUNC_MSDC1_DAT0>,
>>> +
>>> <PINMUX_GPIO171__FUNC_MSDC1_DAT1>,
>>> +
>>> <PINMUX_GPIO172__FUNC_MSDC1_DAT2>,
>>> +
>>> <PINMUX_GPIO173__FUNC_MSDC1_DAT3>,
>>> + <PINMUX_GPIO168__FUNC_MSDC1_CMD>;
>>> + input-enable;
>>> + drive-strength = <6>;
>>> + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
>>> + };
>>> +
>>> + pins-insert {
>>> + pinmux = <PINMUX_GPIO2__FUNC_GPIO2>;
>>> + bias-pull-up;
>>> + };
>>> + };
>>> +
>>> + mmc1_uhs_pins: mmc1-uhs-pins {
>>> + pins-clk {
>>> + pinmux = <PINMUX_GPIO169__FUNC_MSDC1_CLK>;
>>> + drive-strength = <8>;
>>> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
>>> + };
>>> +
>>> + pins-cmd-dat {
>>> + pinmux =
>>> <PINMUX_GPIO170__FUNC_MSDC1_DAT0>,
>>> +
>>> <PINMUX_GPIO171__FUNC_MSDC1_DAT1>,
>>> +
>>> <PINMUX_GPIO172__FUNC_MSDC1_DAT2>,
>>> +
>>> <PINMUX_GPIO173__FUNC_MSDC1_DAT3>,
>>> + <PINMUX_GPIO168__FUNC_MSDC1_CMD>;
>>> + input-enable;
>>> + drive-strength = <8>;
>>> + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
>>> + };
>>
>> Don't we also need pins-insert here? (to match mmc1-default-pins)
>>
> From what I've found, it was done this way for other board devicetrees
> to avoid possible reconfiguration happen for the card detection pin
> while switching to UHS and causing a switch failure.
> Also, what you declare in pinmux nodes is how the pin configuration
> should change in a specific mode and you declare only what changes, and
> not what stay the same.
>
>> I was having trouble with the CD input pin not working in U-Boot
>> until I added it.
> I checked and debugged this on my board and did not get that kind of
> issue, whether this pin config is not present for uhs state or if I add
> it.
> When inserting my sd card or when I boot with it already inserted, the
> mtk-sd driver first sets the pinctrl state to default before switching
> to ufs. The GPIO02 pin config is also OK in both states.
> The mt8189 pinctrl driver seems to apply a default config for this pin
> that is the same as the one that is set here.
>
> There might be u-boot particularities that could explain it fixes your
> issue.
>
> Regards,
> Louis-Alexis
>>
>>> + };
>>> +
Thanks for having a look at this and taking the time to explain. I will
see what I can do to fix it in U-Boot.
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: mediatek: add device-tree for Genio 720-EVK board
From: Louis-Alexis Eyraud @ 2026-03-20 14:06 UTC (permalink / raw)
To: David Lechner, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sean Wang
Cc: kernel, linux-kernel, linux-serial, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <23778b52-9aa2-49fc-946b-e858b99fc3c9@baylibre.com>
Hi David,
On Thu, 2026-02-19 at 18:09 -0600, David Lechner wrote:
> On 12/3/25 7:59 AM, Louis-Alexis Eyraud wrote:
> > Add support for MediaTek MT8189 SoC and its variants, and a device-
> > tree
> > for the basic hardware enablement of the Genio 720-EVK board, based
> > on
> > MT8391 SoC.
> >
> > MT8391 SoC is a variant of MT8189 SoC with a difference for the Arm
> > Cortex-A78 CPU core maximum frequency (2.6 Ghz for MT8391, 3 Ghz
> > for
> > MT8189). MT8391 hardware register maps are identical to MT8189.
> >
> > The Genio 720-EVK board has following features:
> > - MT8391 SoC
> > - MT6365 PMIC
>
> Is MT6365 PMIC ...
>
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8391-genio-common.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8391-genio-common.dtsi
> > new file mode 100644
> > index
> > 0000000000000000000000000000000000000000..744641916952111a4b389cf6a
> > dbd27c429b6eff2
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8391-genio-common.dtsi
> > @@ -0,0 +1,555 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (c) 2025 Collabora Ltd.
> > + * Author: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> > + */
> > +
> > +#include "mt6359.dtsi"
>
> ... really 100% identical to MT6359 PMIC?
>
I did not find any info in the LKML archives if this topic was
discussed in the past.
The MT6365 PMIC seems to be more a rebranded MT6359P.
They have the exact same buck converter and LDOs, and features.
There are several boards based on MT8370, MT8390 and MT8395 SoC that
integrate the MT6365 PMIC and whose devicetree, present in upstream,
use the mt6359.dtsi for this PMIC support:
- Mediatek Genio 1200 EVK
- Mediatek Genio 700 EVK
- Mediatek Genio 510 EVK
- Radxa NIO-12L
Probably a couple more.
The Genio 1200 EVK board devicetree was the first one that used
"mediatek,mt6359" compatible for this PMIC.
As far as I know, there is no known compatibility issue.
The MT6359 regulator kernel driver, in particular, does recognise it as
MT6359P (same identifier) and the MT6365 datasheet shows it has the
same register layout from what I compared for the buck and ldos.
So 100% identical? I cannot say it for sure but I don't have any info
telling otherwise.
> Asking because I'm working on this in U-Boot and would be helpful
> to know that this is correct. Would probably be a good idea to
> mention
> it in the commit message too to show this is intentional.
>
>
> And I wonder if it would be a good idea to add a compatible with
> fallback
> just to be sure.
>
> &pmic {
> compatible = "mediatek,mt6365", "mediatek,mt6359";
> };
You're right.
That's make sense to document a proper compatibility in the dt-bindings
and use it the devicetree, not only for pmic node but also but its
subdevices (auxadc, codec, regulator, rtc, pmic-keys).
As the Genio 720 EVK is not the only board concerned, it would be
better that I send another series to do such cleanup, for instance one
that adds a new mt6365.dtsi before using it (instead of mt6359.dtsi) in
the Genio 720 EVK devicetree.
Regards,
Louis-Alexis
^ permalink raw reply
* Re: [PATCH v3 2/4] serdev: add rust private data to serdev_device
From: Markus Probst @ 2026-03-20 16:53 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, Jiri Slaby, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, linux-serial, linux-kernel, rust-for-linux,
linux-pm, driver-core, dri-devel
In-Reply-To: <2026031447-margarita-untamed-e976@gregkh>
[-- Attachment #1: Type: text/plain, Size: 3925 bytes --]
On Sat, 2026-03-14 at 14:31 +0100, Greg Kroah-Hartman wrote:
> On Sat, Mar 14, 2026 at 12:08:09PM +0000, Markus Probst wrote:
> > On Sat, 2026-03-14 at 12:52 +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Mar 14, 2026 at 11:42:02AM +0000, Markus Probst wrote:
> > > > On Sat, 2026-03-14 at 09:07 +0100, Greg Kroah-Hartman wrote:
> > > > > On Fri, Mar 13, 2026 at 06:12:31PM +0000, Markus Probst wrote:
> > > > > > Add rust private data to `struct serdev_device`, as it is required by the
> > > > > > rust abstraction added in the following commit
> > > > > > (rust: add basic serial device bus abstractions).
> > > > >
> > > > > why is rust "special" here? What's wrong with the existing private
> > > > > pointer in this structure? Why must we add another one?
> > > > Because in rust, the device drvdata will be set after probe has run. In
> > > > serdev, once the device has been opened, it can receive data. It must
> > > > be opened either inside probe or before probe, because it can only be
> > > > configured (baudrate, flow control etc.) and data written to after it
> > > > has been opened. Because it can receive data before drvdata has been
> > > > set yet, we need to ensure it waits on data receival for the probe to
> > > > be finished. Otherwise this would be a null pointer dereference. To do
> > > > this, we need to store a `Completion` for it to wait and a `bool` in
> > > > case the probe exits with an error. We cannot store this data in the
> > > > device drvdata, because this is where the drivers drvdata goes. We also
> > > > cannot create a wrapper of the drivers drvdata, because
> > > > `Device::drvdata::<T>()` would always fail in that case. That is why we
> > > > need a "rust_private_data" for this abstraction to store the
> > > > `Completion` and `bool`.
> > >
> > > So why is this any different from any other bus type? I don't see the
> > > "uniqueness" here that has not required this to happen for PCI or USB or
> > > anything else.
> > >
> > > What am I missing?
> > In Short:
> > In serdev, we have to handle incoming device data (serdev calls on a
> > function pointer we provide in advance), even in the case that the
> > driver hasn't completed probe yet.
>
> But how is that any different from a USB or PCI driver doing the same
> thing? Why is serdev so unique here?
>
In PCI or USB we don't need to provide function pointers for callbacks
in advance, which will be can be called any time (even while probe).
> What specific serdev function
> causes this
>
drivers/tty/serdev/serdev-ttyport.c basically only wraps the serdev
calls to tty calls. This isn't directly caused by a serdev function,
but by the tty part.
> why isn't it an issue with the C api?
>
In C you can set the drvdata inside the probe and even with it not
being fully initialized.
With Rust the drvdata is only available after the probe.
But there is the posibility of serdev calling the provided callback
inside probe.
> Can we change the
> C code to not require this?
Serdev is very closely linked to tty.
There are 3 options:
1. Add a `rust_serdev_device_open` and `rust_serdev_device_ready`
function. `rust_serdev_device_open` would do the same thing as
`serdev_device_open`, but with calling `tty_buffer_lock_exclusive`
before opening the underlying tty port. `rust_serdev_device_ready`
would call `tty_buffer_unlock_exclusive`. Such functions would then
need to exist for every serdev controller (currently there is only
ttyport as serdev controller).
2. Rewrite parts of the tty subsystem.
Not sure what would need to be changed there yet. But this could also
affect the existing tty drivers, which are a lot in comparision to
serdev.
3. Keep the `rust_private_data` pointer in `serdev_device`.
This seems to be the simplest option to me.
Thanks
- Markus Probst
>
> thanks,
>
> greg k-h
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/4] serdev: add rust private data to serdev_device
From: Greg Kroah-Hartman @ 2026-03-20 16:59 UTC (permalink / raw)
To: Markus Probst
Cc: Rob Herring, Jiri Slaby, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, linux-serial, linux-kernel, rust-for-linux,
linux-pm, driver-core, dri-devel
In-Reply-To: <9e07a53053d1dd75a4ebe94aaa06e2279ef3701d.camel@posteo.de>
On Fri, Mar 20, 2026 at 04:53:09PM +0000, Markus Probst wrote:
> On Sat, 2026-03-14 at 14:31 +0100, Greg Kroah-Hartman wrote:
> > On Sat, Mar 14, 2026 at 12:08:09PM +0000, Markus Probst wrote:
> > > On Sat, 2026-03-14 at 12:52 +0100, Greg Kroah-Hartman wrote:
> > > > On Sat, Mar 14, 2026 at 11:42:02AM +0000, Markus Probst wrote:
> > > > > On Sat, 2026-03-14 at 09:07 +0100, Greg Kroah-Hartman wrote:
> > > > > > On Fri, Mar 13, 2026 at 06:12:31PM +0000, Markus Probst wrote:
> > > > > > > Add rust private data to `struct serdev_device`, as it is required by the
> > > > > > > rust abstraction added in the following commit
> > > > > > > (rust: add basic serial device bus abstractions).
> > > > > >
> > > > > > why is rust "special" here? What's wrong with the existing private
> > > > > > pointer in this structure? Why must we add another one?
> > > > > Because in rust, the device drvdata will be set after probe has run. In
> > > > > serdev, once the device has been opened, it can receive data. It must
> > > > > be opened either inside probe or before probe, because it can only be
> > > > > configured (baudrate, flow control etc.) and data written to after it
> > > > > has been opened. Because it can receive data before drvdata has been
> > > > > set yet, we need to ensure it waits on data receival for the probe to
> > > > > be finished. Otherwise this would be a null pointer dereference. To do
> > > > > this, we need to store a `Completion` for it to wait and a `bool` in
> > > > > case the probe exits with an error. We cannot store this data in the
> > > > > device drvdata, because this is where the drivers drvdata goes. We also
> > > > > cannot create a wrapper of the drivers drvdata, because
> > > > > `Device::drvdata::<T>()` would always fail in that case. That is why we
> > > > > need a "rust_private_data" for this abstraction to store the
> > > > > `Completion` and `bool`.
> > > >
> > > > So why is this any different from any other bus type? I don't see the
> > > > "uniqueness" here that has not required this to happen for PCI or USB or
> > > > anything else.
> > > >
> > > > What am I missing?
> > > In Short:
> > > In serdev, we have to handle incoming device data (serdev calls on a
> > > function pointer we provide in advance), even in the case that the
> > > driver hasn't completed probe yet.
> >
> > But how is that any different from a USB or PCI driver doing the same
> > thing? Why is serdev so unique here?
> >
> In PCI or USB we don't need to provide function pointers for callbacks
> in advance, which will be can be called any time (even while probe).
All class drivers are like this, once you register with them, the
function pointers you provide can be called before your probe call ends.
So this isn't unique as far as I can tell.
> > What specific serdev function
> > causes this
> >
> drivers/tty/serdev/serdev-ttyport.c basically only wraps the serdev
> calls to tty calls. This isn't directly caused by a serdev function,
> but by the tty part.
>
> > why isn't it an issue with the C api?
> >
> In C you can set the drvdata inside the probe and even with it not
> being fully initialized.
>
> With Rust the drvdata is only available after the probe.
> But there is the posibility of serdev calling the provided callback
> inside probe.
Other classes have this same issue, so why isn't this a problem for HID
and input and the like?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/4] serdev: add rust private data to serdev_device
From: Markus Probst @ 2026-03-20 17:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, Jiri Slaby, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, linux-serial, linux-kernel, rust-for-linux,
linux-pm, driver-core, dri-devel
In-Reply-To: <2026032048-curtly-refold-e4df@gregkh>
[-- Attachment #1: Type: text/plain, Size: 4104 bytes --]
On Fri, 2026-03-20 at 17:59 +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 20, 2026 at 04:53:09PM +0000, Markus Probst wrote:
> > On Sat, 2026-03-14 at 14:31 +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Mar 14, 2026 at 12:08:09PM +0000, Markus Probst wrote:
> > > > On Sat, 2026-03-14 at 12:52 +0100, Greg Kroah-Hartman wrote:
> > > > > On Sat, Mar 14, 2026 at 11:42:02AM +0000, Markus Probst wrote:
> > > > > > On Sat, 2026-03-14 at 09:07 +0100, Greg Kroah-Hartman wrote:
> > > > > > > On Fri, Mar 13, 2026 at 06:12:31PM +0000, Markus Probst wrote:
> > > > > > > > Add rust private data to `struct serdev_device`, as it is required by the
> > > > > > > > rust abstraction added in the following commit
> > > > > > > > (rust: add basic serial device bus abstractions).
> > > > > > >
> > > > > > > why is rust "special" here? What's wrong with the existing private
> > > > > > > pointer in this structure? Why must we add another one?
> > > > > > Because in rust, the device drvdata will be set after probe has run. In
> > > > > > serdev, once the device has been opened, it can receive data. It must
> > > > > > be opened either inside probe or before probe, because it can only be
> > > > > > configured (baudrate, flow control etc.) and data written to after it
> > > > > > has been opened. Because it can receive data before drvdata has been
> > > > > > set yet, we need to ensure it waits on data receival for the probe to
> > > > > > be finished. Otherwise this would be a null pointer dereference. To do
> > > > > > this, we need to store a `Completion` for it to wait and a `bool` in
> > > > > > case the probe exits with an error. We cannot store this data in the
> > > > > > device drvdata, because this is where the drivers drvdata goes. We also
> > > > > > cannot create a wrapper of the drivers drvdata, because
> > > > > > `Device::drvdata::<T>()` would always fail in that case. That is why we
> > > > > > need a "rust_private_data" for this abstraction to store the
> > > > > > `Completion` and `bool`.
> > > > >
> > > > > So why is this any different from any other bus type? I don't see the
> > > > > "uniqueness" here that has not required this to happen for PCI or USB or
> > > > > anything else.
> > > > >
> > > > > What am I missing?
> > > > In Short:
> > > > In serdev, we have to handle incoming device data (serdev calls on a
> > > > function pointer we provide in advance), even in the case that the
> > > > driver hasn't completed probe yet.
> > >
> > > But how is that any different from a USB or PCI driver doing the same
> > > thing? Why is serdev so unique here?
> > >
> > In PCI or USB we don't need to provide function pointers for callbacks
> > in advance, which will be can be called any time (even while probe).
>
> All class drivers are like this, once you register with them, the
> function pointers you provide can be called before your probe call ends.
> So this isn't unique as far as I can tell.
>
> > > What specific serdev function
> > > causes this
> > >
> > drivers/tty/serdev/serdev-ttyport.c basically only wraps the serdev
> > calls to tty calls. This isn't directly caused by a serdev function,
> > but by the tty part.
> >
> > > why isn't it an issue with the C api?
> > >
> > In C you can set the drvdata inside the probe and even with it not
> > being fully initialized.
> >
> > With Rust the drvdata is only available after the probe.
> > But there is the posibility of serdev calling the provided callback
> > inside probe.
>
> Other classes have this same issue, so why isn't this a problem for HID
> and input and the like?
This is unique for a bus device.
A class device has its own Data (e. g. PwmOps), i. e. it will only be
registered after this Data has been initialized by the driver.
The receive_buf callback on the serdev device on the other hand must
happen on the drvdata, as there is no place to store its own Data.
The drvdata is only available at the end of the probe in Rust.
Thanks
- Markus Probst
>
> thanks,
>
> greg k-h
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [GIT PULL] TTY/Serial driver fixes for 7.0-rc5
From: Greg KH @ 2026-03-20 17:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jiri Slaby, Andrew Morton, linux-kernel, linux-serial
The following changes since commit 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681:
Linux 7.0-rc3 (2026-03-08 16:56:54 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-7.0-rc5
for you to fetch changes up to 5eb608319bb56464674a71b4a66ea65c6c435d64:
vt: save/restore unicode screen buffer for alternate screen (2026-03-13 09:15:58 +0100)
----------------------------------------------------------------
TTY/Serial fixes for 7.0-rc5
Here are some small tty/vt and serial driver fixes for 7.0-rc5.
Included in here are:
- 8250 driver fixes for reported problems
- serial core lockup fix
- uartlite driver bugfix
- vt save/restore bugfix
All of these have been in linux-next for over a week with no reported
problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Ilpo Järvinen (7):
serial: 8250: Protect LCR write in shutdown
serial: 8250_dw: Avoid unnecessary LCR writes
serial: 8250: Add serial8250_handle_irq_locked()
serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling
serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm
serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY
serial: 8250_dw: Ensure BUSY is deasserted
Jiayuan Chen (1):
serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN
Maciej Andrzejewski ICEYE (1):
serial: uartlite: fix PM runtime usage count underflow on probe
Martin Roukala (né Peres) (1):
serial: 8250_pci: add support for the AX99100
Nicolas Pitre (1):
vt: save/restore unicode screen buffer for alternate screen
Peng Zhang (1):
serial: 8250: always disable IRQ during THRE test
Raul E Rangel (1):
serial: 8250: Fix TX deadlock when using DMA
drivers/tty/serial/8250/8250.h | 25 +++
drivers/tty/serial/8250/8250_dma.c | 15 ++
drivers/tty/serial/8250/8250_dw.c | 304 ++++++++++++++++++++++++++++--------
drivers/tty/serial/8250/8250_pci.c | 17 ++
drivers/tty/serial/8250/8250_port.c | 75 +++++----
drivers/tty/serial/serial_core.c | 5 +-
drivers/tty/serial/uartlite.c | 1 +
drivers/tty/vt/vt.c | 8 +
include/linux/console_struct.h | 1 +
include/linux/serial_8250.h | 1 +
10 files changed, 356 insertions(+), 96 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] TTY/Serial driver fixes for 7.0-rc5
From: pr-tracker-bot @ 2026-03-20 19:12 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jiri Slaby, Andrew Morton, linux-kernel,
linux-serial
In-Reply-To: <ab2DKnELM8LPfew8@kroah.com>
The pull request you sent on Fri, 20 Mar 2026 18:26:02 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-7.0-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d46d5c8383442ae44c3b782f87719990ac67925b
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v3 2/4] serdev: add rust private data to serdev_device
From: Danilo Krummrich @ 2026-03-20 19:59 UTC (permalink / raw)
To: Markus Probst
Cc: Greg Kroah-Hartman, Rob Herring, Jiri Slaby, Miguel Ojeda,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Kari Argillander, Rafael J. Wysocki,
Viresh Kumar, Boqun Feng, David Airlie, Simona Vetter,
linux-serial, linux-kernel, rust-for-linux, linux-pm, driver-core,
dri-devel
In-Reply-To: <4f4c09d683023df9daef89ca634b17b5c16625f7.camel@posteo.de>
On 3/20/26 6:13 PM, Markus Probst wrote:
> This is unique for a bus device.
>
> A class device has its own Data (e. g. PwmOps), i. e. it will only be
> registered after this Data has been initialized by the driver.
>
> The receive_buf callback on the serdev device on the other hand must
> happen on the drvdata, as there is no place to store its own Data.
>
> The drvdata is only available at the end of the probe in Rust.
In other words, devm_serdev_device_open() relies on the driver having its
private data set before this is called, since once devm_serdev_device_open() has
been called, the driver's receive_buf() callback may be called.
So, in C it is the driver's responsibility to do things in the correct order, in
Rust we want to make sure the driver can't do it out of order in the first place.
I'm still not sure whether the current approach is the best option. For
instance, we could also solve this with a separate callback. (Wasn't this even
what you had in a previous version?)
^ permalink raw reply
* Re: [PATCH v3 2/4] serdev: add rust private data to serdev_device
From: Markus Probst @ 2026-03-20 21:08 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Greg Kroah-Hartman, Rob Herring, Jiri Slaby, Miguel Ojeda,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Kari Argillander, Rafael J. Wysocki,
Viresh Kumar, Boqun Feng, David Airlie, Simona Vetter,
linux-serial, linux-kernel, rust-for-linux, linux-pm, driver-core,
dri-devel
In-Reply-To: <b8465b11-7a4a-4842-b292-6e3659bd95b3@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Fri, 2026-03-20 at 20:59 +0100, Danilo Krummrich wrote:
> On 3/20/26 6:13 PM, Markus Probst wrote:
> > This is unique for a bus device.
> >
> > A class device has its own Data (e. g. PwmOps), i. e. it will only be
> > registered after this Data has been initialized by the driver.
> >
> > The receive_buf callback on the serdev device on the other hand must
> > happen on the drvdata, as there is no place to store its own Data.
> >
> > The drvdata is only available at the end of the probe in Rust.
>
> In other words, devm_serdev_device_open() relies on the driver having its
> private data set before this is called, since once devm_serdev_device_open() has
> been called, the driver's receive_buf() callback may be called.
>
> So, in C it is the driver's responsibility to do things in the correct order, in
> Rust we want to make sure the driver can't do it out of order in the first place.
>
> I'm still not sure whether the current approach is the best option. For
> instance, we could also solve this with a separate callback.
>
> Wasn't this even
> what you had in a previous version?
Yes, but Kari pointed out that changing the ops while it is in use is
unsafe [1].
Thanks
- Markus Probst
[1]
https://lore.kernel.org/rust-for-linux/CAC=eVgR2WYdDTW3kOeemyQPP-H0aAUsrzn5Gk5zCe2hQEB709w@mail.gmail.com/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [PATCH v1 1/1] serial: xilinx_uartps: Drop unused include
From: Andy Shevchenko @ 2026-03-20 22:08 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel, linux-serial, linux-arm-kernel
Cc: Jiri Slaby, Michal Simek, Andy Shevchenko
This driver includes the legacy header <linux/gpio.h> but does
not use any symbols from it. Drop the inclusion.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/tty/serial/xilinx_uartps.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index c593d20a1b5b..a072b75dbaf2 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -22,7 +22,6 @@
#include <linux/of.h>
#include <linux/module.h>
#include <linux/pm_runtime.h>
-#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
#include <linux/delay.h>
#include <linux/reset.h>
--
2.50.1
^ permalink raw reply related
* [PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write
From: yuhaocheng035 @ 2026-03-21 6:23 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Nicolas Pitre, linux-kernel, linux-serial, Calixte Pernot
From: Haocheng Yu <yuhaocheng035@gmail.com>
A KASAN: slab-out-of-bounds Write in do_con_write issue is reported by
a modified Syzkaller-based kernel fuzzing tool that we developed. The
report indicates the problem lies in vc_con_write_normal
drivers/tty/vt/vt.c:3141(scr_writew(tc, (u16*)vc->vc_pos)), which writes
2 bytes to the right of the allocated region at 2634 bytes.
Since it did not provide any repro program or enough information,
the cause remains unclear. However, adding a validity check of vc->vc_pos
before scr_writew should avoid this issue.
Signed-off-by: Haocheng Yu <yuhaocheng035@gmail.com>
---
drivers/tty/vt/vt.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 6e0089b85c27..95d860f09837 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3138,6 +3138,13 @@ static int vc_con_write_normal(struct vc_data *vc, int tc, int c,
(tc & 0xff);
tc |= (vc_attr << 8) & ~himask;
+ unsigned long end = vc->vc_origin + vc->vc_screenbuf_size;
+
+ if (WARN_ON_ONCE(vc->vc_screenbuf_size < 2 ||
+ end < vc->vc_origin ||
+ vc->vc_pos < vc->vc_origin ||
+ vc->vc_pos > end - 2))
+ return -1;
+
scr_writew(tc, (u16 *)vc->vc_pos);
if (con_should_update(vc) && draw->x < 0) {
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write
From: Greg Kroah-Hartman @ 2026-03-21 6:32 UTC (permalink / raw)
To: yuhaocheng035
Cc: Jiri Slaby, Nicolas Pitre, linux-kernel, linux-serial,
Calixte Pernot
In-Reply-To: <20260321062312.4290-1-yuhaocheng035@gmail.com>
On Sat, Mar 21, 2026 at 02:23:12PM +0800, yuhaocheng035@gmail.com wrote:
> From: Haocheng Yu <yuhaocheng035@gmail.com>
>
> A KASAN: slab-out-of-bounds Write in do_con_write issue is reported by
> a modified Syzkaller-based kernel fuzzing tool that we developed. The
> report indicates the problem lies in vc_con_write_normal
> drivers/tty/vt/vt.c:3141(scr_writew(tc, (u16*)vc->vc_pos)), which writes
> 2 bytes to the right of the allocated region at 2634 bytes.
>
> Since it did not provide any repro program or enough information,
> the cause remains unclear. However, adding a validity check of vc->vc_pos
> before scr_writew should avoid this issue.
>
> Signed-off-by: Haocheng Yu <yuhaocheng035@gmail.com>
What commit caused this problem to show up?
And without more information, or a reproducer, I'm a bit loath to take
this change.
> ---
> drivers/tty/vt/vt.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 6e0089b85c27..95d860f09837 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3138,6 +3138,13 @@ static int vc_con_write_normal(struct vc_data *vc, int tc, int c,
> (tc & 0xff);
> tc |= (vc_attr << 8) & ~himask;
>
> + unsigned long end = vc->vc_origin + vc->vc_screenbuf_size;
Ideally do not create new variables in the middle of a function,
checkpatch should have warned about this.
> +
> + if (WARN_ON_ONCE(vc->vc_screenbuf_size < 2 ||
> + end < vc->vc_origin ||
> + vc->vc_pos < vc->vc_origin ||
> + vc->vc_pos > end - 2))
That's not good, if panic-on-warn is enabled, as it is in a few billion
Linux systems, you just rebooted the machine, turning a simple overwrite
into a denial-of-service, not fixing anything at all, but making it
worse :(
> + return -1;
Do not make up error numbers :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] tty: vt: Fix slab-out-of-bounds write in do_con_write
From: Greg Kroah-Hartman @ 2026-03-21 6:37 UTC (permalink / raw)
To: yuhaocheng035
Cc: Jiri Slaby, Nicolas Pitre, linux-kernel, linux-serial,
Calixte Pernot
In-Reply-To: <2026032123-earplugs-stunning-0c6f@gregkh>
On Sat, Mar 21, 2026 at 07:32:34AM +0100, Greg Kroah-Hartman wrote:
> > + return -1;
>
> Do not make up error numbers :(
Ah, I see this value being returned elsewhere in this function,
nevermind, my fault. But really, it should be an -ERROR value, not just
-1.
thanks,
greg k-h
^ 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