* Re: [PATCH 2/9] serial: core: use uart_iotype_*() to simplify code
From: Ilpo Järvinen @ 2026-04-27 14:16 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <20260427094639.73a7e27709e466fda2356a4d@hugovil.com>
[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]
On Mon, 27 Apr 2026, Hugo Villeneuve wrote:
> On Fri, 24 Apr 2026 11:30:46 -0400
> Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> > 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...
>
> I implemented it, the only thing I am not sure about is the include of
> "8250/8250.h" in serial_core.c?
I'd just include it and add comment before it that it's included because
of UPIO_HUB6 port matching.
The more generic alternative would be to make the matcher a callback but
that feels overkill for some legacy iotype trick, IMO.
--
i.
^ permalink raw reply
* Re: [PATCH 4/4] Revert "drivers: convert sbd_duart.map_guard from atomic_t to refcount_t"
From: Maciej W. Rozycki @ 2026-04-27 14:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Thomas Bogendoerfer, Jiri Slaby, Elena Reshetova, David Windsor,
Kees Cook, Hans Liljestrand, linux-mips, linux-serial,
linux-kernel
In-Reply-To: <2026042630-diaphragm-reactor-7cfe@gregkh>
On Sun, 26 Apr 2026, Greg Kroah-Hartman wrote:
> > Revert commit 22a33651a56f ("drivers: convert sbd_duart.map_guard from
> > atomic_t to refcount_t"), which broke perfectly valid code:
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 1 at lib/refcount.c:114 sbd_request_port+0x54/0x140
> > refcount_t: increment on 0; use-after-free.
> > CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc2+ #34
> > Stack : 0000000014001fe0 0000000000000000 ffffffff80830000 0000000000000000
> > ffffffff8127bc7a ffffffff8016fe08 ffffffff808d0000 ffffffff808d0000
> > ffffffff807aa828 ffffffff80822337 ffffffff808ce188 a8000001860b0000
> > 0000000000000001 0000000000000001 00000000000001c8 ffffffff808a3090
> > 00000000000000bb ffffffff801b09d4 a80000018609bb68 ffffffff801231cc
> > ffffffff812a0000 ffffffff80171388 0000000000001000 ffffffff807aa828
> > 0000000000000001 0000000000000001 0000000000000000 0000000000000000
> > 0000000000000000 a80000018609bab0 0000000000000000 ffffffff803c47cc
> > 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > ffffffff807cb648 ffffffff8010bff8 0000000014001fe1 ffffffff803c47cc
> > ...
> > Call Trace:
> > [<ffffffff8010bff8>] show_stack+0x28/0x88
> > [<ffffffff803c47cc>] dump_stack+0x8c/0xc0
> > [<ffffffff801aff5c>] __warn+0xe0/0x114
> > [<ffffffff801233f0>] warn_slowpath_fmt+0x40/0x50
> > [<ffffffff80455bcc>] sbd_request_port+0x54/0x140
> > [<ffffffff804563a4>] sbd_config_port+0x2c/0x68
> > ---[ end trace f666d696412caa3e ]---
> >
> > (report at the offending commit) -- sbd_request_port() is called twice
> > per DUART instance, to reserve a resource holding the control register
> > block shared between the two channels, so there's no slightest chance
> > for an overflow. Also this doesn't stop the driver from working and
> > it's just the reservation that is missing as a result, i.e.:
> >
> > 10060100-100601ff : sb1250-duart
> > 10060200-100602ff : sb1250-duart
> >
> > as from the offending change, vs:
> >
> > 10060100-100601ff : sb1250-duart
> > 10060200-100602ff : sb1250-duart
> > 10060300-100603ff : sb1250-duart
> >
> > beforehand, which is surely why the breakage has gone so long unnoticed.
> >
> > "If it ain't broke, don't fix it," so just revert the broken commit.
>
> How about fix this up to work properly with a refcount? having "open
> coded" atomic variables like this is ripe for problems, like it seems
> this driver is abusing.
Clearly refcount has odd semantics for this use case, as the failed
attempt to "fix" this code has shown.
The natural values for `map_guard' are 0 and 1 (FALSE and TRUE), for the
resource not taken and taken respectively, however refcount code complains
about this arrangement as indicated by the report quoted.
I suppose I can bend backwards and adopt other values, which I'll have to
figure out from the API somehow, but it's not clear to me how it would
cause less confusion than original straightforward code, the whole point
of which is to prevent the resource from being requested again for the
second port in a DUART.
Or I could use an ordinary variable, possibly of the `bool' type, guarded
by a spinlock, but that would be even more of an overkill IMO.
Maciej
^ permalink raw reply
* Re: [PATCH 2/9] serial: core: use uart_iotype_*() to simplify code
From: Hugo Villeneuve @ 2026-04-27 13:46 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby, LKML,
linux-serial, Hugo Villeneuve
In-Reply-To: <20260424113046.f792a805ef0507638e95b963@hugovil.com>
On Fri, 24 Apr 2026 11:30:46 -0400
Hugo Villeneuve <hugo@hugovil.com> wrote:
> 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...
I implemented it, the only thing I am not sure about is the include of
"8250/8250.h" in serial_core.c?
Hugo.
> >
> > > + return false;
> > > + else
> > > + return true;
> > > + else
> > > return false;
> > > - }
> > > }
> > > EXPORT_SYMBOL(uart_match_port);
> > >
> > >
> > >
> >
> > --
> > i.
> >
> >
>
>
> --
> Hugo Villeneuve
>
>
--
Hugo Villeneuve
^ permalink raw reply
* RE: [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Alim Akhtar @ 2026-04-27 10:26 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel
In-Reply-To: <8998d2ae-cb6e-458d-8551-6b44f81b1c60@kernel.org>
Hi Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Monday, April 27, 2026 12:10 PM
> To: Alim Akhtar <alim.akhtar@samsung.com>; gregkh@linuxfoundation.org;
> jirislaby@kernel.org
> Cc: linux-serial@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] tty: serial: samsung: add dedicated compatible for
> exynosauto SoCs
> >
.
.
.
> >> Entire reasoning for doing this patch is wrong. And patch itself is
> >> NOOP (at least by quick look).
> > Thanks for a quick review, Can you please check the part of the patch
> > which adds OF_EARLYCON_DECLARE to add earlycon support?
> >
>
> It also feels unnecessary - existing compatible will be used for earlycon, no?
> If matching by existing compatible does not work, commit msg should explain
> that.
>
Yes, it fall back to exynos850 and earlycon does work with fallback compatible, Thanks!
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v1] serial: qcom-geni: Avoid probing debug console UART without console support
From: Praveen Talari @ 2026-04-27 9:18 UTC (permalink / raw)
To: Aniket Randive, gregkh, jirislaby, linux-arm-msm, linux-kernel,
linux-serial, anup.kulkarni, dmitry.baryshkov, viken.dadhaniya
In-Reply-To: <20260413072501.263871-1-aniket.randive@oss.qualcomm.com>
On 13-04-2026 12:55, Aniket Randive wrote:
> When CONFIG_SERIAL_QCOM_GENI_CONSOLE is disabled, the driver still
> advertises the debug UART compatible strings ("qcom,geni-debug-uart"
> and "qcom,sa8255p-geni-debug-uart") in its of_match table. This lets the
> driver match and probe console UART DT nodes even though console
> support is not built. As a result, the console port is never registered
> with the UART core and uart_add_one_port() fails with -EINVAL.
>
> Fix this by only including the debug UART compatible entries in the
> match table when CONFIG_SERIAL_QCOM_GENI_CONSOLE is enabled, preventing
> the driver from probing console UART nodes when console support is
> absent.
>
> Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com>
> ---
> drivers/tty/serial/qcom_geni_serial.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> index 9854bb2406e3..b756e0c07c16 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -2039,6 +2039,7 @@ static const struct dev_pm_ops qcom_geni_serial_pm_ops = {
> };
>
> static const struct of_device_id qcom_geni_serial_match_table[] = {
> +#if IS_ENABLED(CONFIG_SERIAL_QCOM_GENI_CONSOLE)
> {
> .compatible = "qcom,geni-debug-uart",
> .data = &qcom_geni_console_data,
> @@ -2047,6 +2048,7 @@ static const struct of_device_id qcom_geni_serial_match_table[] = {
> .compatible = "qcom,sa8255p-geni-debug-uart",
> .data = &sa8255p_qcom_geni_console_data,
> },
> +#endif
> {
> .compatible = "qcom,geni-uart",
> .data = &qcom_geni_uart_data,
Reviewed-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Thanks,
Praveen Talari
^ permalink raw reply
* Re: [PATCH v4 0/4] serial: 8250_dw: Add support for UltraRISC DP1000 UART
From: Andy Shevchenko @ 2026-04-27 7:39 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: <177727526561.1796253.1521989195994870860.b4-reply@b4>
On Mon, Apr 27, 2026 at 03:34:25PM +0800, Jia Wang wrote:
> On 2026-04-24 12:58 +0300, Andy Shevchenko wrote:
> > 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)
> >
>
> Thanks for the review, Andy. I need to rework patches 1, 2 and 4, so
> I won't add your Reviewed-by tag yet. Could you please have another
> look at the updated patches in v5?
Sure, whenever it will be available in the mailing lists/my mailbox.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 0/4] serial: 8250_dw: Add support for UltraRISC DP1000 UART
From: Jia Wang @ 2026-04-27 7:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, 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: <aes-qdaT_9wMbTsm@ashevche-desk.local>
On 2026-04-24 12:58 +0300, Andy Shevchenko wrote:
> 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)
>
Thanks for the review, Andy. I need to rework patches 1, 2 and 4, so
I won't add your Reviewed-by tag yet. Could you please have another
look at the updated patches in v5?
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Best Regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Jia Wang @ 2026-04-27 7:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Ilpo Järvinen, 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: <aeuJTMqADw8J0x0u@ashevche-desk.local>
On 2026-04-24 18:16 +0300, Andy Shevchenko wrote:
> 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.
>
Thanks for the discussion and clarification. I'll add the macro
DW_UART_CPR_FIFO_MODE_FROM_SIZE() in 8250_dwlib.h (in patch 2) with the
suggested build‑time checks (using BUILD_BUG_ON_ZERO for bounds validation),
and update patch 4 to use it.
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Best Regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH] serial: 8250_dw: Clean up register macros and error handling
From: Andy Shevchenko @ 2026-04-27 7:02 UTC (permalink / raw)
To: Artem Shimko
Cc: sashal, miquel.raynal, phil.edworthy, Ilpo Järvinen,
Greg Kroah-Hartman, Jiri Slaby, linux-kernel, linux-serial
In-Reply-To: <20260424210525.1574497-1-a.shimko.dev@gmail.com>
On Sat, Apr 25, 2026 at 12:05:24AM +0300, Artem Shimko wrote:
> 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.
There is real patch series in-flight which we want to apply.
This one may wait till that happen. You may also help reviewing that
in a way that this patch won't be needed at all (or be minimal).
https://lore.kernel.org/linux-serial/20260424-ultrarisc-serial-v4-0-1765a0b4c4a0@ultrarisc.com/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] serial: qcom: Unify user-visible "Qualcomm" name
From: Krzysztof Kozlowski @ 2026-04-27 7:00 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-kernel, linux-serial
Cc: =Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
Krzysztof Kozlowski
Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
And "Qualcomm Technologies" has even variations over the tree:
Qualcomm Technologies
Qualcomm Technologies Inc.
Qualcomm Technologies, Inc.
I am doing this tree wide:
https://lore.kernel.org/all/?q=f%3Akrzysztof+s%3A%22Unify+user-visible%22+s%3AQualcomm
---
drivers/tty/serial/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 9aa61c93d7bc..3e519d001e02 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -913,13 +913,13 @@ config SERIAL_MSM_CONSOLE
select SERIAL_EARLYCON
config SERIAL_QCOM_GENI
- tristate "QCOM on-chip GENI based serial port support"
+ tristate "Qualcomm on-chip GENI based serial port support"
depends on ARCH_QCOM || COMPILE_TEST
depends on QCOM_GENI_SE
select SERIAL_CORE
config SERIAL_QCOM_GENI_CONSOLE
- bool "QCOM GENI Serial Console support"
+ bool "Qualcomm GENI Serial Console support"
depends on SERIAL_QCOM_GENI
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v6 2/6] ARM: zte: Add zx297520v3 platform support
From: Krzysztof Kozlowski @ 2026-04-27 6:53 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260426-send-v6-2-d49efa72bb09@gmail.com>
On Sun, Apr 26, 2026 at 02:54:15PM +0300, Stefan Dösinger wrote:
> diff --git a/arch/arm/mach-zte/Kconfig b/arch/arm/mach-zte/Kconfig
> new file mode 100644
> index 000000000000..2e3abee94994
> --- /dev/null
> +++ b/arch/arm/mach-zte/Kconfig
> @@ -0,0 +1,26 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menuconfig ARCH_ZTE
> + bool "ZTE zx family"
> + depends on ARCH_MULTI_V7
> + help
> + Support for ZTE zx-based family of processors.
> +
> +if ARCH_ZTE
> +
> +config SOC_ZX297520V3
> + default y if ARCH_ZTE
> + bool "zx297520v3"
"bool" should be the first line in the entry.
Also say something a bit more useful, e.g. "zx297520v3 SoC" becuase
unfortunately the model number looks too close to random set of
characters.
Rest seems fine:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/6] dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
From: Krzysztof Kozlowski @ 2026-04-27 6:50 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260426-send-v6-1-d49efa72bb09@gmail.com>
On Sun, Apr 26, 2026 at 02:54:14PM +0300, Stefan Dösinger wrote:
> This adds a new binding file for ZTE, containing their zx297520v3 SoC
> and one board (D-Link DWR-932M) based on it.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Krzysztof Kozlowski @ 2026-04-27 6:40 UTC (permalink / raw)
To: Alim Akhtar, gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel
In-Reply-To: <324e01dcd5a0$a53d3d90$efb7b8b0$@samsung.com>
On 26/04/2026 19:18, Alim Akhtar wrote:
> Hi Krzysztof
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Friday, April 24, 2026 9:42 PM
>> To: Alim Akhtar <alim.akhtar@samsung.com>; gregkh@linuxfoundation.org;
>> jirislaby@kernel.org
>> Cc: linux-serial@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [PATCH] tty: serial: samsung: add dedicated compatible for
>> exynosauto SoCs
>>
>> 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.
>>
> Ok, I might have missed your earlier comments on *not* having a dedicated driver match entry, fair enough.
>
>> Entire reasoning for doing this patch is wrong. And patch itself is NOOP (at
>> least by quick look).
> Thanks for a quick review, Can you please check the part of the patch which adds OF_EARLYCON_DECLARE
> to add earlycon support?
>
It also feels unnecessary - existing compatible will be used for
earlycon, no? If matching by existing compatible does not work, commit
msg should explain that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/4] Revert "drivers: convert sbd_duart.map_guard from atomic_t to refcount_t"
From: Greg Kroah-Hartman @ 2026-04-26 20:45 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Thomas Bogendoerfer, Jiri Slaby, Elena Reshetova, David Windsor,
Kees Cook, Hans Liljestrand, linux-mips, linux-serial,
linux-kernel
In-Reply-To: <alpine.DEB.2.21.2604130416440.29980@angie.orcam.me.uk>
On Mon, Apr 13, 2026 at 04:28:53AM +0100, Maciej W. Rozycki wrote:
> Revert commit 22a33651a56f ("drivers: convert sbd_duart.map_guard from
> atomic_t to refcount_t"), which broke perfectly valid code:
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1 at lib/refcount.c:114 sbd_request_port+0x54/0x140
> refcount_t: increment on 0; use-after-free.
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc2+ #34
> Stack : 0000000014001fe0 0000000000000000 ffffffff80830000 0000000000000000
> ffffffff8127bc7a ffffffff8016fe08 ffffffff808d0000 ffffffff808d0000
> ffffffff807aa828 ffffffff80822337 ffffffff808ce188 a8000001860b0000
> 0000000000000001 0000000000000001 00000000000001c8 ffffffff808a3090
> 00000000000000bb ffffffff801b09d4 a80000018609bb68 ffffffff801231cc
> ffffffff812a0000 ffffffff80171388 0000000000001000 ffffffff807aa828
> 0000000000000001 0000000000000001 0000000000000000 0000000000000000
> 0000000000000000 a80000018609bab0 0000000000000000 ffffffff803c47cc
> 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> ffffffff807cb648 ffffffff8010bff8 0000000014001fe1 ffffffff803c47cc
> ...
> Call Trace:
> [<ffffffff8010bff8>] show_stack+0x28/0x88
> [<ffffffff803c47cc>] dump_stack+0x8c/0xc0
> [<ffffffff801aff5c>] __warn+0xe0/0x114
> [<ffffffff801233f0>] warn_slowpath_fmt+0x40/0x50
> [<ffffffff80455bcc>] sbd_request_port+0x54/0x140
> [<ffffffff804563a4>] sbd_config_port+0x2c/0x68
> ---[ end trace f666d696412caa3e ]---
>
> (report at the offending commit) -- sbd_request_port() is called twice
> per DUART instance, to reserve a resource holding the control register
> block shared between the two channels, so there's no slightest chance
> for an overflow. Also this doesn't stop the driver from working and
> it's just the reservation that is missing as a result, i.e.:
>
> 10060100-100601ff : sb1250-duart
> 10060200-100602ff : sb1250-duart
>
> as from the offending change, vs:
>
> 10060100-100601ff : sb1250-duart
> 10060200-100602ff : sb1250-duart
> 10060300-100603ff : sb1250-duart
>
> beforehand, which is surely why the breakage has gone so long unnoticed.
>
> "If it ain't broke, don't fix it," so just revert the broken commit.
How about fix this up to work properly with a refcount? having "open
coded" atomic variables like this is ripe for problems, like it seems
this driver is abusing.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/4] serial: 8250_dwlib: move DesignWare register definitions to header
From: Jia Wang @ 2026-04-27 2:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, 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: <aes_zx9GdaXnDNqG@ashevche-desk.local>
On 2026-04-24 13:02 +0300, Andy Shevchenko wrote:
> 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.
>
Thanks.
Will add comments and blank lines in v5.
> ...
>
> > +/* 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.
>
Will add comments to IIR, MCR, and USR bits and reorder the groups by
register offset in v5.
> > +/* 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.
>
Will do in v5. I'll move them to their respective register-offset
groups with comments and blank lines as suggested.
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Best Regards,
Jia Wang
^ permalink raw reply
* [PATCH v2] dt-bindings: serial: Add compatible for Qualcomm SA8797P SoC
From: Shawn Guo @ 2026-04-27 1:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Praveen Talari,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-serial, devicetree, linux-arm-msm,
linux-kernel, Krzysztof Kozlowski, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Document QUP GENI UART controller on Qualcomm Nord SA8797P SoC which is
compatible with SA8255P controller.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Changes in v2:
- Use 'sa8797p' instead of 'nord-auto' in compatibles
- Update subject and commit log accordingly
- Link to v1: https://lore.kernel.org/all/20260420060524.1248432-1-shengchao.guo@oss.qualcomm.com/
.../bindings/serial/qcom,sa8255p-geni-uart.yaml | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
index c8f01923cb25..8496f822dfa5 100644
--- a/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
@@ -14,9 +14,16 @@ allOf:
properties:
compatible:
- enum:
- - qcom,sa8255p-geni-uart
- - qcom,sa8255p-geni-debug-uart
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+ - items:
+ - const: qcom,sa8797p-geni-uart
+ - const: qcom,sa8255p-geni-uart
+ - items:
+ - const: qcom,sa8797p-geni-debug-uart
+ - const: qcom,sa8255p-geni-debug-uart
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v2] dt-bindings: qcom: geni-se-qup: Add compatible for SA8797P SoC
From: Shawn Guo @ 2026-04-27 0:59 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Praveen Talari,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-serial, devicetree, linux-arm-msm,
linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Document GENI Serial Engine QUP Wrapper Controller on Nord SA8797P SoC
which is compatible with SA8255P one.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Changes in v2:
- Fix indentation warnings reported by yamllint
- Use 'sa8797p' instead of 'nord-auto' in compatibles, also update
subject and commit log accordingly
- Add missing I2C and SPI compatibles
- Link to v1: https://lore.kernel.org/all/20260420064401.1248833-1-shengchao.guo@oss.qualcomm.com/
.../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 31 +++++++++++++++----
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
index 352af3426d34..9c38ba59662b 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
@@ -19,7 +19,11 @@ description:
properties:
compatible:
- const: qcom,sa8255p-geni-se-qup
+ oneOf:
+ - const: qcom,sa8255p-geni-se-qup
+ - items:
+ - const: qcom,sa8797p-geni-se-qup
+ - const: qcom,sa8255p-geni-se-qup
reg:
description: QUP wrapper common register address and length.
@@ -49,7 +53,11 @@ patternProperties:
properties:
compatible:
- const: qcom,sa8255p-geni-spi
+ oneOf:
+ - const: qcom,sa8255p-geni-spi
+ - items:
+ - const: qcom,sa8797p-geni-spi
+ - const: qcom,sa8255p-geni-spi
"i2c@[0-9a-f]+$":
type: object
@@ -58,7 +66,11 @@ patternProperties:
properties:
compatible:
- const: qcom,sa8255p-geni-i2c
+ oneOf:
+ - const: qcom,sa8255p-geni-i2c
+ - items:
+ - const: qcom,sa8797p-geni-i2c
+ - const: qcom,sa8255p-geni-i2c
"serial@[0-9a-f]+$":
type: object
@@ -67,9 +79,16 @@ patternProperties:
properties:
compatible:
- enum:
- - qcom,sa8255p-geni-uart
- - qcom,sa8255p-geni-debug-uart
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+ - items:
+ - const: qcom,sa8797p-geni-uart
+ - const: qcom,sa8255p-geni-uart
+ - items:
+ - const: qcom,sa8797p-geni-debug-uart
+ - const: qcom,sa8255p-geni-debug-uart
required:
- compatible
--
2.43.0
^ permalink raw reply related
* [PATCH v2] serial: mxs-auart: replace hardcoded 1 with predefined macro GPIO_LINE_DIRECTION_IN
From: Nikola Z. Ivanov @ 2026-04-26 21:42 UTC (permalink / raw)
To: gregkh, jirislaby, Frank.Li, s.hauer, kernel, festevam
Cc: linux-kernel, linux-serial, imx, linux-arm-kernel,
Nikola Z. Ivanov
The GPIO_LINE_DIRECTION_* definitions have just recently been exposed to
gpio consumers.h by breaking them out in a separate defs.h file.
Use this to validate the gpio direction instead of the hard-coded literal.
Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
---
Changes since v1:
- Commit title change
https://lore.kernel.org/all/26cd0656-ca76-4cb7-9f1e-b8c042a7e2cb@gmail.com/
drivers/tty/serial/mxs-auart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 693b491f1e75..697318dbb146 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1520,7 +1520,7 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
for (i = 0; i < UART_GPIO_MAX; i++) {
gpiod = mctrl_gpio_to_gpiod(s->gpios, i);
- if (gpiod && (gpiod_get_direction(gpiod) == 1))
+ if (gpiod && (gpiod_get_direction(gpiod) == GPIO_LINE_DIRECTION_IN))
s->gpio_irq[i] = gpiod_to_irq(gpiod);
else
s->gpio_irq[i] = -EINVAL;
--
2.53.0
^ permalink raw reply related
* RE: [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Alim Akhtar @ 2026-04-26 17:18 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel
In-Reply-To: <6916bf87-4c40-42c5-988f-92a57a6fc658@kernel.org>
Hi Krzysztof
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Friday, April 24, 2026 9:42 PM
> To: Alim Akhtar <alim.akhtar@samsung.com>; gregkh@linuxfoundation.org;
> jirislaby@kernel.org
> Cc: linux-serial@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] tty: serial: samsung: add dedicated compatible for
> exynosauto SoCs
>
> 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.
>
Ok, I might have missed your earlier comments on *not* having a dedicated driver match entry, fair enough.
> Entire reasoning for doing this patch is wrong. And patch itself is NOOP (at
> least by quick look).
Thanks for a quick review, Can you please check the part of the patch which adds OF_EARLYCON_DECLARE
to add earlycon support?
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v6 6/6] ARM: zte: defconfig: Add a zx29 defconfig file
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
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This enables existing drivers for hardware that is present on this board
even if it is not present in the DT yet.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes: v5 to v6: Regenerate the file with make savedefconfig.
An open question: What's the appropriate name? zx29_defconfig?
zte_defconfig? zte_zx29_defconfig? There's e.g. stm32_defconfig without
an extra mention of STMicro in the name.
---
MAINTAINERS | 1 +
arch/arm/configs/zx29_defconfig | 54 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f51ba1c5ada..5dc52b84cc09 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3776,6 +3776,7 @@ ARM/ZTE ZX29 SOC SUPPORT
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zte.yaml
F: arch/arm/boot/dts/zte/
+F: arch/arm/configs/zx29_defconfig
F: arch/arm/mach-zte/
ARM/ZYNQ ARCHITECTURE
diff --git a/arch/arm/configs/zx29_defconfig b/arch/arm/configs/zx29_defconfig
new file mode 100644
index 000000000000..54fa62ed56e7
--- /dev/null
+++ b/arch/arm/configs/zx29_defconfig
@@ -0,0 +1,54 @@
+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
+CONFIG_KALLSYMS_ALL=y
+CONFIG_ARCH_ZTE=y
+CONFIG_ARM_PSCI=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttyAMA0 earlyprintk root=/dev/ram rw"
+CONFIG_CPU_FREQ=y
+CONFIG_CPUFREQ_DT_PLATDEV=y
+# CONFIG_SUSPEND is not set
+CONFIG_PM=y
+CONFIG_BINFMT_FLAT=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_ALLOW_DEV_COREDUMP is not set
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_SRAM=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_PINCTRL=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+CONFIG_POWER_RESET=y
+CONFIG_MFD_SYSCON=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+# CONFIG_HID is not set
+CONFIG_USB_DWC2=y
+CONFIG_USB_GADGET=y
+CONFIG_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_RESET_SIMPLE=y
+CONFIG_JFFS2_FS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
--
2.53.0
^ permalink raw reply related
* [PATCH v6 5/6] ARM: dts: zte: Add D-Link DWR-932M support
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
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This adds base DT definition for zx297520v3 and one board that consumes it.
The stock kernel does not use the armv7 timer, but it seems to work
fine. The board has other board-specific timers that would need a driver
and I see no reason to bother with them since the arm standard timer
works.
The caveat is the non-standard GIC setup needed to handle the timer's
level-low PPI. This is the responsibility of the boot loader and
documented in Documentation/arch/arm/zte/zx297520v3.rst.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes in
v6: Squash board + timer + uart patches into one
v5: Prepend the SoC name in the device specific DTS filename.
v4:
Declare all uarts
Remove the UART aliases for now. I can revisit this when I get my
hands on a board that exposes two UARTs.
---
MAINTAINERS | 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 +++++++++++++++++++++
5 files changed, 130 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e707176c2114..6f51ba1c5ada 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3775,6 +3775,7 @@ F: drivers/video/fbdev/wmt_ge_rops.*
ARM/ZTE ZX29 SOC SUPPORT
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zte.yaml
+F: arch/arm/boot/dts/zte/
F: arch/arm/mach-zte/
ARM/ZYNQ ARCHITECTURE
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index efe38eb25301..28fba538d552 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,3 +39,4 @@ subdir-y += unisoc
subdir-y += vt8500
subdir-y += xen
subdir-y += xilinx
+subdir-y += zte
diff --git a/arch/arm/boot/dts/zte/Makefile b/arch/arm/boot/dts/zte/Makefile
new file mode 100644
index 000000000000..f052cfbd636c
--- /dev/null
+++ b/arch/arm/boot/dts/zte/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+dtb-$(CONFIG_SOC_ZX297520V3) += \
+ zx297520v3-dlink-dwr932m.dtb
diff --git a/arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts b/arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts
new file mode 100644
index 000000000000..1700f46aba86
--- /dev/null
+++ b/arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Stefan Dösinger <stefandoesinger@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "zx297520v3.dtsi"
+
+/ {
+ model = "D-Link DWR-932M";
+ compatible = "dlink,dwr932m", "zte,zx297520v3";
+
+ memory@20000000 {
+ device_type = "memory";
+ reg = <0x20000000 0x04000000>;
+ };
+};
+
+&uart1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
new file mode 100644
index 000000000000..ca65797ed926
--- /dev/null
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Stefan Dösinger <stefandoesinger@gmail.com>
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0>;
+ };
+ };
+
+ /* Base bus clock and default for the UART. It will be replaced once a clock driver has
+ * been added.
+ */
+ uartclk: uartclk: uartclk-26000000 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ clock-frequency = <26000000>;
+ interrupt-parent = <&gic>;
+ /* I don't think uboot sets CNTVOFF and the stock kernel doesn't use the
+ * arm timer at all. Since this is a single CPU system I don't think it
+ * really matters that the offset is random though.
+ */
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+ /* The GIC has a non-standard way of configuring ints between level-low/level
+ * high or rising edge/falling edge at 0xf2202070 and onwards. See AP_INT_MODE_BASE
+ * and AP_PPI_MODE_REG in the ZTE kernel, although the offsets in the kernel source
+ * seem wrong.
+ *
+ * Everything defaults to active-high/rising edge, but the timer is active-low. We
+ * currently rely on the boot loader to change timer IRQs to active-low for us for
+ * now.
+ */
+ gic: interrupt-controller@f2000000 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xf2000000 0x10000>,
+ <0xf2040000 0x20000>;
+ };
+
+ uart0: serial@131000 {
+ compatible = "arm,primecell";
+ arm,primecell-periphid = <0x0018c011>;
+ reg = <0x00131000 0x1000>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&uartclk>;
+ clock-names = "uartclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart1: serial@1408000 {
+ compatible = "arm,pl011", "arm,primecell";
+ arm,primecell-periphid = <0x0018c011>;
+ reg = <0x01408000 0x1000>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&uartclk>;
+ clock-names = "uartclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart2: serial@140d000 {
+ compatible = "arm,primecell";
+ arm,primecell-periphid = <0x0018c011>;
+ reg = <0x0140d000 0x1000>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&uartclk>;
+ clock-names = "uartclk", "apb_pclk";
+ status = "disabled";
+ };
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 4/6] amba/serial: amba-pl011: Bring back zx29 UART support
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
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform"). I did not bring back the zx29-uart .compatible as the
arm,primecell-periphid does the job.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes since v4:
Use ZTE's JEDEC ID instead of 0xfe for the DT-Provided AMBA ID.
---
drivers/tty/serial/amba-pl011.c | 42 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f17d288c807..f24cc403d9e0 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -216,6 +216,38 @@ static struct vendor_data vendor_st = {
.get_fifosize = get_fifosize_st,
};
+static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
+ [REG_DR] = ZX_UART011_DR,
+ [REG_FR] = ZX_UART011_FR,
+ [REG_LCRH_RX] = ZX_UART011_LCRH,
+ [REG_LCRH_TX] = ZX_UART011_LCRH,
+ [REG_IBRD] = ZX_UART011_IBRD,
+ [REG_FBRD] = ZX_UART011_FBRD,
+ [REG_CR] = ZX_UART011_CR,
+ [REG_IFLS] = ZX_UART011_IFLS,
+ [REG_IMSC] = ZX_UART011_IMSC,
+ [REG_RIS] = ZX_UART011_RIS,
+ [REG_MIS] = ZX_UART011_MIS,
+ [REG_ICR] = ZX_UART011_ICR,
+ [REG_DMACR] = ZX_UART011_DMACR,
+};
+
+static unsigned int get_fifosize_zte(struct amba_device *dev)
+{
+ return 16;
+}
+
+static struct vendor_data vendor_zte = {
+ .reg_offset = pl011_zte_offsets,
+ .access_32b = true,
+ .ifls = UART011_IFLS_RX4_8 | UART011_IFLS_TX4_8,
+ .fr_busy = ZX_UART01x_FR_BUSY,
+ .fr_dsr = ZX_UART01x_FR_DSR,
+ .fr_cts = ZX_UART01x_FR_CTS,
+ .fr_ri = ZX_UART011_FR_RI,
+ .get_fifosize = get_fifosize_zte,
+};
+
/* Deals with DMA transactions */
struct pl011_dmabuf {
@@ -3081,6 +3113,16 @@ static const struct amba_id pl011_ids[] = {
.mask = 0x00ffffff,
.data = &vendor_st,
},
+ {
+ /* This is an invented ID. The actual hardware that contains
+ * these ZTE UARTs (zx29 boards) has no AMBA PIDs stored. ZTE
+ * JEDEC ID (ignoring banks) and the "011" part number as used
+ * by ARM.
+ */
+ .id = 0x0008c011,
+ .mask = 0x000fffff,
+ .data = &vendor_zte,
+ },
{ 0, 0 },
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 3/6] ARM: zte: Add support for zx29 low level debug
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
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This is based on the removed zx29 code. A separate (more complicated)
patch will re-add the register map to the pl011 serial driver.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
I am unsure about the virtual address. It doesn't seem to matter, as
long as it is a valid address. This address is based on the old removed
code. Is there a rule-of-thumb physical to virtual mapping I can use to
give a sensible default value?
---
arch/arm/Kconfig.debug | 12 ++++++++++++
arch/arm/include/debug/pl01x.S | 7 +++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 366f162e147d..98d8a5a60048 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1331,6 +1331,16 @@ choice
This option selects UART0 on VIA/Wondermedia System-on-a-chip
devices, including VT8500, WM8505, WM8650 and WM8850.
+ config DEBUG_ZTE_ZX
+ bool "Kernel low-level debugging via zx29 UART"
+ select DEBUG_UART_PL01X
+ depends on ARCH_ZTE
+ help
+ Say Y here if you are enabling ZTE zx297520v3 SOC and need
+ debug UART support. This UART is a PL011 with different
+ register addresses. The UART for boot messages on zx29 boards
+ is usually UART1 and is operating at 921600 8N1.
+
config DEBUG_ZYNQ_UART0
bool "Kernel low-level debugging on Xilinx Zynq using UART0"
depends on ARCH_ZYNQ
@@ -1545,6 +1555,7 @@ config DEBUG_UART_8250
config DEBUG_UART_PHYS
hex "Physical base address of debug UART"
+ default 0x01408000 if DEBUG_ZTE_ZX
default 0x01c28000 if DEBUG_SUNXI_UART0
default 0x01c28400 if DEBUG_SUNXI_UART1
default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
@@ -1701,6 +1712,7 @@ config DEBUG_UART_VIRT
default 0xf31004c0 if DEBUG_MESON_UARTAO
default 0xf4090000 if DEBUG_LPC32XX
default 0xf4200000 if DEBUG_GEMINI
+ default 0xf4708000 if DEBUG_ZTE_ZX
default 0xf6200000 if DEBUG_PXA_UART1
default 0xf7000000 if DEBUG_SUN9I_UART0
default 0xf7000000 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART0
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
index c7e02d0628bf..0c7bfa4c10db 100644
--- a/arch/arm/include/debug/pl01x.S
+++ b/arch/arm/include/debug/pl01x.S
@@ -8,6 +8,13 @@
*/
#include <linux/amba/serial.h>
+#ifdef CONFIG_DEBUG_ZTE_ZX
+#undef UART01x_DR
+#undef UART01x_FR
+#define UART01x_DR 0x04
+#define UART01x_FR 0x14
+#endif
+
#ifdef CONFIG_DEBUG_UART_PHYS
.macro addruart, rp, rv, tmp
ldr \rp, =CONFIG_DEBUG_UART_PHYS
--
2.53.0
^ permalink raw reply related
* [PATCH v6 2/6] ARM: zte: Add zx297520v3 platform support
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
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
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.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Documentation/arch/arm/zte/zx297520v3.rst | 158 ++++++++++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-zte/Kconfig | 26 +++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 ++++
7 files changed, 209 insertions(+)
diff --git a/Documentation/arch/arm/zte/zx297520v3.rst b/Documentation/arch/arm/zte/zx297520v3.rst
new file mode 100644
index 000000000000..6621ea72769f
--- /dev/null
+++ b/Documentation/arch/arm/zte/zx297520v3.rst
@@ -0,0 +1,158 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+====================================
+Booting Linux on ZTE zx297520v3 SoCs
+====================================
+
+...............................................................................
+
+Author: Stefan Dösinger
+
+Date : 27 Jan 2026
+
+1. Hardware description
+---------------------------
+Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
+it seems to lack VFP and NEON.
+
+The SoC is used in a number of cheap LTE to WiFi routers, both battery powered
+MiFis and stationary CPEs. In addition to the CPU these devices usually have
+64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an
+SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2,
+and buttons. Devices with as low as 32 MB or as high as 128 MB ram exist, as
+do devices with 8 or 16 MB of NOR flash.
+
+Some devices, especially the stationary ones, have 100 mbit Ethernet and an
+Ethernet switch.
+
+Usually the devices have LEDs for status indication, although some have SPI or
+I2C connected displays
+
+Some have an SD card slot. If it exists, it is a better choice for the root
+file system because it easily outperforms the built-in NAND.
+
+The LTE interface runs on a separate DSP called ZSP880. It is probably derived
+from LSI ZSPs and has an undocumented instruction set. The ZSP communicates
+with the main CPU via SRAM and DRAM and a mailbox hardware that can generate
+IRQs on either ends.
+
+There is also a Cortex M0 CPU, which is responsible for early HW initialization
+and starting the Cortex A53 CPU. It does not have any essential purpose once
+U-Boot is started. A SRAM-Based handover protocol exists to run custom code on
+this CPU.
+
+2. Booting via USB
+---------------------------
+
+The Boot ROM has support for booting custom code via USB. This mode can be
+entered by connecting a Boot PIN to GND or by modifying the third byte on NAND
+(set it to anything other than 0x5A aka 'Z'). A free software tool to start
+custom U-Boot and kernels can be found here:
+
+https://github.com/zx297520v3-mainline/zx297520v3-loader
+
+If USB download mode is entered but no boot commands are sent through USB, the
+device will proceed to boot normally after a few seconds. It is therefore
+possible to enable USB boot permanently and still leave the default boot files
+in place.
+
+3. Building for built-in U-Boot
+---------------------------
+The devices come with an ancient U-Boot that loads legacy uImages from NAND and
+boots them without a chance for the user to interrupt. The images are stored in
+files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
+usually mtd4. A file named "fotaflag" switches between the two modes.
+
+In addition to the uImage header, those files have a 384 byte signature header,
+which is used for authenticating the images on some devices. Most devices have
+this authentication disabled and it is enough to pad the uImage files with 384
+zero bytes.
+
+Builtin U-Boot also poorly sets up the CPU. Read the next section for details
+on this. It has no support for loading DTBs, so CONFIG_ARM_APPENDED_DTB is
+needed.
+
+So to build an image that boots from NAND the following steps are necessary:
+
+1) Patch the assembly code from section 3 into arch/arm/kernel/head.S.
+2) make zx29_defconfig
+3) make [-j x]
+4) cat arch/arm/boot/zImage arch/arm/boot/dts/zte/[device].dtb > kernel+dtb
+5) mkimage -A arm -O linux -T kernel -C none -a 0x20008000 -d kernel+dtb uimg
+6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
+7) cat uimg >> ap_recovery.bin
+8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
+free space is not enough.
+9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
+
+For development, booting ap_recovery.bin is recommended because the normal boot
+mode arms the watchdog before starting the kernel.
+
+4. CPU and GIC Setup
+---------------------------
+
+Generally CPU and GICv3 need to be set up according to the requirements spelled
+out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means:
+
+1. GICD_CTLR.DS=1 to disable GIC security
+2. Enable access to ICC_SRE
+3. Disable trapping IRQs into monitor mode
+4. Configure EL2 and below to run in insecure mode.
+5. Configure timer PPIs to active-low.
+
+The kernel sources provided by ZTE do not boot either (interrupts do not work
+at all). They are incomplete in other aspects too, so it is assumed that there
+is some workaround similar to the one described in this document somewhere in
+the binary blobs.
+
+The assembly code below is given as an example of how to achieve this:
+
+```
+#include <linux/irqchip/arm-gic-v3.h>
+#include <asm/assembler.h>
+#include <asm/cp15.h>
+
+@ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ldr r3, =0xf2000000
+ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+str r4, [r3]
+
+cps #MON_MODE
+
+@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+@ seems to respond only to non-secure addresses. I have taken insipiration from
+@ Raspberry pi's armstub7.S here.
+@
+@ ARM docs say modify this bit in monitor mode only...
+mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
+ @ Allow hypervisor call.
+mcr p15, 0, r3, c1, c1, 0
+
+@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ldr r3, =0xF22020a8
+ldr r4, =0x50
+str r4, [r3]
+ldr r3, =0xF22020ac
+ldr r4, =0x14
+str r4, [r3]
+
+@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
+orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
+mcr p15, 6, r3, c12, c12, 5
+mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
+orr r3, #(ICC_SRE_EL1_SRE)
+mcr p15, 0, r3, c12, c12, 5
+
+@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+@ for EL2.
+mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
+orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+mcr p15, 4, r3, c12, c9, 5
+isb
+
+@ Back to SVC mode. TODO: Doesn't safe_svcmode_maskall do this for us anyway?
+cps #SVC_MODE
+```
diff --git a/MAINTAINERS b/MAINTAINERS
index b768b9da37a4..e707176c2114 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3775,6 +3775,7 @@ F: drivers/video/fbdev/wmt_ge_rops.*
ARM/ZTE ZX29 SOC SUPPORT
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zte.yaml
+F: arch/arm/mach-zte/
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@amd.com>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec33376f8e2b..4217ed704e48 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -464,6 +464,8 @@ source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vt8500/Kconfig"
+source "arch/arm/mach-zte/Kconfig"
+
source "arch/arm/mach-zynq/Kconfig"
# ARMv7-M architecture
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b7de4b6b284c..573813ef5e77 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -223,6 +223,7 @@ machine-$(CONFIG_ARCH_SUNXI) += sunxi
machine-$(CONFIG_ARCH_TEGRA) += tegra
machine-$(CONFIG_ARCH_U8500) += ux500
machine-$(CONFIG_ARCH_VT8500) += vt8500
+machine-$(CONFIG_ARCH_ZTE) += zte
machine-$(CONFIG_ARCH_ZYNQ) += zynq
machine-$(CONFIG_PLAT_VERSATILE) += versatile
machine-$(CONFIG_PLAT_SPEAR) += spear
diff --git a/arch/arm/mach-zte/Kconfig b/arch/arm/mach-zte/Kconfig
new file mode 100644
index 000000000000..2e3abee94994
--- /dev/null
+++ b/arch/arm/mach-zte/Kconfig
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menuconfig ARCH_ZTE
+ bool "ZTE zx family"
+ depends on ARCH_MULTI_V7
+ help
+ Support for ZTE zx-based family of processors.
+
+if ARCH_ZTE
+
+config SOC_ZX297520V3
+ default y if ARCH_ZTE
+ bool "zx297520v3"
+ select ARM_GIC_V3
+ select ARM_AMBA
+ select HAVE_ARM_ARCH_TIMER
+ select PM_GENERIC_DOMAINS if PM
+ help
+ Support for ZTE zx297520v3 SoC. It is a single core SoC used in cheap
+ LTE to WiFi routers. These devices can be identified by the occurrence
+ of the string "zx297520v3" in the boot output and /proc/cpuinfo of
+ their stock firmware.
+
+ Please read Documentation/arch/arm/zte/zx297520v3.rst on how to boot
+ the kernel.
+
+endif
diff --git a/arch/arm/mach-zte/Makefile b/arch/arm/mach-zte/Makefile
new file mode 100644
index 000000000000..1bfe4fddd6af
--- /dev/null
+++ b/arch/arm/mach-zte/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SOC_ZX297520V3) += zx297520v3.o
diff --git a/arch/arm/mach-zte/zx297520v3.c b/arch/arm/mach-zte/zx297520v3.c
new file mode 100644
index 000000000000..c11c7e836f91
--- /dev/null
+++ b/arch/arm/mach-zte/zx297520v3.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 Stefan Dösinger
+ */
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+static const char *const zx297520v3_dt_compat[] __initconst = {
+ "zte,zx297520v3",
+ NULL,
+};
+
+DT_MACHINE_START(ZX, "ZTE zx297520v3 (Device Tree)")
+ .dt_compat = zx297520v3_dt_compat,
+MACHINE_END
--
2.53.0
^ permalink raw reply related
* [PATCH v6 1/6] dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
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
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This adds a new binding file for ZTE, containing their zx297520v3 SoC
and one board (D-Link DWR-932M) based on it.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changelog:
v6:
Removed extra boards, I'll add them when submitting their individual
DTS files. Rephrase the subject to add "zte" and remove the redundant
use of "binding".
Moved the devicetree bindings patch ahead of the implementation patches.
Moved the MAINTAINERS section from "ZX29" to "ARM/ZTE".
---
Documentation/devicetree/bindings/arm/zte.yaml | 26 ++++++++++++++++++++++++++
MAINTAINERS | 4 ++++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/zte.yaml b/Documentation/devicetree/bindings/arm/zte.yaml
new file mode 100644
index 000000000000..f028d2cec7ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/zte.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/zte.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE zx platforms
+
+maintainers:
+ - Stefan Dösinger <stefandoesinger@gmail.com>
+
+description: |
+ ARM platforms using SoCs designed by ZTE. Currently this supports devices
+ based on the zx297520v3 SoC which is found in LTE routers.
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - dlink,dwr932m
+ - const: zte,zx297520v3
+
+additionalProperties: true
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..b768b9da37a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3772,6 +3772,10 @@ F: drivers/video/fbdev/vt8500lcdfb.*
F: drivers/video/fbdev/wm8505fb*
F: drivers/video/fbdev/wmt_ge_rops.*
+ARM/ZTE ZX29 SOC SUPPORT
+M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: Documentation/devicetree/bindings/arm/zte.yaml
+
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@amd.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox