* Re: [PATCH v5 8/8] ARM: defconfig: Add a zx29 defconfig file
From: Linus Walleij @ 2026-04-24 7:13 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260421-send-v5-8-ace038e63515@gmail.com>
On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> This enables existing drivers that already are (UART) or will be (USB,
> GPIO) necessary to operate this board even if they aren't declared in
> the DTS yet.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
*I* personally (as SoC maintainer) think that having a few more defconfigs
is fine, even helpful.
But I would defer this to the more senior SoC maintainers because I think
their stance is something like:
- We have multi_v7_defconfig for compile testing
- We know that binary gets way to big for your system: it's for build
testing and perhaps booting in QEMU or systems with many MB of
RAM, not for actually running it on products.
- You are encouraged to keep your own defconfig out-of-tree.
However I even challenged this myself by adding a defconfig for memory
constrained Broadcoms a while back (NACKed/ignored ;) so if it was all
up to me I would merge this.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 8/8] ARM: defconfig: Add a zx29 defconfig file
From: Arnd Bergmann @ 2026-04-24 7:48 UTC (permalink / raw)
To: Stefan Dösinger, Jonathan Corbet, Shuah Khan, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial
In-Reply-To: <20260421-send-v5-8-ace038e63515@gmail.com>
On Tue, Apr 21, 2026, at 22:23, Stefan Dösinger wrote:
> This enables existing drivers that already are (UART) or will be (USB,
> GPIO) necessary to operate this board even if they aren't declared in
> the DTS yet.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
I'll reply to Linus' comment as well, the defconfigs are generally
not in a great shape across many platforms, so we should come up
with some better policies there.
Either way, the patch description above should at least explain
why you think you need your own defconfig, as we don't normally
take those.
Some comments about the contents of this file:
> +++ b/arch/arm/configs/zx29_defconfig
> @@ -0,0 +1,89 @@
> +CONFIG_SYSVIPC=y
> +CONFIG_BLK_DEV_INITRD=y
> +# CONFIG_RD_BZIP2 is not set
> +# CONFIG_RD_LZMA is not set
> +# CONFIG_RD_XZ is not set
> +# CONFIG_RD_LZ4 is not set
> +CONFIG_EXPERT=y
What is the reason for CONFIG_EXPERT here? Can you avoid this?
> +CONFIG_CMDLINE="console=ttyAMA0 earlyprintk root=/dev/ram rw"
A definconfig should normall not rely on earlyprintk, just add
that when you actually need to debug the super-early boot
stages. With "earlycon" it should pick up the right console
from the stdout path and work almost as early.
> +CONFIG_BINFMT_FLAT=y
Are you actually using flat binaries? I wasn't aware that this
is still possible on MMU-enabled kernels.
> +CONFIG_BLK_DEV_RAM=y
> +CONFIG_BLK_DEV_RAM_COUNT=4
The old ramdisk boot is going away in the future, please use
initramfs instead. This should also save a good amount of RAM.
> +CONFIG_DEVTMPFS=y # FIXME: This is specific to my initrd. Remove
> before upstream
stale comment?
> +CONFIG_CONFIG_TMPFS=y
Typo?
Arnd
^ permalink raw reply
* Re: [PATCH] serial: 8250_accent: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 8:49 UTC (permalink / raw)
To: Jiri Slaby
Cc: Greg Kroah-Hartman, Russell King, linux-kernel, linux-serial,
stable
In-Reply-To: <463cec4f-a038-4bd0-90df-76e0ef48381c@kernel.org>
Hi Jiri,
Please disregard this patch.
On Thu, 16 Apr 2026 at 14:14, Jiri Slaby <jirislaby@kernel.org> wrote:
>
> Hi,
>
> On 15. 04. 26, 20:34, Guangshuo Li wrote:
> > When platform_device_register() fails in accent_init(), the embedded
> > struct device in accent_device has already been initialized by
> > device_initialize(), but the failure path returns the error without
> > dropping the device reference for the current platform device:
> >
> > accent_init()
> > -> platform_device_register(&accent_device)
> > -> device_initialize(&accent_device.dev)
> > -> setup_pdev_dma_masks(&accent_device)
> > -> platform_device_add(&accent_device)
> >
> > This leads to a reference leak when platform_device_register() fails.
>
> What reference exactly?
>
> > Fix this by calling platform_device_put() before returning the error.
> >
> > The issue was identified by a static analysis tool I developed and
> > confirmed by manual review.
>
> How did you verify you did the right change?
>
> > Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > ---
> > drivers/tty/serial/8250/8250_accent.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250_accent.c b/drivers/tty/serial/8250/8250_accent.c
> > index 1691f1a57f89..e9cf40268c0e 100644
> > --- a/drivers/tty/serial/8250/8250_accent.c
> > +++ b/drivers/tty/serial/8250/8250_accent.c
> > @@ -25,7 +25,13 @@ static struct platform_device accent_device = {
> >
> > static int __init accent_init(void)
> > {
> > - return platform_device_register(&accent_device);
> > + int ret;
> > +
> > + ret = platform_device_register(&accent_device);
> > + if (ret)
> > + platform_device_put(&accent_device);
>
> In particular, what does put_device() do on a static device, even
> initialized, ie. with no device::release? Try it...
>
> IMO, all the patches are bogus.
>
> thanks,
> --
> js
> suse labs
After re-checking it, accent_device is a static platform_device and it
does not provide a dev.release callback, so calling platform_device_put()
on the platform_device_register() failure path is not appropriate and can
trigger the missing release callback warning.
This falls into the same static platform_device pattern as the other
patches, so I will drop it.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: [PATCH] serial: 8250_boca: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 8:50 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Russell King,
linux-kernel, linux-serial
In-Reply-To: <20260415183756.3770073-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 02:38, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in boca_init(), the embedded
> struct device in boca_device has already been initialized by
> device_initialize(), but the failure path returns the error without
> dropping the device reference for the current platform device:
>
> boca_init()
> -> platform_device_register(&boca_device)
> -> device_initialize(&boca_device.dev)
> -> setup_pdev_dma_masks(&boca_device)
> -> platform_device_add(&boca_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before returning the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/tty/serial/8250/8250_boca.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_boca.c b/drivers/tty/serial/8250/8250_boca.c
> index a9b97c034653..70ea8e30ae80 100644
> --- a/drivers/tty/serial/8250/8250_boca.c
> +++ b/drivers/tty/serial/8250/8250_boca.c
> @@ -39,7 +39,13 @@ static struct platform_device boca_device = {
>
> static int __init boca_init(void)
> {
> - return platform_device_register(&boca_device);
> + int ret;
> +
> + ret = platform_device_register(&boca_device);
> + if (ret)
> + platform_device_put(&boca_device);
> +
> + return ret;
> }
>
> module_init(boca_init);
> --
> 2.43.0
>
After re-checking it, boca_device is a static platform_device and it does
not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: [PATCH] serial: 8250_exar_st16c554: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 8:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Paul B Schroeder,
Andrew Morton, linux-kernel, linux-serial
In-Reply-To: <20260415184032.3776292-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 02:40, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in exar_init(), the embedded
> struct device in exar_device has already been initialized by
> device_initialize(), but the failure path returns the error without
> dropping the device reference for the current platform device:
>
> exar_init()
> -> platform_device_register(&exar_device)
> -> device_initialize(&exar_device.dev)
> -> setup_pdev_dma_masks(&exar_device)
> -> platform_device_add(&exar_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before returning the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: e0980dafa329d ("[PATCH] Exar quad port serial")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/tty/serial/8250/8250_exar_st16c554.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_exar_st16c554.c b/drivers/tty/serial/8250/8250_exar_st16c554.c
> index 933811ebfaac..b2c37f0c52aa 100644
> --- a/drivers/tty/serial/8250/8250_exar_st16c554.c
> +++ b/drivers/tty/serial/8250/8250_exar_st16c554.c
> @@ -30,7 +30,13 @@ static struct platform_device exar_device = {
>
> static int __init exar_init(void)
> {
> - return platform_device_register(&exar_device);
> + int ret;
> +
> + ret = platform_device_register(&exar_device);
> + if (ret)
> + platform_device_put(&exar_device);
> +
> + return ret;
> }
>
> module_init(exar_init);
> --
> 2.43.0
>
After re-checking it, exar_device is a static platform_device and it does
not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: [PATCH] serial: 8250_fourport: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 8:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Russell King,
linux-kernel, linux-serial
In-Reply-To: <20260415184839.3796326-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 02:48, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in fourport_init(), the embedded
> struct device in fourport_device has already been initialized by
> device_initialize(), but the failure path returns the error without
> dropping the device reference for the current platform device:
>
> fourport_init()
> -> platform_device_register(&fourport_device)
> -> device_initialize(&fourport_device.dev)
> -> setup_pdev_dma_masks(&fourport_device)
> -> platform_device_add(&fourport_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before returning the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/tty/serial/8250/8250_fourport.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_fourport.c b/drivers/tty/serial/8250/8250_fourport.c
> index 3215b9b7afde..a65bc7316655 100644
> --- a/drivers/tty/serial/8250/8250_fourport.c
> +++ b/drivers/tty/serial/8250/8250_fourport.c
> @@ -34,7 +34,13 @@ static struct platform_device fourport_device = {
>
> static int __init fourport_init(void)
> {
> - return platform_device_register(&fourport_device);
> + int ret;
> +
> + ret = platform_device_register(&fourport_device);
> + if (ret)
> + platform_device_put(&fourport_device);
> +
> + return ret;
> }
>
> module_init(fourport_init);
> --
> 2.43.0
>
After re-checking it, fourport_device is a static platform_device and it
does not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: [PATCH v5 8/8] ARM: defconfig: Add a zx29 defconfig file
From: Arnd Bergmann @ 2026-04-24 8:54 UTC (permalink / raw)
To: Linus Walleij, Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alexandre Belloni, Drew Fustini, Greg Kroah-Hartman, Jiri Slaby,
linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial
In-Reply-To: <CAD++jL=_eDY_mG_QBreSrZiho0hUrDSciedq=vrxXaTiMwrSyg@mail.gmail.com>
On Fri, Apr 24, 2026, at 09:13, Linus Walleij wrote:
> On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
> <stefandoesinger@gmail.com> wrote:
>
>> This enables existing drivers that already are (UART) or will be (USB,
>> GPIO) necessary to operate this board even if they aren't declared in
>> the DTS yet.
>>
>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> *I* personally (as SoC maintainer) think that having a few more defconfigs
> is fine, even helpful.
>
> But I would defer this to the more senior SoC maintainers because I think
> their stance is something like:
>
> - We have multi_v7_defconfig for compile testing
>
> - We know that binary gets way to big for your system: it's for build
> testing and perhaps booting in QEMU or systems with many MB of
> RAM, not for actually running it on products.
>
> - You are encouraged to keep your own defconfig out-of-tree.
Right, we clearly need to do something better than what we are with
the general defconfigs, as I'm sure many of the existing ones are
never actually used for booting a machine, and are horribly out of
date with the Kconfig options.
I wouldn't object to adding another defconfig for a new (or revived)
soc family, but I don't want to have more per-board ones.
Overall, we have about 70 defconfigs and 55 soc families that have their
own mach-* directory (plus a few without code), and the number of
defconfigs alone makes it hard to keep them up to date.
> However I even challenged this myself by adding a defconfig for memory
> constrained Broadcoms a while back (NACKed/ignored ;) so if it was all
> up to me I would merge this.
I don't even remember that discussion ;-)
One idea might be to have a tiny base defconfig, plus platform
specific fragments that add drivers. The problem is agreeing
what bits are essential enough to still get enabled in the
tiny config.
Arnd
^ permalink raw reply
* Re: [PATCH] serial: 8250_hub6: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 8:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Russell King,
linux-kernel, linux-serial
In-Reply-To: <20260415185339.3804023-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 02:53, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in hub6_init(), the embedded
> struct device in hub6_device has already been initialized by
> device_initialize(), but the failure path returns the error without
> dropping the device reference for the current platform device:
>
> hub6_init()
> -> platform_device_register(&hub6_device)
> -> device_initialize(&hub6_device.dev)
> -> setup_pdev_dma_masks(&hub6_device)
> -> platform_device_add(&hub6_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before returning the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/tty/serial/8250/8250_hub6.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_hub6.c b/drivers/tty/serial/8250/8250_hub6.c
> index 273f59b9bca5..005dd6bec3da 100644
> --- a/drivers/tty/serial/8250/8250_hub6.c
> +++ b/drivers/tty/serial/8250/8250_hub6.c
> @@ -43,9 +43,14 @@ static struct platform_device hub6_device = {
>
> static int __init hub6_init(void)
> {
> - return platform_device_register(&hub6_device);
> -}
> + int ret;
> +
> + ret = platform_device_register(&hub6_device);
> + if (ret)
> + platform_device_put(&hub6_device);
>
> + return ret;
> +}
> module_init(hub6_init);
>
> MODULE_AUTHOR("Russell King");
> --
> 2.43.0
>
After re-checking it, hub6_device is a static platform_device and it does
not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: [PATCH v4 0/4] serial: 8250_dw: Add support for UltraRISC DP1000 UART
From: Andy Shevchenko @ 2026-04-24 9:58 UTC (permalink / raw)
To: Jia Wang
Cc: Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-serial,
linux-riscv, devicetree, Conor Dooley
In-Reply-To: <20260424-ultrarisc-serial-v4-0-1765a0b4c4a0@ultrarisc.com>
On Fri, Apr 24, 2026 at 01:39:27PM +0800, Jia Wang wrote:
> This patch series adds support for the UltraRISC DP1000 UART controller.
>
> The series includes four patches. The first two are preparatory cleanups;
> the last two add the DP1000 compatible and fixed CPR handling.
>
> The patches have been tested on an UltraRISC DP1000 development board with
> Linux v7.0-rc7, verifying basic UART functionality.
Now it looks good to me, thanks!
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(except DT bindings, not an expert, no tag)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Alim Akhtar @ 2026-04-24 10:18 UTC (permalink / raw)
To: krzk, gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <CGME20260424100201epcas5p371dd69955076938ee41ed0d823433056@epcas5p3.samsung.com>
Currently Exynosautov-{9,920} getting probed based on exynos850
fallback. It is recommended to have a dedicated compatible for
proper driver binding.
Add specific platfrom_device_id and of_device_id for
unique identification and proper driver binding.
While at it, also declare earlycon for these SoC which is helpful
in debugging early kernel crashes which might occures before
serial driver initialization.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
drivers/tty/serial/samsung_tty.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index e27806bf2cf3..49409cb6fd25 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2500,6 +2500,12 @@ static const struct s3c24xx_serial_drv_data exynos8895_serial_drv_data = {
.fifosize = { 0 },
};
+static const struct s3c24xx_serial_drv_data exynosauto_serial_drv_data = {
+ EXYNOS_COMMON_SERIAL_DRV_DATA,
+ /* samsung,uart-fifosize must be specified in the device tree. */
+ .fifosize = { 0 },
+};
+
static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
.info = {
.name = "Google GS101 UART",
@@ -2531,6 +2537,7 @@ static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
#define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
#define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
#define EXYNOS8895_SERIAL_DRV_DATA (&exynos8895_serial_drv_data)
+#define EXYNOSAUTO_SERIAL_DRV_DATA (&exynosauto_serial_drv_data)
#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)
#else
@@ -2538,6 +2545,7 @@ static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
#define EXYNOS5433_SERIAL_DRV_DATA NULL
#define EXYNOS850_SERIAL_DRV_DATA NULL
#define EXYNOS8895_SERIAL_DRV_DATA NULL
+#define EXYNOSAUTO_SERIAL_DRV_DATA NULL
#define GS101_SERIAL_DRV_DATA NULL
#endif
@@ -2621,6 +2629,12 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
}, {
.name = "exynos850-uart",
.driver_data = (kernel_ulong_t)EXYNOS850_SERIAL_DRV_DATA,
+ }, {
+ .name = "exynosautov9-uart",
+ .driver_data = (kernel_ulong_t)EXYNOSAUTO_SERIAL_DRV_DATA,
+ }, {
+ .name = "exynosautov920-uart",
+ .driver_data = (kernel_ulong_t)EXYNOSAUTO_SERIAL_DRV_DATA,
}, {
.name = "artpec8-uart",
.driver_data = (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
@@ -2649,6 +2663,10 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
.data = S5L_SERIAL_DRV_DATA },
{ .compatible = "samsung,exynos850-uart",
.data = EXYNOS850_SERIAL_DRV_DATA },
+ { .compatible = "samsung,exynosautov9-uart",
+ .data = EXYNOSAUTO_SERIAL_DRV_DATA },
+ { .compatible = "samsung,exynosautov920-uart",
+ .data = EXYNOSAUTO_SERIAL_DRV_DATA },
{ .compatible = "axis,artpec8-uart",
.data = ARTPEC8_SERIAL_DRV_DATA },
{ .compatible = "google,gs101-uart",
@@ -2826,6 +2844,10 @@ OF_EARLYCON_DECLARE(artpec8, "axis,artpec8-uart",
s5pv210_early_console_setup);
OF_EARLYCON_DECLARE(exynos850, "samsung,exynos850-uart",
s5pv210_early_console_setup);
+OF_EARLYCON_DECLARE(exynosauto, "samsung,exynosautov9-uart",
+ s5pv210_early_console_setup);
+OF_EARLYCON_DECLARE(exynosauto, "samsung,exynosautov920-uart",
+ s5pv210_early_console_setup);
static int __init gs101_early_console_setup(struct earlycon_device *device,
const char *opt)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 1/4] serial: 8250_dwlib: move DesignWare register definitions to header
From: Andy Shevchenko @ 2026-04-24 10:02 UTC (permalink / raw)
To: Jia Wang
Cc: Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-serial,
linux-riscv, devicetree
In-Reply-To: <20260424-ultrarisc-serial-v4-1-1765a0b4c4a0@ultrarisc.com>
On Fri, Apr 24, 2026 at 01:39:28PM +0800, Jia Wang wrote:
> Move the DW_UART_* register offsets and CPR bit/field definitions from
> 8250_dwlib.c into 8250_dwlib.h so they can be shared by 8250_dw and
> 8250_dwlib users.
>
> Add an include guard for 8250_dwlib.h.
...
> -/* DesignWare specific register fields */
> -#define DW_UART_IIR_IID GENMASK(3, 0)
> -
> -#define DW_UART_MCR_SIRE BIT(6)
> -
> -#define DW_UART_USR_BUSY BIT(0)
> -
One nit-pick, though, these three need the similar comments in the header and a
blank line between them.
...
> +/* Offsets for the DesignWare specific registers */
> +#define DW_UART_USR 0x1f /* UART Status Register */
> +#define DW_UART_DMASA 0xa8 /* DMA Software Ack */
> +#define DW_UART_TCR 0xac /* Transceiver Control Register (RS485) */
> +#define DW_UART_DE_EN 0xb0 /* Driver Output Enable Register */
> +#define DW_UART_RE_EN 0xb4 /* Receiver Output Enable Register */
> +#define DW_UART_DLF 0xc0 /* Divisor Latch Fraction Register */
> +#define DW_UART_RAR 0xc4 /* Receive Address Register */
> +#define DW_UART_TAR 0xc8 /* Transmit Address Register */
> +#define DW_UART_LCR_EXT 0xcc /* Line Extended Control Register */
> +#define DW_UART_CPR 0xf4 /* Component Parameter Register */
> +#define DW_UART_UCV 0xf8 /* UART Component Version */
> +
> +/* Receive / Transmit Address Register bits */
> +#define DW_UART_ADDR_MASK GENMASK(7, 0)
> +/* Line Status Register bits */
> +#define DW_UART_LSR_ADDR_RCVD BIT(8)
Like this one, the IIR. MCR, and USR bits should be commented. Also preserve
the sorting by the register offset, so the groups of bits follow the above list
of registers, where USR bits, for example, should go before TCR.
> +/* Transceiver Control Register bits */
> +#define DW_UART_TCR_RS485_EN BIT(0)
> +#define DW_UART_TCR_RE_POL BIT(1)
> +#define DW_UART_TCR_DE_POL BIT(2)
> +#define DW_UART_TCR_XFER_MODE GENMASK(4, 3)
> +#define DW_UART_TCR_XFER_MODE_DE_DURING_RE FIELD_PREP(DW_UART_TCR_XFER_MODE, 0)
> +#define DW_UART_TCR_XFER_MODE_SW_DE_OR_RE FIELD_PREP(DW_UART_TCR_XFER_MODE, 1)
> +#define DW_UART_TCR_XFER_MODE_DE_OR_RE FIELD_PREP(DW_UART_TCR_XFER_MODE, 2)
> +
> +/* Line Extended Control Register bits */
> +#define DW_UART_LCR_EXT_DLS_E BIT(0)
> +#define DW_UART_LCR_EXT_ADDR_MATCH BIT(1)
> +#define DW_UART_LCR_EXT_SEND_ADDR BIT(2)
> +#define DW_UART_LCR_EXT_TRANSMIT_MODE BIT(3)
> +
> +/* Component Parameter Register bits */
> +#define DW_UART_CPR_ABP_DATA_WIDTH GENMASK(1, 0)
> +#define DW_UART_CPR_AFCE_MODE BIT(4)
> +#define DW_UART_CPR_THRE_MODE BIT(5)
> +#define DW_UART_CPR_SIR_MODE BIT(6)
> +#define DW_UART_CPR_SIR_LP_MODE BIT(7)
> +#define DW_UART_CPR_ADDITIONAL_FEATURES BIT(8)
> +#define DW_UART_CPR_FIFO_ACCESS BIT(9)
> +#define DW_UART_CPR_FIFO_STAT BIT(10)
> +#define DW_UART_CPR_SHADOW BIT(11)
> +#define DW_UART_CPR_ENCODED_PARMS BIT(12)
> +#define DW_UART_CPR_DMA_EXTRA BIT(13)
> +#define DW_UART_CPR_FIFO_MODE GENMASK(23, 16)
> +/* DesignWare specific register fields */
> +#define DW_UART_IIR_IID GENMASK(3, 0)
> +#define DW_UART_MCR_SIRE BIT(6)
> +#define DW_UART_USR_BUSY BIT(0)
I.o.w. uncouple these as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 6/9] serial: core: prevent irrelevant I/O infos display for UPIO_BUS
From: Ilpo Järvinen @ 2026-04-24 10:51 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-6-baf82d3b86d1@dimonoff.com>
On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> It doesn't make sense to display irrelevant MMIO or legacy I/O information
> for serial devices on I2C or SPI busses. Now that we have a separate I/O
> type for these types of devices, prevent display of I/O information for
> them. Using uart_iotype_*() functions to do so also addresses the now
> invalid check for "iotype >= UPIO_MEM".
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> drivers/tty/serial/serial_core.c | 50 ++++++++++++++++++----------------------
> 1 file changed, 22 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 0bfdb69817e4259681fbc4658c9a68200aa2b65f..42559eda6fc134de77c3a7b850d565ebdc89e216 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -2011,13 +2011,18 @@ static void uart_line_info(struct seq_file *m, struct uart_state *state)
> if (!uport)
> return;
>
> - mmio = uport->iotype >= UPIO_MEM;
> - seq_printf(m, "%u: uart:%s %s%08llX irq:%u",
> - uport->line, uart_type(uport),
> - mmio ? "mmio:0x" : "port:",
> - mmio ? (unsigned long long)uport->mapbase
> - : (unsigned long long)uport->iobase,
> - uport->irq);
> + seq_printf(m, "%u: uart:%s", uport->line, uart_type(uport));
> +
> + mmio = uart_iotype_mmio(uport->iotype);
> +
> + if (mmio || uart_iotype_legacy_io(uport->iotype)) {
> + seq_printf(m, " %s%08llX",
> + mmio ? "mmio:0x" : "port:",
> + mmio ? (unsigned long long)uport->mapbase
> + : (unsigned long long)uport->iobase);
This should align to ?
> + }
> +
> + seq_printf(m, "irq:%u", uport->irq);
>
> if (uport->type == PORT_UNKNOWN) {
> seq_putc(m, '\n');
> @@ -2482,31 +2487,20 @@ EXPORT_SYMBOL(uart_resume_port);
> static inline void
> uart_report_port(struct uart_driver *drv, struct uart_port *port)
> {
> - char address[64];
> + char address[64] = "";
>
> - switch (port->iotype) {
> - case UPIO_PORT:
> - snprintf(address, sizeof(address), "I/O 0x%lx", port->iobase);
> - break;
> - case UPIO_HUB6:
> + if (uart_iotype_mmio(port->iotype))
> snprintf(address, sizeof(address),
> - "I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
> - break;
> - case UPIO_MEM:
> - case UPIO_MEM16:
> - case UPIO_MEM32:
> - case UPIO_MEM32BE:
> - case UPIO_AU:
> - case UPIO_TSI:
> - snprintf(address, sizeof(address),
> - "MMIO 0x%llx", (unsigned long long)port->mapbase);
> - break;
> - default:
> - strscpy(address, "*unknown*", sizeof(address));
> - break;
> + " at MMIO 0x%llx", (unsigned long long)port->mapbase);
> + else if (uart_iotype_legacy_io(port->iotype)) {
> + if (port->iotype == UPIO_PORT)
> + snprintf(address, sizeof(address), " at I/O 0x%lx", port->iobase);
> + else if (port->iotype == UPIO_HUB6)
> + snprintf(address, sizeof(address),
> + " at I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
Please use scnprintf() so we could perhaps one day get rid of snprintf()
entirely.
> }
>
> - pr_info("%s%s%s at %s (irq = %u, base_baud = %u) is a %s\n",
> + pr_info("%s%s%s%s (irq = %u, base_baud = %u) is a %s\n",
> port->dev ? dev_name(port->dev) : "",
> port->dev ? ": " : "",
> port->name,
>
>
--
i.
^ permalink raw reply
* Re: [PATCH 2/9] serial: core: use uart_iotype_*() to simplify code
From: Ilpo Järvinen @ 2026-04-24 11:13 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-2-baf82d3b86d1@dimonoff.com>
On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Make use of new functions uart_iotype_mmio() and uart_iotype_legacy_io()
> to simplify and improve code readability.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> drivers/tty/serial/serial_core.c | 24 +++++++++---------------
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index b1cf45a8fc854cd97e349ff077d83b42e3ef8b16..fc273f8f9e75de89dca1ac1aca3589567bcf8a18 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3221,23 +3221,17 @@ bool uart_match_port(const struct uart_port *port1,
> {
> if (port1->iotype != port2->iotype)
> return false;
> -
> - switch (port1->iotype) {
> - case UPIO_PORT:
> - return port1->iobase == port2->iobase;
> - case UPIO_HUB6:
> - return port1->iobase == port2->iobase &&
> - port1->hub6 == port2->hub6;
> - case UPIO_MEM:
> - case UPIO_MEM16:
> - case UPIO_MEM32:
> - case UPIO_MEM32BE:
> - case UPIO_AU:
> - case UPIO_TSI:
> + else if (uart_iotype_mmio(port1->iotype))
> return port1->mapbase == port2->mapbase;
> - default:
> + else if (uart_iotype_legacy_io(port1->iotype))
> + if (port1->iobase != port2->iobase)
> + return false;
> + else if (port1->iotype == UPIO_HUB6 && port1->hub6 != port2->hub6)
I suggest placing the entire hub6 related check (including the iobase
check) into own function in 8250_hub6.c and add a stub for the case when
hub6 code is not even built into kernel into 8250.h.
> + return false;
> + else
> + return true;
> + else
> return false;
> - }
> }
> EXPORT_SYMBOL(uart_match_port);
>
>
>
--
i.
^ permalink raw reply
* Re: [PATCH v5 1/8] ARM: zte: Add zx297520v3 platform support
From: Stefan Dösinger @ 2026-04-24 11:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <CAD++jL=am0f+sgBSFYQCdcFOvFWgPETn_pSgVdzETJ3_yUNqgw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
> Am 24.04.2026 um 10:06 schrieb Linus Walleij <linusw@kernel.org>:
>
> On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
> <stefandoesinger@gmail.com> wrote:
>
>> This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
>> DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
>> and sold by ISPs themselves. They are widespread in Africa, China,
>> Russia and Eastern Europe.
>>
>> This SoC is a relative of the zx296702 and zx296718 that had some
>> upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
>> platform"). My eventual goal is to enable OpenWRT to run on these
>> devices.
>>
>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> Didn't I review this already? I don't remember, anyway:
> Reviewed-by: Linus Walleij <linusw@kernel.org>
Yes, you did, but the previous version, and after I sent this one.
And if I understand the b4 docs correctly, the Reviewed-by tags are sort of handled client side: I have to tell b4 to fetch trailers, and then it will add it when I send my v6 with Krzysztof's request to squash patches.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] serial: add new I/O type for SPI and I2C bus devices
From: Ilpo Järvinen @ 2026-04-24 11:24 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-0-baf82d3b86d1@dimonoff.com>
[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]
On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
> Hello,
> this patch series add a new I/O type for serial devices on a SPI/I2C bus.
>
> These changes are based on a suggestion [1] made by Ilpo Järvinen during
> past sc16is7xx driver patches review.
Hehe, I didn't even recall suggesting this (nor why) :-).
I like this series. Some, relatively minor, comments on the individual
patches. Thanks for looking into solving this properly.
--
i.
> I decided to use UPIO_BUS/SERIAL_IO_BUS names but maybe other names would
> be more appropriate:
> UPIO_SBUS / SERIAL_IO_SBUS
> UPIO_SERBUS / SERIAL_IO_SERBUS
> UPIO_EXT / SERIAL_IO_EXT
> UPIO_CUSTOM / SERIAL_IO_CUSTOM
> UPIO_REGMAP / SERIAL_IO_REGMAP /* Maybe not always true in future? */
> ...
>
> Tested on a imx6 board with two SC16is752 using SPI mode, and a dummy
> device-tree entry for a MAX3100:
> dmesg -t | grep "base_baud"
> 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 197, base_baud = 5000000) is a IMX
> 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 198, base_baud = 5000000) is a IMX
> spi1.0: ttySC0 (irq = 165, base_baud = 1500000) is a SC16IS752
> spi1.0: ttySC1 (irq = 165, base_baud = 1500000) is a SC16IS752
> spi3.0: ttySC2 (irq = 37, base_baud = 1500000) is a SC16IS752
> spi3.0: ttySC3 (irq = 37, base_baud = 1500000) is a SC16IS752
> spi3.1: ttyMAX0 (irq = 0, base_baud = 0) is a MAX3100
> Note that before these patches, max3100 silently failed in uart_configure_port()
> because membase/iobase/mapbase were zero.
>
> For max310x and SC16is7xx in i2c mode, tested only that driver is properly
> registered by using i2c-stub.
>
> Also tested on a custom board with a Renesas RZ/G2L cpu (sh-sci driver) to
> confirm there is no regression:
> dmesg -t | grep "base_baud"
> 1004b800.serial: ttySC0 at MMIO 0x1004b800 (irq = 35, base_baud = 0) is a scif
> 1004bc00.serial: ttySC1 at MMIO 0x1004bc00 (irq = 40, base_baud = 0) is a scif
>
> Maybe some of the patches could be merged together, but for now I decided
> to keep them separate to help the review process.
>
> Thank you.
>
> [1] https://lore.kernel.org/lkml/2936e18f-44ea-faed-9fa0-2ddefe7c3194@linux.intel.com/raw
>
> ---
> Hugo Villeneuve (9):
> serial: core: add uart_iotype_mmio/legacy_io helper functions
> serial: core: use uart_iotype_*() to simplify code
> serial: 8250: use uart_iotype_*() to simplify code
> serial: core: fix indentation/alignment
> serial: core: add new I/O type for SPI and I2C bus devices
> serial: core: prevent irrelevant I/O infos display for UPIO_BUS
> serial: sc16is7xx: use new UPIO_BUS as iotype
> serial: max310x: use new UPIO_BUS as iotype
> serial: max3100: use new UPIO_BUS as iotype
>
> drivers/tty/serial/8250/8250_port.c | 33 ++--------
> drivers/tty/serial/max3100.c | 1 +
> drivers/tty/serial/max310x.c | 9 +--
> drivers/tty/serial/sc16is7xx.c | 9 +--
> drivers/tty/serial/serial_core.c | 121 ++++++++++++++++++++----------------
> include/linux/serial_core.h | 5 ++
> include/uapi/linux/serial.h | 1 +
> 7 files changed, 83 insertions(+), 96 deletions(-)
> ---
> base-commit: 2e68039281932e6dc37718a1ea7cbb8e2cda42e6
> change-id: 20260423-tty-upio-c8b66a0a593e
>
> Best regards,
>
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Ilpo Järvinen @ 2026-04-24 11:38 UTC (permalink / raw)
To: Jia Wang
Cc: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <20260424-ultrarisc-serial-v4-2-1765a0b4c4a0@ultrarisc.com>
On Fri, 24 Apr 2026, Jia Wang wrote:
> Replace the magic CPR value for Renesas RZ/N1 with a composition using
> DW_UART_CPR_* bit/field definitions and FIELD_PREP_CONST().
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> drivers/tty/serial/8250/8250_dw.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> index 467755bf0092..d3c2c9c84d9f 100644
> --- a/drivers/tty/serial/8250/8250_dw.c
> +++ b/drivers/tty/serial/8250/8250_dw.c
> @@ -937,7 +937,15 @@ static const struct dw8250_platform_data dw8250_armada_38x_data = {
>
> static const struct dw8250_platform_data dw8250_renesas_rzn1_data = {
> .usr_reg = DW_UART_USR,
> - .cpr_value = 0x00012f32,
> + .cpr_value = FIELD_PREP_CONST(DW_UART_CPR_ABP_DATA_WIDTH, 2) |
> + DW_UART_CPR_AFCE_MODE |
> + DW_UART_CPR_THRE_MODE |
> + DW_UART_CPR_ADDITIONAL_FEATURES |
> + DW_UART_CPR_FIFO_ACCESS |
> + DW_UART_CPR_FIFO_STAT |
> + DW_UART_CPR_SHADOW |
> + DW_UART_CPR_DMA_EXTRA |
> + FIELD_PREP_CONST(DW_UART_CPR_FIFO_MODE, 0x01),
Hmm, maybe there should also be macro also for this one which takes the
fifosize as input and converts it to CPR field vlaue (effectively, the
macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
than the literal.
Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
inside that macro to catch invalid fifo sizes (+ don't forget the
necessary headers for those two new things).
--
i.
^ permalink raw reply
* Re: [PATCH] dt-bindings: serial: Add compatible for Qualcomm Nord SoC
From: Shawn Guo @ 2026-04-24 12:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Praveen Talari, Konrad Dybcio, Dmitry Baryshkov,
Bartosz Golaszewski, Deepti Jaggi, linux-serial, devicetree,
linux-arm-msm, linux-kernel
In-Reply-To: <20260421-spotted-fiery-crab-4defd7@quoll>
On Tue, Apr 21, 2026 at 12:34:33PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Apr 20, 2026 at 02:05:24PM +0800, Shawn Guo wrote:
> > From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> >
> > Document compatibles for QUP GENI UART controller on Nord SoC with
> > fallback on SA8255P compatibles.
> >
> > Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> > ---
> > .../bindings/serial/qcom,sa8255p-geni-uart.yaml | 13 ++++++++++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thank you, Krzysztof!
As explained to Rob [1], I would like to send a new version by using
'sa8797p' instead of 'nord-auto' in the compatible strings. I intend
to keep your review tag, but please let me know if you want to withdraw
the tag.
Shawn
[1] https://lore.kernel.org/all/aeowYpvA6MegAX6w@QCOM-aGQu4IUr3Y/
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Andy Shevchenko @ 2026-04-24 13:27 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Jia Wang, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <4548483c-cbba-899e-6b1a-1290d36b59cd@linux.intel.com>
On Fri, Apr 24, 2026 at 02:38:56PM +0300, Ilpo Järvinen wrote:
> On Fri, 24 Apr 2026, Jia Wang wrote:
...
> Hmm, maybe there should also be macro also for this one which takes the
> fifosize as input and converts it to CPR field vlaue (effectively, the
> macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
> than the literal.
But this can be done separately, right?
> Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
> inside that macro to catch invalid fifo sizes (+ don't forget the
> necessary headers for those two new things).
Hmm... Some devices may have FIFO = 8 or 4 bytes (Intel Quark IIRC has less
than 16 and it's DW IP).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Ilpo Järvinen @ 2026-04-24 14:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <aetv2ljDOpH_Hs4s@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
On Fri, 24 Apr 2026, Andy Shevchenko wrote:
> On Fri, Apr 24, 2026 at 02:38:56PM +0300, Ilpo Järvinen wrote:
> > On Fri, 24 Apr 2026, Jia Wang wrote:
>
> ...
>
> > Hmm, maybe there should also be macro also for this one which takes the
> > fifosize as input and converts it to CPR field vlaue (effectively, the
> > macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
> > than the literal.
>
> But this can be done separately, right?
It's logically part of the cpr_value literal to defines conversion (of
course one could introduce it in own patch without users but I don't see
much benefit from that).
> > Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
> > inside that macro to catch invalid fifo sizes (+ don't forget the
> > necessary headers for those two new things).
>
> Hmm... Some devices may have FIFO = 8 or 4 bytes (Intel Quark IIRC has less
> than 16 and it's DW IP).
Perhaps but according the DW databook I've at hand, there are no values in
FIFO_MODE field for such FIFO sizes. So what would CPR contain in those
cases for FIFO_MODE field?
--
i.
^ permalink raw reply
* Re: [PATCH 6/9] serial: core: prevent irrelevant I/O infos display for UPIO_BUS
From: Hugo Villeneuve @ 2026-04-24 14:24 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <96429741-16d0-3e4b-b42f-d273a2adfba7@linux.intel.com>
On Fri, 24 Apr 2026 13:51:52 +0300 (EEST)
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
>
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > It doesn't make sense to display irrelevant MMIO or legacy I/O information
> > for serial devices on I2C or SPI busses. Now that we have a separate I/O
> > type for these types of devices, prevent display of I/O information for
> > them. Using uart_iotype_*() functions to do so also addresses the now
> > invalid check for "iotype >= UPIO_MEM".
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > drivers/tty/serial/serial_core.c | 50 ++++++++++++++++++----------------------
> > 1 file changed, 22 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index 0bfdb69817e4259681fbc4658c9a68200aa2b65f..42559eda6fc134de77c3a7b850d565ebdc89e216 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -2011,13 +2011,18 @@ static void uart_line_info(struct seq_file *m, struct uart_state *state)
> > if (!uport)
> > return;
> >
> > - mmio = uport->iotype >= UPIO_MEM;
> > - seq_printf(m, "%u: uart:%s %s%08llX irq:%u",
> > - uport->line, uart_type(uport),
> > - mmio ? "mmio:0x" : "port:",
> > - mmio ? (unsigned long long)uport->mapbase
> > - : (unsigned long long)uport->iobase,
> > - uport->irq);
> > + seq_printf(m, "%u: uart:%s", uport->line, uart_type(uport));
> > +
> > + mmio = uart_iotype_mmio(uport->iotype);
> > +
> > + if (mmio || uart_iotype_legacy_io(uport->iotype)) {
> > + seq_printf(m, " %s%08llX",
> > + mmio ? "mmio:0x" : "port:",
> > + mmio ? (unsigned long long)uport->mapbase
> > + : (unsigned long long)uport->iobase);
>
> This should align to ?
Ok, my auto-indent is not working for that.
Will change it to:
seq_printf(m, " %s%08llX", mmio ? "mmio:0x" : "port:",
mmio ? (unsigned long long)uport->mapbase
: (unsigned long long)uport->iobase);
>
> > + }
> > +
> > + seq_printf(m, "irq:%u", uport->irq);
> >
> > if (uport->type == PORT_UNKNOWN) {
> > seq_putc(m, '\n');
> > @@ -2482,31 +2487,20 @@ EXPORT_SYMBOL(uart_resume_port);
> > static inline void
> > uart_report_port(struct uart_driver *drv, struct uart_port *port)
> > {
> > - char address[64];
> > + char address[64] = "";
> >
> > - switch (port->iotype) {
> > - case UPIO_PORT:
> > - snprintf(address, sizeof(address), "I/O 0x%lx", port->iobase);
> > - break;
> > - case UPIO_HUB6:
> > + if (uart_iotype_mmio(port->iotype))
> > snprintf(address, sizeof(address),
> > - "I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
> > - break;
> > - case UPIO_MEM:
> > - case UPIO_MEM16:
> > - case UPIO_MEM32:
> > - case UPIO_MEM32BE:
> > - case UPIO_AU:
> > - case UPIO_TSI:
> > - snprintf(address, sizeof(address),
> > - "MMIO 0x%llx", (unsigned long long)port->mapbase);
> > - break;
> > - default:
> > - strscpy(address, "*unknown*", sizeof(address));
> > - break;
> > + " at MMIO 0x%llx", (unsigned long long)port->mapbase);
> > + else if (uart_iotype_legacy_io(port->iotype)) {
> > + if (port->iotype == UPIO_PORT)
> > + snprintf(address, sizeof(address), " at I/O 0x%lx", port->iobase);
> > + else if (port->iotype == UPIO_HUB6)
> > + snprintf(address, sizeof(address),
> > + " at I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
>
> Please use scnprintf() so we could perhaps one day get rid of snprintf()
> entirely.
Ok will do.
>
> > }
> >
> > - pr_info("%s%s%s at %s (irq = %u, base_baud = %u) is a %s\n",
> > + pr_info("%s%s%s%s (irq = %u, base_baud = %u) is a %s\n",
> > port->dev ? dev_name(port->dev) : "",
> > port->dev ? ": " : "",
> > port->name,
> >
> >
>
> --
> i.
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Andy Shevchenko @ 2026-04-24 15:16 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Jia Wang, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <363a636d-f014-cc29-6be4-ec3041f43855@linux.intel.com>
On Fri, Apr 24, 2026 at 05:09:46PM +0300, Ilpo Järvinen wrote:
> On Fri, 24 Apr 2026, Andy Shevchenko wrote:
> > On Fri, Apr 24, 2026 at 02:38:56PM +0300, Ilpo Järvinen wrote:
> > > On Fri, 24 Apr 2026, Jia Wang wrote:
...
> > > Hmm, maybe there should also be macro also for this one which takes the
> > > fifosize as input and converts it to CPR field vlaue (effectively, the
> > > macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
> > > than the literal.
> >
> > But this can be done separately, right?
>
> It's logically part of the cpr_value literal to defines conversion (of
> course one could introduce it in own patch without users but I don't see
> much benefit from that).
No objections.
> > > Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
> > > inside that macro to catch invalid fifo sizes (+ don't forget the
> > > necessary headers for those two new things).
> >
> > Hmm... Some devices may have FIFO = 8 or 4 bytes (Intel Quark IIRC has less
> > than 16 and it's DW IP).
>
> Perhaps but according the DW databook I've at hand, there are no values in
> FIFO_MODE field for such FIFO sizes. So what would CPR contain in those
> cases for FIFO_MODE field?
On real HW it returns 0s for all registers above 0x07 (multiplied by 4 as
a stride). But I also checked the values of xmit_fifo_size and it shows 16.
What 8 is it is the DMA max_burst. Hence the proposed assertion should work.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/9] serial: core: use uart_iotype_*() to simplify code
From: Hugo Villeneuve @ 2026-04-24 15:30 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <716918cf-b240-43cc-a702-9b3d94dc75d2@linux.intel.com>
On Fri, 24 Apr 2026 14:13:02 +0300 (EEST)
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
>
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Make use of new functions uart_iotype_mmio() and uart_iotype_legacy_io()
> > to simplify and improve code readability.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > drivers/tty/serial/serial_core.c | 24 +++++++++---------------
> > 1 file changed, 9 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index b1cf45a8fc854cd97e349ff077d83b42e3ef8b16..fc273f8f9e75de89dca1ac1aca3589567bcf8a18 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -3221,23 +3221,17 @@ bool uart_match_port(const struct uart_port *port1,
> > {
> > if (port1->iotype != port2->iotype)
> > return false;
> > -
> > - switch (port1->iotype) {
> > - case UPIO_PORT:
> > - return port1->iobase == port2->iobase;
> > - case UPIO_HUB6:
> > - return port1->iobase == port2->iobase &&
> > - port1->hub6 == port2->hub6;
> > - case UPIO_MEM:
> > - case UPIO_MEM16:
> > - case UPIO_MEM32:
> > - case UPIO_MEM32BE:
> > - case UPIO_AU:
> > - case UPIO_TSI:
> > + else if (uart_iotype_mmio(port1->iotype))
> > return port1->mapbase == port2->mapbase;
> > - default:
> > + else if (uart_iotype_legacy_io(port1->iotype))
> > + if (port1->iobase != port2->iobase)
> > + return false;
> > + else if (port1->iotype == UPIO_HUB6 && port1->hub6 != port2->hub6)
>
> I suggest placing the entire hub6 related check (including the iobase
> check) into own function in 8250_hub6.c and add a stub for the case when
> hub6 code is not even built into kernel into 8250.h.
Neat. I will make a separate commit for that in V2. This
simplifies uart_match_port() even more...
Thank you,
Hugo.
>
> > + return false;
> > + else
> > + return true;
> > + else
> > return false;
> > - }
> > }
> > EXPORT_SYMBOL(uart_match_port);
> >
> >
> >
>
> --
> i.
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Krzysztof Kozlowski @ 2026-04-24 16:12 UTC (permalink / raw)
To: Alim Akhtar, gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel
In-Reply-To: <20260424101835.2125970-1-alim.akhtar@samsung.com>
On 24/04/2026 12:18, Alim Akhtar wrote:
> Currently Exynosautov-{9,920} getting probed based on exynos850
> fallback. It is recommended to have a dedicated compatible for
> proper driver binding.
Unfortunately it is not. Dedicated compatible you have. However you are
not adding dedicated compatible. You added dedicated driver match entry
and we, and especially me, gave reviews many times that it is *not
recommended* to have dedicated driver match entry.
Entire reasoning for doing this patch is wrong. And patch itself is NOOP
(at least by quick look).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] serial: 8250_dw: Clean up register macros and error handling
From: Artem Shimko @ 2026-04-24 21:05 UTC (permalink / raw)
To: sashal, miquel.raynal, phil.edworthy, Ilpo Järvinen,
Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby
Cc: Artem Shimko, linux-kernel, linux-serial
Align register offset definitions for DW_UART_USR, DW_UART_DMASA,
OCTEON_UART_USR, RZN1_UART_TDMACR and RZN1_UART_RDMACR to improve
readability. Replace raw shift with FIELD_PREP() and GENMASK() for
RZN1_UART_xDMACR burst field definitions — this documents that the
field occupies bits [2:1] and prevents accidental overflow when new
burst values are added.
Simplify ENXIO handling in dw8250_probe(): instead of explicitly
zeroing 'err' and then checking it, use a single conditional that
allows -ENXIO (no interrupt, fall back to polling) while treating
any other error as fatal. No functional change intended.
Signed-off-by: Artem Shimko <a.shimko.dev@gmail.com>
---
Hi,
This small cleanup patch addresses a few minor style and robustness
issues I noticed while working with the driver.
Thank you.
--
Regards,
Artem
drivers/tty/serial/8250/8250_dw.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 94beadb4024d..3e7b79154d9d 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -35,13 +35,13 @@
#include "8250_dwlib.h"
/* Offsets for the DesignWare specific registers */
-#define DW_UART_USR 0x1f /* UART Status Register */
-#define DW_UART_DMASA 0xa8 /* DMA Software Ack */
+#define DW_UART_USR 0x1f /* UART Status Register */
+#define DW_UART_DMASA 0xa8 /* DMA Software Ack */
-#define OCTEON_UART_USR 0x27 /* UART Status Register */
+#define OCTEON_UART_USR 0x27 /* UART Status Register */
-#define RZN1_UART_TDMACR 0x10c /* DMA Control Register Transmit Mode */
-#define RZN1_UART_RDMACR 0x110 /* DMA Control Register Receive Mode */
+#define RZN1_UART_TDMACR 0x10c /* DMA Control Register Transmit Mode */
+#define RZN1_UART_RDMACR 0x110 /* DMA Control Register Receive Mode */
/* DesignWare specific register fields */
#define DW_UART_IIR_IID GENMASK(3, 0)
@@ -52,9 +52,10 @@
/* Renesas specific register fields */
#define RZN1_UART_xDMACR_DMA_EN BIT(0)
-#define RZN1_UART_xDMACR_1_WORD_BURST (0 << 1)
-#define RZN1_UART_xDMACR_4_WORD_BURST (1 << 1)
-#define RZN1_UART_xDMACR_8_WORD_BURST (2 << 1)
+#define RZN1_UART_xDMACR_BURST_MASK GENMASK(2, 1)
+#define RZN1_UART_xDMACR_1_WORD_BURST FIELD_PREP(RZN1_UART_xDMACR_BURST_MASK, 0)
+#define RZN1_UART_xDMACR_4_WORD_BURST FIELD_PREP(RZN1_UART_xDMACR_BURST_MASK, 1)
+#define RZN1_UART_xDMACR_8_WORD_BURST FIELD_PREP(RZN1_UART_xDMACR_BURST_MASK, 2)
#define RZN1_UART_xDMACR_BLK_SZ(x) ((x) << 3)
/* Quirks */
@@ -729,9 +730,7 @@ static int dw8250_probe(struct platform_device *pdev)
err = uart_read_port_properties(p);
/* no interrupt -> fall back to polling */
- if (err == -ENXIO)
- err = 0;
- if (err)
+ if (err && err != -ENXIO)
return err;
switch (p->iotype) {
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/6] Add support for ZTE zx297520v3
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
Hi,
This is a follow-up on my RFC patches from January [0] for ZTE's
zx297520v3 chipset. This chipset is popular in cheap LTE-to-wifi routers
sold in developing countries. My goal is to run OpenWRT on them. I made
more progress in more work on this SoC and it is time to get serious
about code review and upstreaming.
Since my version in January I managed to get more hardware running: SPI,
I2C, PMIC with real time clock and voltage regulators, Watchdog. LTE is
not working yet, but I am able to start the coprocessor that handles it
and talk to it via mailbox + shared memory. Wifi is working on a few
more devices. Since WiFi, USB and Ethernet are working, the devices can
have actual use with OpenWRT even without LTE.
Another hacker created a free software program to talk to the USB loader
[1] and boot U-Boot and Linux without modifying the on disk files. At
the moment it needs a proprietary blob, so my documentation is
emphasising booting with the on-device U-Boot.
This patchset here is mostly unmodified from the version I sent in
January. It is the bare minimum to get an interactive shell working on
the UART. Future patches can be found on my git repository [2] for those
curious to peek ahead. The first 30 patches are in reasonable shape, but
the further you go the more cleanup is necessary. I expect all of the
patches go require a few rounds of feedback though.
My plan for upstreaming is largly this:
1) This bare minimum boot patchset
2) Add clock and pinctrl drivers
3) Add standard hardware to the device tree
4) Add zx29 specific drivers one by one: Watchdog, spi, i2c, DMA, PMIC,
battery
5) SDIO backend for rtl8xxxu
6) rproc, mailbox and rpmsg
I am willing to maintain support for the SoC within reason. My patches
add myself as maintainer. This is a hobby project for me though, keep
that in mind if you want to ship a commercial product with these SoCs
and upstreaming Linux.
Cheers,
Stefan
0: https://lists.infradead.org/pipermail/linux-arm-kernel/2026-January/1099306.html
1: https://github.com/zx297520v3-mainline/zx297520v3-loader
2: https://gitlab.com/stefandoesinger/zx297520-kernel/
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Patch changelog:
Changes in v6:
Squashed DT commits into one
Removed for-now unused board DT bindings
Add "zte" to DT patch subject
Regenerate the defconfig with make savedefconfig
- Link to v5: https://lore.kernel.org/r/20260421-send-v5-0-ace038e63515@gmail.com
v5:
Spelling fixes
Renamed dlink-dwr-932m.dts to zx297520v3-dlink-dwr932m.dts
DT binding indentation fixes
Use a manufacturer 0x8b for the UART, fix patch prefix
Declare all UARTs, remove uart aliases for now
Consistent license declarations. I made every new file except the DT
binding GPL-2.0-only but I don't particularly mind GPL-2.0-or-later
either.
- Link to v4: https://lore.kernel.org/r/20260416-send-v4-0-e19d02b944ec@gmail.com
v4: rename zx29.yaml to zte.yaml and add board enums
v3: Remove [RFC] tag, add defconfig
v2: checkpatch.pl fixes
---
Stefan Dösinger (6):
dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
ARM: zte: Add zx297520v3 platform support
ARM: zte: Add support for zx29 low level debug
amba/serial: amba-pl011: Bring back zx29 UART support
ARM: dts: zte: Add D-Link DWR-932M support
ARM: zte: defconfig: Add a zx29 defconfig file
Documentation/arch/arm/zte/zx297520v3.rst | 158 +++++++++++++++++++++
Documentation/devicetree/bindings/arm/zte.yaml | 26 ++++
MAINTAINERS | 7 +
arch/arm/Kconfig | 2 +
arch/arm/Kconfig.debug | 12 ++
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 +
arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts | 22 +++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 103 ++++++++++++++
arch/arm/configs/zx29_defconfig | 54 +++++++
arch/arm/include/debug/pl01x.S | 7 +
arch/arm/mach-zte/Kconfig | 26 ++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 +++
drivers/tty/serial/amba-pl011.c | 42 ++++++
16 files changed, 485 insertions(+)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260416-send-5c08e095e5c9
Best regards,
--
Stefan Dösinger <stefandoesinger@gmail.com>
^ 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