* [PATCH v1 0/2] serial: 8250: Remove highly customised deprecated interface
From: Andy Shevchenko @ 2026-01-22 10:19 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby (SUSE), linux-doc,
linux-kernel, linux-serial
Cc: Jonathan Corbet, Shuah Khan, Kevin Hilman, Tony Lindgren
The custom divisor interface not only old and deprecated, it's too much
driver-dependent. For the user it's not easy to understand what to supply
as a value (usually encoded) via that interface. On top of it, there is
an existing BOTHER mechanism that allows to do the same and more without
any tribal knowledge.
Remove highly customised deprecated interface to set baud rates.
Note, the "standard" custom_divisor that is used as a plain value
for "quot" is still left and may be used by the respective drivers
including but not limited to 8250.
Andy Shevchenko (2):
serial: 8250_omap: Remove custom deprecated baud setting routine
serial: 8250_pci: Remove custom deprecated baud setting routine
Documentation/misc-devices/oxsemi-tornado.rst | 26 +-----
drivers/tty/serial/8250/8250_omap.c | 16 ----
drivers/tty/serial/8250/8250_pci.c | 85 ++++++++-----------
3 files changed, 38 insertions(+), 89 deletions(-)
--
2.50.1
^ permalink raw reply
* [PATCH v1 2/2] serial: 8250_pci: Remove custom deprecated baud setting routine
From: Andy Shevchenko @ 2026-01-22 10:19 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby (SUSE), linux-doc,
linux-kernel, linux-serial
Cc: Jonathan Corbet, Shuah Khan, Kevin Hilman, Tony Lindgren
In-Reply-To: <20260122102349.2395423-1-andriy.shevchenko@linux.intel.com>
As comments mentioned this is old (and actually deprecated) interface
to set custom baud rates. This interface has limitations as it only
allows to set a single opaque value called "custom_divisor". If the HW
needs more complex settings (like fractional divisor) it must somehow
encode this. This is horrid interface that is very driver specific
and not flexible. Meanwhile Linux has established way to set free
baud rate settings via BOTHER [1]. With all this being said, remove
deprecated interface for good.
Link: https://stackoverflow.com/questions/12646324/how-can-i-set-a-custom-baud-rate-on-linux [1]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Documentation/misc-devices/oxsemi-tornado.rst | 26 +-----
drivers/tty/serial/8250/8250_pci.c | 85 ++++++++-----------
2 files changed, 38 insertions(+), 73 deletions(-)
diff --git a/Documentation/misc-devices/oxsemi-tornado.rst b/Documentation/misc-devices/oxsemi-tornado.rst
index b33351bef6cf..fe2e5f726c2b 100644
--- a/Documentation/misc-devices/oxsemi-tornado.rst
+++ b/Documentation/misc-devices/oxsemi-tornado.rst
@@ -89,31 +89,7 @@ With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX
limitation imposed by ``serial8250_get_baud_rate`` standard baud rates
below 300bps become unavailable in the regular way, e.g. the rate of
200bps requires the baud base to be divided by 78125 and that is beyond
-the unsigned 16-bit range. The historic spd_cust feature can still be
-used by encoding the values for, the prescaler, the oversampling rate
-and the clock divisor (DLM/DLL) as follows to obtain such rates if so
-required:
-
-::
-
- 31 29 28 20 19 16 15 0
- +-----+-----------------+-------+-------------------------------+
- |0 0 0| CPR2:CPR | TCR | DLM:DLL |
- +-----+-----------------+-------+-------------------------------+
-
-Use a value such encoded for the ``custom_divisor`` field along with the
-ASYNC_SPD_CUST flag set in the ``flags`` field in ``struct serial_struct``
-passed with the TIOCSSERIAL ioctl(2), such as with the setserial(8)
-utility and its ``divisor`` and ``spd_cust`` parameters, and then select
-the baud rate of 38400bps. Note that the value of 0 in TCR sets the
-oversampling rate to 16 and prescaler values below 1 in CPR2/CPR are
-clamped by the driver to 1.
-
-For example the value of 0x1f4004e2 will set CPR2/CPR, TCR and DLM/DLL
-respectively to 0x1f4, 0x0 and 0x04e2, choosing the prescaler value,
-the oversampling rate and the clock divisor of 62.500, 16 and 1250
-respectively. These parameters will set the baud rate for the serial
-port to 62500000 / 62.500 / 1250 / 16 = 50bps.
+the unsigned 16-bit range.
Maciej W. Rozycki <macro@orcam.me.uk>
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 3efe075ef7b2..6589bb531cc6 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1205,60 +1205,49 @@ static unsigned int pci_oxsemi_tornado_get_divisor(struct uart_port *port,
u8 tcr;
int i;
- /* Old custom speed handling. */
- if (baud == 38400 && (port->flags & UPF_SPD_MASK) == UPF_SPD_CUST) {
- unsigned int cust_div = port->custom_divisor;
+ best_squot = quot_scale;
+ for (i = 0; i < ARRAY_SIZE(p); i++) {
+ unsigned int spre;
+ unsigned int srem;
+ u8 cp;
+ u8 tc;
- quot = cust_div & UART_DIV_MAX;
- tcr = (cust_div >> 16) & OXSEMI_TORNADO_TCR_MASK;
- cpr = (cust_div >> 20) & OXSEMI_TORNADO_CPR_MASK;
- if (cpr < OXSEMI_TORNADO_CPR_MIN)
- cpr = OXSEMI_TORNADO_CPR_DEF;
- } else {
- best_squot = quot_scale;
- for (i = 0; i < ARRAY_SIZE(p); i++) {
- unsigned int spre;
- unsigned int srem;
- u8 cp;
- u8 tc;
+ tc = p[i][0];
+ cp = p[i][1];
+ spre = tc * cp;
- tc = p[i][0];
- cp = p[i][1];
- spre = tc * cp;
+ srem = sdiv % spre;
+ if (srem > spre / 2)
+ srem = spre - srem;
+ squot = DIV_ROUND_CLOSEST(srem * quot_scale, spre);
- srem = sdiv % spre;
- if (srem > spre / 2)
- srem = spre - srem;
- squot = DIV_ROUND_CLOSEST(srem * quot_scale, spre);
-
- if (srem == 0) {
- tcr = tc;
- cpr = cp;
- quot = sdiv / spre;
- break;
- } else if (squot < best_squot) {
- best_squot = squot;
- tcr = tc;
- cpr = cp;
- quot = DIV_ROUND_CLOSEST(sdiv, spre);
- }
+ if (srem == 0) {
+ tcr = tc;
+ cpr = cp;
+ quot = sdiv / spre;
+ break;
+ } else if (squot < best_squot) {
+ best_squot = squot;
+ tcr = tc;
+ cpr = cp;
+ quot = DIV_ROUND_CLOSEST(sdiv, spre);
}
- while (tcr <= (OXSEMI_TORNADO_TCR_MASK + 1) >> 1 &&
- quot % 2 == 0) {
+ }
+ while (tcr <= (OXSEMI_TORNADO_TCR_MASK + 1) >> 1 &&
+ quot % 2 == 0) {
+ quot >>= 1;
+ tcr <<= 1;
+ }
+ while (quot > UART_DIV_MAX) {
+ if (tcr <= (OXSEMI_TORNADO_TCR_MASK + 1) >> 1) {
quot >>= 1;
tcr <<= 1;
- }
- while (quot > UART_DIV_MAX) {
- if (tcr <= (OXSEMI_TORNADO_TCR_MASK + 1) >> 1) {
- quot >>= 1;
- tcr <<= 1;
- } else if (cpr <= OXSEMI_TORNADO_CPR_MASK >> 1) {
- quot >>= 1;
- cpr <<= 1;
- } else {
- quot = quot * cpr / OXSEMI_TORNADO_CPR_MASK;
- cpr = OXSEMI_TORNADO_CPR_MASK;
- }
+ } else if (cpr <= OXSEMI_TORNADO_CPR_MASK >> 1) {
+ quot >>= 1;
+ cpr <<= 1;
+ } else {
+ quot = quot * cpr / OXSEMI_TORNADO_CPR_MASK;
+ cpr = OXSEMI_TORNADO_CPR_MASK;
}
}
--
2.50.1
^ permalink raw reply related
* [PATCH v1 1/2] serial: 8250_omap: Remove custom deprecated baud setting routine
From: Andy Shevchenko @ 2026-01-22 10:19 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby (SUSE), linux-doc,
linux-kernel, linux-serial
Cc: Jonathan Corbet, Shuah Khan, Kevin Hilman, Tony Lindgren
In-Reply-To: <20260122102349.2395423-1-andriy.shevchenko@linux.intel.com>
As comments mentioned this is old (and actually deprecated) interface
to set custom baud rates. This interface has limitations as it only
allows to set a single opaque value called "custom_divisor". If the HW
needs more complex settings (like fractional divisor) it must somehow
encode this. This is horrid interface that is very driver specific
and not flexible. Meanwhile Linux has established way to set free
baud rate settings via BOTHER [1]. With all this being said, remove
deprecated interface for good.
Link: https://stackoverflow.com/questions/12646324/how-can-i-set-a-custom-baud-rate-on-linux [1]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/tty/serial/8250/8250_omap.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 4496f692b86b..427719c158b7 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -243,22 +243,6 @@ static void omap_8250_get_divisor(struct uart_port *port, unsigned int baud,
unsigned int div_13, div_16;
unsigned int abs_d13, abs_d16;
- /*
- * Old custom speed handling.
- */
- if (baud == 38400 && (port->flags & UPF_SPD_MASK) == UPF_SPD_CUST) {
- priv->quot = port->custom_divisor & UART_DIV_MAX;
- /*
- * I assume that nobody is using this. But hey, if somebody
- * would like to specify the divisor _and_ the mode then the
- * driver is ready and waiting for it.
- */
- if (port->custom_divisor & (1 << 16))
- priv->mdr1 = UART_OMAP_MDR1_13X_MODE;
- else
- priv->mdr1 = UART_OMAP_MDR1_16X_MODE;
- return;
- }
div_13 = DIV_ROUND_CLOSEST(uartclk, 13 * baud);
div_16 = DIV_ROUND_CLOSEST(uartclk, 16 * baud);
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v5 06/11] dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
From: Robert Marko @ 2026-01-22 9:35 UTC (permalink / raw)
To: Linus Walleij
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial, luka.perkov, Conor Dooley
In-Reply-To: <CAD++jLmitNVhWmUf9BBqLR2_WsAR7V-+ykVJsLK3MuOSUKQF0A@mail.gmail.com>
On Wed, Jan 21, 2026 at 1:44 PM Linus Walleij <linusw@kernel.org> wrote:
>
> Hi Robert,
>
> On Thu, Jan 15, 2026 at 12:41 PM Robert Marko <robert.marko@sartura.hr> wrote:
>
> > Document LAN969x compatibles for SGPIO.
> >
> > Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
>
> Should I just merge this one patch to the pinctrl tree?
That would be great as other bindings are slowly being picked into
their respective trees.
Regards,
Robert
> Looks good to me.
>
> Yours,
> Linus Walleij
--
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr
^ permalink raw reply
* Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-01-22 8:52 UTC (permalink / raw)
To: Herve Codina
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Bartosz Golaszewski, Sui Jingfeng
In-Reply-To: <20260114134004.11023a7e@bootlin.com>
On Wed, Jan 14, 2026 at 01:40:04PM +0100, Herve Codina wrote:
> On Mon, 12 Jan 2026 10:18:41 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> > +Cc: Herve (btw, any news on LAN966x support?)
>
> Related to LAN966x support, I am still stucked on issues related to
> fw_devlink and DT overlays [1].
Thank you for the update and your reply here!
> [1] https://lore.kernel.org/all/20260112154731.6540453b@bootlin.com/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback
From: Andy Shevchenko @ 2026-01-22 8:51 UTC (permalink / raw)
To: Sui Jingfeng
Cc: manivannan.sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi
In-Reply-To: <26a001c3-2140-4241-87dd-604eab3f827b@linux.dev>
On Wed, Jan 14, 2026 at 11:21:59AM +0800, Sui Jingfeng wrote:
> On 2026/1/12 15:56, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > Because the software node backend of the fwnode API framework lacks an
> > > implementation for the .device_get_match_data function callback.
> > Maybe this is done on purpose.
>
> It is a *fact* that the broken swnode lacks an implementation for the .device_get_match_data stub.
No need to re-create board files when it's not needed or doesn't fit.
> Otherwise, If it is really done *on purpose*, the maintainers of swnode
> backend could/shall document it in the source file *explicitly*.
Probably it should be spoken in a better way.
> > Have you thought about this aspect?
>
> If you are sure, then stop telling us something start with "Maybe ..."
I wasn't the author of the swnode idea I can't read their minds. Please,
ask the respective people about this directly.
> > > This makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> > How difficult?
>
> The emphasis isn't on the 'difficult', it means that not convenient
>
> > DSA implementation went to the way of taking DT overlay
> > approach.
>
> Software node can do the same implementation just as what ACPI fwnode backend does.
>
> > Why that one can't be applied here?
>
> DT overlay requires the OS distribution(such as ubuntu) has theDT overlay
> config option selected. this is introduce extra overhead/side effects on the
> non-DT systems.
If we have hotpluggable or runtime reconfigurable devices this is the expected
option to support them. I don't see a problem here.
> > > Implement the .device_get_match_data fwnode callback, which helps to keep
> > > the three backends of the fwnode API aligned as much as possible. This is
> > > also a fundamental step to make a few drivers OF-independent truely
> > > possible.
> > >
> > > Device drivers or platform setup codes are expected to provide a software
> > > node string property, named as "compatible". At this moment, the value of
> > > this string property is being used to match against the compatible entries
> > > in the of_device_id table. It can be extended in the future though.
> > I really do not want to see this patch
>
> Whatever!
>
> Then just stop the endless, bruth-force ranting on such a straight-forward thing.
>
> > without very good justification
>
> Justifications has been provided over and over again.
>
> > (note, there were at least two attempts in the past
>
> This exactly saying that the implementation is missing.
Now you count a third one for your pleasure :-)
P.S.
We already had this discussion in the past and this attitude won't help
moving forward.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] serial: 8250_pci: Fix uninitialized variable use in pci_oxsemi_tornado_get_divisor
From: Lee Yongjun @ 2026-01-22 0:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, linux-serial, linux-kernel, Andy Shevchenko
In-Reply-To: <2026012141-arrival-mounted-0d49@gregkh>
Hi Greg,
Thanks for the clarification.
I agree that this case cannot occur in practice and the current code is
fine as-is. I will drop this patch.
Thanks,
Lee Yongjun
Hi Greg,
Thanks for the clarification.
I agree that this case cannot occur in practice and the current code is
fine as-is. I will drop this patch.
Thanks,
Lee Yongjun
^ permalink raw reply
* Re: [PATCH] serial: 8250 dw: clear FIFO before writting LCR
From: Adriana Nicolae @ 2026-01-21 16:55 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: linux-serial, Andy Shevchenko, prasad
In-Reply-To: <faf3bae5-4656-7c47-d875-9103a5f2079e@linux.intel.com>
On Wed, Jan 21, 2026 at 4:31 PM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Fri, 31 Oct 2025, Adriana Nicolae wrote:
>
> > On Wed, Oct 8, 2025 at 4:12 PM Ilpo Järvinen
> > <ilpo.jarvinen@linux.intel.com> wrote:
> > >
> > > On Wed, 8 Oct 2025, Adriana Nicolae wrote:
> > > > Hello, Sorry for missing an update, the exact root cause is not clear, currently the
> > > > brute force method of draining FIFO right before setting or clearing DLAB was stable
> > > > during tests.
> > > >
> > > > The serial stuck seems to be a failed attempt to clear the DLAB.
> > > > This operation fails because the USR indicates the hardware is
> > > > still busy, even though the UART is in loopback mode and should
> > > > be inactive.
> > > >
> > > > To isolate the issue, I tried the following without success:
> > > > - Added delays: I inserted 100 repeated ndelay(p->frame_time)
> > > > calls before and after enabling loopback mode to allow the FIFO
> > > > to clear.
> > > > - Cleared FIFO: I explicitly cleared the FIFO in addition to
> > > > adding the delay.
> > > > - Checked status: I printed the LSR just before the DLAB clear
> > > > attempt and checked the USB busy bit.
> > >
> > > Okay, so the BUSY must be stuck asserted.
> > >
> > > Another idea, maybe test tx + rx over loopback to see if that manages to
> > > de-freeze the BUSY bit. A patch to that effect below.
> > >
> > > (I've only added the new block into dw8250_idle_enter() compared with the
> > > old patch but rebasing to tty-next resulted in some other changes due to
> > > conflicts.)
> >
> > I've tested the new dw8250_idle_enter() sequence, and you're right,
> > the BUSY bit remains set after entering loopback mode.
> >
> > However, the sequence in the patch (including the single loopback
> > tx/rx) wasn't quite enough. I didn't see any kernel panics or console
> > stuck anymore, but I've monitored the traces and there were cases when
> > the trace after "p->serial_out(p, UART_LCR, up->lcr);" showed both
> > BUSY bit set and DLAB bit still enabled.
> >
> > >
> > > Only thing besides BUSY being stuck asserted is something Tx'ing after the
> > > idle enter sequence. I think we could trap/check that too in
> > > dw8250_serial_out() by using something along these lines:
> > >
> > > if (d->in_idle && offset == UART_TX) {
> > > WARN_ON_ONCE(1);
> > > return;
> > > }
> > >
> > > (I think that should catch even console writes but I'm not 100% sure of
> > > that and it will should get us where the rogue Tx originates from).
> >
> > I also added the WARN_ON_ONCE check you suggested in
> > dw8250_serial_out(). The warning has not triggered, so it seems we
> > don't have a rogue Tx firing while in_idle is set.
> >
> > >
> > > > The critical finding was that immediately before the DLAB clear
> > > > operation (p->serial_out(p, UART_LCR, up->lcr);), the LSR value
> > > > was 0x6a and the USR busy bit [0] was set. This confirms the UART
> > > > is busy, which blocks the DLAB modification.
> > > >
> > > > This is occurring on a device with a single UART console. The setup
> > > > does not use DMA or modem control; only the Rx/Tx lines are connected.
> > > >
> > > > The trace below, from a single process, shows one successful DLAB
> > > > clear followed by a failing one. The second attempt repeatedly logs
> > > > "USR still busy" before eventually succeeding. This can lead to
> > > > subsequent failures in dw8250_check_lcr: dw8250_idle_entered.
> > > >
> > > > Trace Log:
> > > >
> > > > <...>-15440 8583.592533: dw8250_idle_enter: in_idle = 1
> > > > login-15440 8583.713817: dw8250_idle_enter: in loopback mode
> > > > login-15440 8583.835099: dw8250_idle_enter: LSR in loopback mode is 0x63
> > > > login-15440 8583.835103: dw8250_set_divisor: UART_LCR_DLAB cleared 13
> > > > login-15440 8583.835104: dw8250_idle_exit: idle exit
> > > > login-15440 8583.835105: dw8250_idle_exit: out of loopback mode
> > > > login-15440 8583.835105: dw8250_idle_exit: in_idle = 0
> > > > login-15440 8583.835352: dw8250_idle_enter: in_idle = 1
> > > > login-15440 8583.956633: dw8250_idle_enter: in loopback mode
> > > > login-15440 8583.956638: dw8250_idle_enter: LSR in loopback mode is 0x6a
> > > > login-15440 8583.963918: dw8250_set_divisor: USR still busy dl_write
> > > > login-15440 8584.000332: dw8250_set_divisor: USR still busy dl_write
> > > > login-15440 8584.040385: dw8250_set_divisor: USR still busy dl_write
> > > > login-15440 8584.078012: dw8250_set_divisor: UART_LCR_DLAB cleared 93
> > > > login-15440 8584.078013: dw8250_idle_exit: idle exit
> > > > login-15440 8584.078014: dw8250_idle_exit: out of loopback mode
> > > > login-15440 8584.078015: dw8250_idle_exit: in_idle = 0
> > >
> > >
> > >
> > > --
> > > From 01df58736a10f7f34aca895ef08e5519953f8572 Mon Sep 17 00:00:00 2001
> > > From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
> > > Date: Wed, 8 Oct 2025 15:40:19 +0300
> > > Subject: [PATCH 1/1] serial: 8250_dw: Ensure BUSY is deasserted
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: 8bit
> > >
> > > DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
> > > Existance of BUSY depends on uart_16550_compatible, if UART HW is
> > > configured with 16550 compatible those registers can always be
> > > written.
> > >
> > > There currently is dw8250_force_idle() which attempts to archive
> > > non-BUSY state by disabling FIFO, however, the solution is unreliable
> > > when Rx keeps getting more and more characters.
> > >
> > > Create a sequence of operations to enforce that ensures UART cannot
> > > keep BUSY asserted indefinitely. The new sequence relies on enabling
> > > loopback mode temporarily to prevent incoming Rx characters keeping
> > > UART BUSY.
> > >
> > > Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
> > > writes.
> > >
> > > This issue was reported by qianfan Zhao who put lots of debugging
> > > effort into understanding the solution space.
> > >
> > > Reported-by: qianfan Zhao <qianfanguijin@163.com>
> > > Reported-by: Adriana Nicolae <adriana@arista.com>
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > ---
> > > drivers/tty/serial/8250/8250_dw.c | 159 +++++++++++++++++++++---------
> > > 1 file changed, 115 insertions(+), 44 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> > > index a53ba04d9770..8e25dfe8e653 100644
> > > --- a/drivers/tty/serial/8250/8250_dw.c
> > > +++ b/drivers/tty/serial/8250/8250_dw.c
> > > @@ -42,6 +42,8 @@
> > > /* DesignWare specific register fields */
> > > #define DW_UART_MCR_SIRE BIT(6)
> > >
> > > +#define DW_UART_USR_BUSY BIT(0)
> > > +
> > > /* Renesas specific register fields */
> > > #define RZN1_UART_xDMACR_DMA_EN BIT(0)
> > > #define RZN1_UART_xDMACR_1_WORD_BURST (0 << 1)
> > > @@ -77,6 +79,7 @@ struct dw8250_data {
> > >
> > > unsigned int skip_autocfg:1;
> > > unsigned int uart_16550_compatible:1;
> > > + unsigned int in_idle:1;
> > > };
> > >
> > > static inline struct dw8250_data *to_dw8250_data(struct dw8250_port_data *data)
> > > @@ -108,36 +111,103 @@ static inline u32 dw8250_modify_msr(struct uart_port *p, unsigned int offset, u3
> > > }
> > >
> > > /*
> > > - * This function is being called as part of the uart_port::serial_out()
> > > - * routine. Hence, it must not call serial_port_out() or serial_out()
> > > - * against the modified registers here, i.e. LCR.
> > > + * Ensure BUSY is not asserted. If DW UART is configured with
> > > + * !uart_16550_compatible, the writes to LCR, DLL, and DLH fail while
> > > + * BUSY is asserted.
> > > + *
> > > + * Context: port's lock must be held
> > > */
> > > -static void dw8250_force_idle(struct uart_port *p)
> > > +static int dw8250_idle_enter(struct uart_port *p)
> > > {
> > > + struct dw8250_data *d = to_dw8250_data(p->private_data);
> > > struct uart_8250_port *up = up_to_u8250p(p);
> > > - unsigned int lsr;
> > > + u32 lsr;
> > >
> > > - /*
> > > - * The following call currently performs serial_out()
> > > - * against the FCR register. Because it differs to LCR
> > > - * there will be no infinite loop, but if it ever gets
> > > - * modified, we might need a new custom version of it
> > > - * that avoids infinite recursion.
> > > - */
> > > - serial8250_clear_and_reinit_fifos(up);
> > > + if (d->uart_16550_compatible)
> > > + return 0;
> > > +
> > > + d->in_idle = 1;
> > > +
> > > + /* Prevent triggering interrupt from RBR filling */
> > > + p->serial_out(p, UART_IER, 0);
> > > +
> > > + serial8250_rx_dma_flush(up);
> > > + // What about Tx DMA? Should probably pause that too and resume
> > > + // afterwards.
> > > +
> > > + p->serial_out(p, UART_MCR, up->mcr | UART_MCR_LOOP);
> > > + if (up->capabilities & UART_CAP_FIFO)
> > > + p->serial_out(p, UART_FCR, 0);
> >
> > Changing this to repeatedly clear the FIFO turned out to reliably
> > clear the BUSY bit , also no kernel panic or device stuck in busy
> > mode.
> >
> > On the device I tested the first clear is not always enough, under
> > high load I saw it cleared on the second iteration. I'm thinking it
> > might be some particular issue with the device I'm using where the
> > first FIFO clear might fail. I never encountered more than 2
> > iterations with a "ndelay(p->frame_time);" in between here to get out
> > of BUSY state.
>
> Hi,
>
> I seem to have missed this email until now (I'm sorry about that, though
> to my defence, IIRC, I was quite sick around that timeframe it was sent
> and clear the email backlog isn't ever fun and may end up missing
> something).
>
> Do you mean changing this to a simple loop or writing something else than
> just 0 to FCR (or perhaps calling serial8250_clear_fifos())?
>
> What is the exact code that you found working?
>
Yes, everything worked ok for me after changing the dw8250_idle_enter
function with the one below. From traces added in the function, it
sometimes reported iterations_in_busy = 2 but never higher than that.
The function only has the prepended "while(p->serial_in(p,
d->pdata->usr_reg) & DW_UART_USR_BUSY) {" to iterate forever, although
it was at most 2 iterations when serial was stressed:
static int dw8250_idle_enter(struct uart_port *p)
{
struct dw8250_data *d = to_dw8250_data(p->private_data);
struct uart_8250_port *up = up_to_u8250p(p);
u32 lsr, iterations_in_busy = 0;
if (d->uart_16550_compatible)
return 0;
d->in_idle = 1;
/* Prevent triggering interrupt from RBR filling */
p->serial_out(p, UART_IER, 0);
serial8250_rx_dma_flush(up);
// What about Tx DMA? Should probably pause that too and resume
// afterwards.
p->serial_out(p, UART_MCR, up->mcr | UART_MCR_LOOP);
while(p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
if (up->capabilities & UART_CAP_FIFO) {
p->serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
p->serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO |
UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
p->serial_out(p, UART_FCR, 0);
}
ndelay(p->frame_time);
iterations_in_busy++;
}
trace_printk("Not busy got after %d\n", iterations_in_busy);
lsr = serial_lsr_in(up);
if (lsr & UART_LSR_DR) {
p->serial_in(p, UART_RX);
up->lsr_saved_flags = 0;
}
/*
* BUSY might still be frozen to asserted, try to de-freeze it by
* sending a character over the loopback and receiving it.
*/
if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
trace_printk("Serial USR still busy\n");
p->serial_out(p, UART_TX, 0);
ndelay(1000);
lsr = serial_lsr_in(up);
if (lsr & UART_LSR_DR) {
p->serial_in(p, UART_RX);
up->lsr_saved_flags = 0;
}
}
/* Now guaranteed to have BUSY deasserted? Just sanity check */
if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
trace_printk("BUSY\n");
return -EBUSY;
}
return 0;
}
> So when you fixed this FIFO clearing thing, everything seemed to work okay
> after that?
>
> In the meantime, this issue has once again been reported to me by somebody
> else, and I've done improvements to shutdown code as well to address a
> few BUSY related problems (I'll be posting a series that solved that
> case soon but I suppose this patch needs amendments based on input from
> your case).
>
> --
> i.
>
> > > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY)
> > > + ndelay(p->frame_time);
> > > +
> > > + lsr = serial_lsr_in(up);
> > > + if (lsr & UART_LSR_DR) {
> > > + p->serial_in(p, UART_RX);
> > > + up->lsr_saved_flags = 0;
> > > + }
> > >
> > > /*
> > > - * With PSLVERR_RESP_EN parameter set to 1, the device generates an
> > > - * error response when an attempt to read an empty RBR with FIFO
> > > - * enabled.
> > > + * BUSY might still be frozen to asserted, try to de-freeze it by
> > > + * sending a character over the loopback and receiving it.
> > > */
> > > - if (up->fcr & UART_FCR_ENABLE_FIFO) {
> > > - lsr = serial_port_in(p, UART_LSR);
> > > - if (!(lsr & UART_LSR_DR))
> > > - return;
> > > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
> > > + p->serial_out(p, UART_TX, 0);
> > > + ndelay(p->frame_time);
> > > + lsr = serial_lsr_in(up);
> > > + if (lsr & UART_LSR_DR) {
> > > + p->serial_in(p, UART_RX);
> > > + up->lsr_saved_flags = 0;
> > > + }
> > > }
> > >
> > > - serial_port_in(p, UART_RX);
> > > + /* Now guaranteed to have BUSY deasserted? Just sanity check */
> > > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY)
> > > + return -EBUSY;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void dw8250_idle_exit(struct uart_port *p)
> > > +{
> > > + struct dw8250_data *d = to_dw8250_data(p->private_data);
> > > + struct uart_8250_port *up = up_to_u8250p(p);
> > > +
> > > + if (d->uart_16550_compatible)
> > > + return;
> > > +
> > > + if (up->capabilities & UART_CAP_FIFO)
> > > + p->serial_out(p, UART_FCR, up->fcr);
> > > + p->serial_out(p, UART_MCR, up->mcr);
> > > + p->serial_out(p, UART_IER, up->ier);
> > > +
> > > + // Maybe move the DMA Rx restart check in dma_rx_complete() to own
> > > + // function (serial8250_rx_dma_restart()) and call it from here.
> > > + // DMA Tx resume
> > > +
> > > + d->in_idle = 0;
> > > +}
> > > +
> > > +static void dw8250_set_divisor(struct uart_port *p, unsigned int baud,
> > > + unsigned int quot, unsigned int quot_frac)
> > > +{
> > > + struct uart_8250_port *up = up_to_u8250p(p);
> > > + int ret;
> > > +
> > > + ret = dw8250_idle_enter(p);
> > > + if (ret < 0)
> > > + goto idle_failed;
> > > +
> > > + p->serial_out(p, UART_LCR, up->lcr | UART_LCR_DLAB);
> > > + if (!(p->serial_in(p, UART_LCR) & UART_LCR_DLAB))
> > > + goto idle_failed;
> > > +
> > > + serial_dl_write(up, quot);
> > > + p->serial_out(p, UART_LCR, up->lcr);
> > > +
> > > +idle_failed:
> > > + dw8250_idle_exit(p);
> > > }
> > >
> > > /*
> > > @@ -148,37 +218,37 @@ static void dw8250_force_idle(struct uart_port *p)
> > > static void dw8250_check_lcr(struct uart_port *p, unsigned int offset, u32 value)
> > > {
> > > struct dw8250_data *d = to_dw8250_data(p->private_data);
> > > - void __iomem *addr = p->membase + (offset << p->regshift);
> > > - int tries = 1000;
> > > + u32 lcr = p->serial_in(p, UART_LCR);
> > > + int ret;
> > >
> > > if (offset != UART_LCR || d->uart_16550_compatible)
> > > return;
> > >
> > > /* Make sure LCR write wasn't ignored */
> > > - while (tries--) {
> > > - u32 lcr = serial_port_in(p, offset);
> > > -
> > > - if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
> > > - return;
> > > + if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
> > > + return;
> > >
> > > - dw8250_force_idle(p);
> > > + if (d->in_idle) {
> > > + /*
> > > + * FIXME: this deadlocks if port->lock is already held
> > > + * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> > > + */
> > > + return;
> > > + }
> > >
> > > -#ifdef CONFIG_64BIT
> > > - if (p->type == PORT_OCTEON)
> > > - __raw_writeq(value & 0xff, addr);
> > > - else
> > > -#endif
> > > - if (p->iotype == UPIO_MEM32)
> > > - writel(value, addr);
> > > - else if (p->iotype == UPIO_MEM32BE)
> > > - iowrite32be(value, addr);
> > > - else
> > > - writeb(value, addr);
> > > + ret = dw8250_idle_enter(p);
> > > + if (ret < 0) {
> > > + /*
> > > + * FIXME: this deadlocks if port->lock is already held
> > > + * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> > > + */
> > > + goto idle_failed;
> > > }
> > > - /*
> > > - * FIXME: this deadlocks if port->lock is already held
> > > - * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> > > - */
> > > +
> > > + p->serial_out(p, UART_LCR, value);
> > > +
> > > +idle_failed:
> > > + dw8250_idle_exit(p);
> > > }
> > >
> > > /* Returns once the transmitter is empty or we run out of retries */
> > > @@ -547,6 +617,7 @@ static int dw8250_probe(struct platform_device *pdev)
> > > p->dev = dev;
> > > p->set_ldisc = dw8250_set_ldisc;
> > > p->set_termios = dw8250_set_termios;
> > > + p->set_divisor = dw8250_set_divisor;
> > >
> > > data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > > if (!data)
> > >
> > > base-commit: d21b26cad33250be758ea9d860ff9d5c3992c459
> > > --
> > > 2.39.5
> >
^ permalink raw reply
* Re: [PATCH] serial: 8250_pci: Fix uninitialized variable use in pci_oxsemi_tornado_get_divisor
From: Greg Kroah-Hartman @ 2026-01-21 16:36 UTC (permalink / raw)
To: Lee Yongjun; +Cc: Jiri Slaby, linux-serial, linux-kernel, Andy Shevchenko
In-Reply-To: <20260121155352.52489-1-jun85566@gmail.com>
On Thu, Jan 22, 2026 at 12:53:52AM +0900, Lee Yongjun wrote:
> Smatch reports the following errors:
>
> drivers/tty/serial/8250/8250_pci.c:1246 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'tcr'.
> drivers/tty/serial/8250/8250_pci.c:1247 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'quot'.
> drivers/tty/serial/8250/8250_pci.c:1251 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'quot'.
> drivers/tty/serial/8250/8250_pci.c:1255 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'cpr'.
> drivers/tty/serial/8250/8250_pci.c:1265 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'cpr'.
>
> These variables are initialized in the if branch or inside the loop in
> the else branch. However, if the loop finishes without finding a suitable
> divisor, they remain uninitialized.
But can that ever really happen? Please step through it all with the
values that the hardware provides to see this.
> Initialize 'quot', 'cpr', and 'tcr' to 0 to prevent undefined behavior.
Why haven't we seen any real problems with this? I think this is ok
as-is. Maybe a little bit complex and non-intutive, but ok.
thanks,
greg k-h
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Petr Mladek @ 2026-01-21 16:08 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Steven Rostedt, linux-kernel, linux-serial, linux-fbdev,
John Ogness, Sergey Senozhatsky, Greg Kroah-Hartman, Jiri Slaby,
Simona Vetter, Helge Deller
In-Reply-To: <20260121135737.K7b-4M5r@linutronix.de>
On Wed 2026-01-21 14:57:37, Sebastian Andrzej Siewior wrote:
> On 2026-01-21 14:43:45 [+0100], Petr Mladek wrote:
> > I know that there was a plan to get rid of cond_resched().
> > But what is the status now, please?
>
> It is slowly moving => https://lore.kernel.org/all/20251219101502.GB1132199@noisy.programming.kicks-ass.net/
Good to know.
> > I still see more that 1k cond_resched() calls in the code:
> >
> > $> git grep cond_resched\(\) | grep "\.c:" | wc -l
> > 1263
> >
> > And config PREEMPT_VOLUNTARY still talks about the explicit
> > preemption points.
> >
> > > Should we just remove it and see what breaks?
> >
> > Honestly, I do not feel comfortable with removing it. It is true that
> > it has no effect in the printk() code path. But the vt code is used
> > also when working on the terminal.
> >
> > The vt code still uses console_lock() because it was intertwined
> > with printk console code since very old days. console_lock is a kind
> > of big kernel lock there.
>
> Do you a have path which loops and would mandate it? I found a few which
> do not matter and have their own cond_resched() around. So I don't see a
> reason to keep it. And I found one which breaks things so a removal
> makes sense.
Could anyone from VT guys comment on it, please?
> > Alternative solution is to get rid of the spin_trylock(). The only
> > purpose is to prevent race in console_flush_on_panic(). It used
> > to be a simple bit operation. The spin_lock() was added just to
> > get barriers right. But we have a great atomic_t API these days.
> >
> > IMHO, it is a win-win solution because a preemptive context is
> > always better.
>
> So why do we keep warts again? Just because it *might* be required?
> Keeping things preemptible makes sense but this is locking with no
> annotation what so ever.
Well, the current locking is documented but it creates false
positives. The "printing_lock" is taken on a single place
using spin_trylock(). Nobody would ever spin on it. So
sleeping is perfectly fine.
> Again. printk has its cond_resched, the tty has it, too.
> I'm with Steven on the removal side.
As I said, the cond_resched() does not have any effect from
the printk() code path. But the other VT paths might rely on it.
If VT-guys are willing to take the risk and remove it
then I am fine with it.
Best Regards,
Petr
^ permalink raw reply
* [PATCH] serial: 8250_pci: Fix uninitialized variable use in pci_oxsemi_tornado_get_divisor
From: Lee Yongjun @ 2026-01-21 15:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-serial, linux-kernel, Andy Shevchenko, Lee Yongjun
Smatch reports the following errors:
drivers/tty/serial/8250/8250_pci.c:1246 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'tcr'.
drivers/tty/serial/8250/8250_pci.c:1247 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'quot'.
drivers/tty/serial/8250/8250_pci.c:1251 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'quot'.
drivers/tty/serial/8250/8250_pci.c:1255 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'cpr'.
drivers/tty/serial/8250/8250_pci.c:1265 pci_oxsemi_tornado_get_divisor() error: uninitialized symbol 'cpr'.
These variables are initialized in the if branch or inside the loop in
the else branch. However, if the loop finishes without finding a suitable
divisor, they remain uninitialized.
Initialize 'quot', 'cpr', and 'tcr' to 0 to prevent undefined behavior.
Signed-off-by: Lee Yongjun <jun85566@gmail.com>
---
drivers/tty/serial/8250/8250_pci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index c5a932f48f74..b32d7e03c29a 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1200,9 +1200,9 @@ static unsigned int pci_oxsemi_tornado_get_divisor(struct uart_port *port,
unsigned int sdiv = DIV_ROUND_CLOSEST(sclk, baud);
unsigned int best_squot;
unsigned int squot;
- unsigned int quot;
- u16 cpr;
- u8 tcr;
+ unsigned int quot = 0;
+ u16 cpr = 0;
+ u8 tcr = 0;
int i;
/* Old custom speed handling. */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] serial: 8250 dw: clear FIFO before writting LCR
From: Ilpo Järvinen @ 2026-01-21 14:31 UTC (permalink / raw)
To: Adriana Nicolae; +Cc: linux-serial, Andy Shevchenko, prasad
In-Reply-To: <CAERbo5yjKDrVdfAZEAzWqeTSXoZJE_GZqbwov-4KGs1BPpwCiQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 16100 bytes --]
On Fri, 31 Oct 2025, Adriana Nicolae wrote:
> On Wed, Oct 8, 2025 at 4:12 PM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> >
> > On Wed, 8 Oct 2025, Adriana Nicolae wrote:
> > > Hello, Sorry for missing an update, the exact root cause is not clear, currently the
> > > brute force method of draining FIFO right before setting or clearing DLAB was stable
> > > during tests.
> > >
> > > The serial stuck seems to be a failed attempt to clear the DLAB.
> > > This operation fails because the USR indicates the hardware is
> > > still busy, even though the UART is in loopback mode and should
> > > be inactive.
> > >
> > > To isolate the issue, I tried the following without success:
> > > - Added delays: I inserted 100 repeated ndelay(p->frame_time)
> > > calls before and after enabling loopback mode to allow the FIFO
> > > to clear.
> > > - Cleared FIFO: I explicitly cleared the FIFO in addition to
> > > adding the delay.
> > > - Checked status: I printed the LSR just before the DLAB clear
> > > attempt and checked the USB busy bit.
> >
> > Okay, so the BUSY must be stuck asserted.
> >
> > Another idea, maybe test tx + rx over loopback to see if that manages to
> > de-freeze the BUSY bit. A patch to that effect below.
> >
> > (I've only added the new block into dw8250_idle_enter() compared with the
> > old patch but rebasing to tty-next resulted in some other changes due to
> > conflicts.)
>
> I've tested the new dw8250_idle_enter() sequence, and you're right,
> the BUSY bit remains set after entering loopback mode.
>
> However, the sequence in the patch (including the single loopback
> tx/rx) wasn't quite enough. I didn't see any kernel panics or console
> stuck anymore, but I've monitored the traces and there were cases when
> the trace after "p->serial_out(p, UART_LCR, up->lcr);" showed both
> BUSY bit set and DLAB bit still enabled.
>
> >
> > Only thing besides BUSY being stuck asserted is something Tx'ing after the
> > idle enter sequence. I think we could trap/check that too in
> > dw8250_serial_out() by using something along these lines:
> >
> > if (d->in_idle && offset == UART_TX) {
> > WARN_ON_ONCE(1);
> > return;
> > }
> >
> > (I think that should catch even console writes but I'm not 100% sure of
> > that and it will should get us where the rogue Tx originates from).
>
> I also added the WARN_ON_ONCE check you suggested in
> dw8250_serial_out(). The warning has not triggered, so it seems we
> don't have a rogue Tx firing while in_idle is set.
>
> >
> > > The critical finding was that immediately before the DLAB clear
> > > operation (p->serial_out(p, UART_LCR, up->lcr);), the LSR value
> > > was 0x6a and the USR busy bit [0] was set. This confirms the UART
> > > is busy, which blocks the DLAB modification.
> > >
> > > This is occurring on a device with a single UART console. The setup
> > > does not use DMA or modem control; only the Rx/Tx lines are connected.
> > >
> > > The trace below, from a single process, shows one successful DLAB
> > > clear followed by a failing one. The second attempt repeatedly logs
> > > "USR still busy" before eventually succeeding. This can lead to
> > > subsequent failures in dw8250_check_lcr: dw8250_idle_entered.
> > >
> > > Trace Log:
> > >
> > > <...>-15440 8583.592533: dw8250_idle_enter: in_idle = 1
> > > login-15440 8583.713817: dw8250_idle_enter: in loopback mode
> > > login-15440 8583.835099: dw8250_idle_enter: LSR in loopback mode is 0x63
> > > login-15440 8583.835103: dw8250_set_divisor: UART_LCR_DLAB cleared 13
> > > login-15440 8583.835104: dw8250_idle_exit: idle exit
> > > login-15440 8583.835105: dw8250_idle_exit: out of loopback mode
> > > login-15440 8583.835105: dw8250_idle_exit: in_idle = 0
> > > login-15440 8583.835352: dw8250_idle_enter: in_idle = 1
> > > login-15440 8583.956633: dw8250_idle_enter: in loopback mode
> > > login-15440 8583.956638: dw8250_idle_enter: LSR in loopback mode is 0x6a
> > > login-15440 8583.963918: dw8250_set_divisor: USR still busy dl_write
> > > login-15440 8584.000332: dw8250_set_divisor: USR still busy dl_write
> > > login-15440 8584.040385: dw8250_set_divisor: USR still busy dl_write
> > > login-15440 8584.078012: dw8250_set_divisor: UART_LCR_DLAB cleared 93
> > > login-15440 8584.078013: dw8250_idle_exit: idle exit
> > > login-15440 8584.078014: dw8250_idle_exit: out of loopback mode
> > > login-15440 8584.078015: dw8250_idle_exit: in_idle = 0
> >
> >
> >
> > --
> > From 01df58736a10f7f34aca895ef08e5519953f8572 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
> > Date: Wed, 8 Oct 2025 15:40:19 +0300
> > Subject: [PATCH 1/1] serial: 8250_dw: Ensure BUSY is deasserted
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
> > Existance of BUSY depends on uart_16550_compatible, if UART HW is
> > configured with 16550 compatible those registers can always be
> > written.
> >
> > There currently is dw8250_force_idle() which attempts to archive
> > non-BUSY state by disabling FIFO, however, the solution is unreliable
> > when Rx keeps getting more and more characters.
> >
> > Create a sequence of operations to enforce that ensures UART cannot
> > keep BUSY asserted indefinitely. The new sequence relies on enabling
> > loopback mode temporarily to prevent incoming Rx characters keeping
> > UART BUSY.
> >
> > Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
> > writes.
> >
> > This issue was reported by qianfan Zhao who put lots of debugging
> > effort into understanding the solution space.
> >
> > Reported-by: qianfan Zhao <qianfanguijin@163.com>
> > Reported-by: Adriana Nicolae <adriana@arista.com>
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > ---
> > drivers/tty/serial/8250/8250_dw.c | 159 +++++++++++++++++++++---------
> > 1 file changed, 115 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> > index a53ba04d9770..8e25dfe8e653 100644
> > --- a/drivers/tty/serial/8250/8250_dw.c
> > +++ b/drivers/tty/serial/8250/8250_dw.c
> > @@ -42,6 +42,8 @@
> > /* DesignWare specific register fields */
> > #define DW_UART_MCR_SIRE BIT(6)
> >
> > +#define DW_UART_USR_BUSY BIT(0)
> > +
> > /* Renesas specific register fields */
> > #define RZN1_UART_xDMACR_DMA_EN BIT(0)
> > #define RZN1_UART_xDMACR_1_WORD_BURST (0 << 1)
> > @@ -77,6 +79,7 @@ struct dw8250_data {
> >
> > unsigned int skip_autocfg:1;
> > unsigned int uart_16550_compatible:1;
> > + unsigned int in_idle:1;
> > };
> >
> > static inline struct dw8250_data *to_dw8250_data(struct dw8250_port_data *data)
> > @@ -108,36 +111,103 @@ static inline u32 dw8250_modify_msr(struct uart_port *p, unsigned int offset, u3
> > }
> >
> > /*
> > - * This function is being called as part of the uart_port::serial_out()
> > - * routine. Hence, it must not call serial_port_out() or serial_out()
> > - * against the modified registers here, i.e. LCR.
> > + * Ensure BUSY is not asserted. If DW UART is configured with
> > + * !uart_16550_compatible, the writes to LCR, DLL, and DLH fail while
> > + * BUSY is asserted.
> > + *
> > + * Context: port's lock must be held
> > */
> > -static void dw8250_force_idle(struct uart_port *p)
> > +static int dw8250_idle_enter(struct uart_port *p)
> > {
> > + struct dw8250_data *d = to_dw8250_data(p->private_data);
> > struct uart_8250_port *up = up_to_u8250p(p);
> > - unsigned int lsr;
> > + u32 lsr;
> >
> > - /*
> > - * The following call currently performs serial_out()
> > - * against the FCR register. Because it differs to LCR
> > - * there will be no infinite loop, but if it ever gets
> > - * modified, we might need a new custom version of it
> > - * that avoids infinite recursion.
> > - */
> > - serial8250_clear_and_reinit_fifos(up);
> > + if (d->uart_16550_compatible)
> > + return 0;
> > +
> > + d->in_idle = 1;
> > +
> > + /* Prevent triggering interrupt from RBR filling */
> > + p->serial_out(p, UART_IER, 0);
> > +
> > + serial8250_rx_dma_flush(up);
> > + // What about Tx DMA? Should probably pause that too and resume
> > + // afterwards.
> > +
> > + p->serial_out(p, UART_MCR, up->mcr | UART_MCR_LOOP);
> > + if (up->capabilities & UART_CAP_FIFO)
> > + p->serial_out(p, UART_FCR, 0);
>
> Changing this to repeatedly clear the FIFO turned out to reliably
> clear the BUSY bit , also no kernel panic or device stuck in busy
> mode.
>
> On the device I tested the first clear is not always enough, under
> high load I saw it cleared on the second iteration. I'm thinking it
> might be some particular issue with the device I'm using where the
> first FIFO clear might fail. I never encountered more than 2
> iterations with a "ndelay(p->frame_time);" in between here to get out
> of BUSY state.
Hi,
I seem to have missed this email until now (I'm sorry about that, though
to my defence, IIRC, I was quite sick around that timeframe it was sent
and clear the email backlog isn't ever fun and may end up missing
something).
Do you mean changing this to a simple loop or writing something else than
just 0 to FCR (or perhaps calling serial8250_clear_fifos())?
What is the exact code that you found working?
So when you fixed this FIFO clearing thing, everything seemed to work okay
after that?
In the meantime, this issue has once again been reported to me by somebody
else, and I've done improvements to shutdown code as well to address a
few BUSY related problems (I'll be posting a series that solved that
case soon but I suppose this patch needs amendments based on input from
your case).
--
i.
> > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY)
> > + ndelay(p->frame_time);
> > +
> > + lsr = serial_lsr_in(up);
> > + if (lsr & UART_LSR_DR) {
> > + p->serial_in(p, UART_RX);
> > + up->lsr_saved_flags = 0;
> > + }
> >
> > /*
> > - * With PSLVERR_RESP_EN parameter set to 1, the device generates an
> > - * error response when an attempt to read an empty RBR with FIFO
> > - * enabled.
> > + * BUSY might still be frozen to asserted, try to de-freeze it by
> > + * sending a character over the loopback and receiving it.
> > */
> > - if (up->fcr & UART_FCR_ENABLE_FIFO) {
> > - lsr = serial_port_in(p, UART_LSR);
> > - if (!(lsr & UART_LSR_DR))
> > - return;
> > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
> > + p->serial_out(p, UART_TX, 0);
> > + ndelay(p->frame_time);
> > + lsr = serial_lsr_in(up);
> > + if (lsr & UART_LSR_DR) {
> > + p->serial_in(p, UART_RX);
> > + up->lsr_saved_flags = 0;
> > + }
> > }
> >
> > - serial_port_in(p, UART_RX);
> > + /* Now guaranteed to have BUSY deasserted? Just sanity check */
> > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY)
> > + return -EBUSY;
> > +
> > + return 0;
> > +}
> > +
> > +static void dw8250_idle_exit(struct uart_port *p)
> > +{
> > + struct dw8250_data *d = to_dw8250_data(p->private_data);
> > + struct uart_8250_port *up = up_to_u8250p(p);
> > +
> > + if (d->uart_16550_compatible)
> > + return;
> > +
> > + if (up->capabilities & UART_CAP_FIFO)
> > + p->serial_out(p, UART_FCR, up->fcr);
> > + p->serial_out(p, UART_MCR, up->mcr);
> > + p->serial_out(p, UART_IER, up->ier);
> > +
> > + // Maybe move the DMA Rx restart check in dma_rx_complete() to own
> > + // function (serial8250_rx_dma_restart()) and call it from here.
> > + // DMA Tx resume
> > +
> > + d->in_idle = 0;
> > +}
> > +
> > +static void dw8250_set_divisor(struct uart_port *p, unsigned int baud,
> > + unsigned int quot, unsigned int quot_frac)
> > +{
> > + struct uart_8250_port *up = up_to_u8250p(p);
> > + int ret;
> > +
> > + ret = dw8250_idle_enter(p);
> > + if (ret < 0)
> > + goto idle_failed;
> > +
> > + p->serial_out(p, UART_LCR, up->lcr | UART_LCR_DLAB);
> > + if (!(p->serial_in(p, UART_LCR) & UART_LCR_DLAB))
> > + goto idle_failed;
> > +
> > + serial_dl_write(up, quot);
> > + p->serial_out(p, UART_LCR, up->lcr);
> > +
> > +idle_failed:
> > + dw8250_idle_exit(p);
> > }
> >
> > /*
> > @@ -148,37 +218,37 @@ static void dw8250_force_idle(struct uart_port *p)
> > static void dw8250_check_lcr(struct uart_port *p, unsigned int offset, u32 value)
> > {
> > struct dw8250_data *d = to_dw8250_data(p->private_data);
> > - void __iomem *addr = p->membase + (offset << p->regshift);
> > - int tries = 1000;
> > + u32 lcr = p->serial_in(p, UART_LCR);
> > + int ret;
> >
> > if (offset != UART_LCR || d->uart_16550_compatible)
> > return;
> >
> > /* Make sure LCR write wasn't ignored */
> > - while (tries--) {
> > - u32 lcr = serial_port_in(p, offset);
> > -
> > - if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
> > - return;
> > + if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
> > + return;
> >
> > - dw8250_force_idle(p);
> > + if (d->in_idle) {
> > + /*
> > + * FIXME: this deadlocks if port->lock is already held
> > + * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> > + */
> > + return;
> > + }
> >
> > -#ifdef CONFIG_64BIT
> > - if (p->type == PORT_OCTEON)
> > - __raw_writeq(value & 0xff, addr);
> > - else
> > -#endif
> > - if (p->iotype == UPIO_MEM32)
> > - writel(value, addr);
> > - else if (p->iotype == UPIO_MEM32BE)
> > - iowrite32be(value, addr);
> > - else
> > - writeb(value, addr);
> > + ret = dw8250_idle_enter(p);
> > + if (ret < 0) {
> > + /*
> > + * FIXME: this deadlocks if port->lock is already held
> > + * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> > + */
> > + goto idle_failed;
> > }
> > - /*
> > - * FIXME: this deadlocks if port->lock is already held
> > - * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> > - */
> > +
> > + p->serial_out(p, UART_LCR, value);
> > +
> > +idle_failed:
> > + dw8250_idle_exit(p);
> > }
> >
> > /* Returns once the transmitter is empty or we run out of retries */
> > @@ -547,6 +617,7 @@ static int dw8250_probe(struct platform_device *pdev)
> > p->dev = dev;
> > p->set_ldisc = dw8250_set_ldisc;
> > p->set_termios = dw8250_set_termios;
> > + p->set_divisor = dw8250_set_divisor;
> >
> > data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > if (!data)
> >
> > base-commit: d21b26cad33250be758ea9d860ff9d5c3992c459
> > --
> > 2.39.5
>
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Sebastian Andrzej Siewior @ 2026-01-21 13:57 UTC (permalink / raw)
To: Petr Mladek
Cc: Steven Rostedt, linux-kernel, linux-serial, linux-fbdev,
John Ogness, Sergey Senozhatsky, Greg Kroah-Hartman, Jiri Slaby,
Simona Vetter, Helge Deller
In-Reply-To: <aXDYEVlkFgxdSVSG@pathway.suse.cz>
On 2026-01-21 14:43:45 [+0100], Petr Mladek wrote:
> I know that there was a plan to get rid of cond_resched().
> But what is the status now, please?
It is slowly moving => https://lore.kernel.org/all/20251219101502.GB1132199@noisy.programming.kicks-ass.net/
> I still see more that 1k cond_resched() calls in the code:
>
> $> git grep cond_resched\(\) | grep "\.c:" | wc -l
> 1263
>
> And config PREEMPT_VOLUNTARY still talks about the explicit
> preemption points.
>
> > Should we just remove it and see what breaks?
>
> Honestly, I do not feel comfortable with removing it. It is true that
> it has no effect in the printk() code path. But the vt code is used
> also when working on the terminal.
>
> The vt code still uses console_lock() because it was intertwined
> with printk console code since very old days. console_lock is a kind
> of big kernel lock there.
Do you a have path which loops and would mandate it? I found a few which
do not matter and have their own cond_resched() around. So I don't see a
reason to keep it. And I found one which breaks things so a removal
makes sense.
> Alternative solution is to get rid of the spin_trylock(). The only
> purpose is to prevent race in console_flush_on_panic(). It used
> to be a simple bit operation. The spin_lock() was added just to
> get barriers right. But we have a great atomic_t API these days.
>
> IMHO, it is a win-win solution because a preemptive context is
> always better.
So why do we keep warts again? Just because it *might* be required?
Keeping things preemptible makes sense but this is locking with no
annotation what so ever.
Again. printk has its cond_resched, the tty has it, too.
I'm with Steven on the removal side.
Sebastian
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Petr Mladek @ 2026-01-21 13:43 UTC (permalink / raw)
To: Steven Rostedt
Cc: Sebastian Andrzej Siewior, linux-kernel, linux-serial,
linux-fbdev, John Ogness, Sergey Senozhatsky, Greg Kroah-Hartman,
Jiri Slaby, Simona Vetter, Helge Deller
In-Reply-To: <20260120110845.2922a91a@gandalf.local.home>
On Tue 2026-01-20 11:08:45, Steven Rostedt wrote:
> On Wed, 14 Jan 2026 15:59:55 +0100
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>
> > @@ -3362,22 +3362,6 @@ void console_unlock(void)
> > }
> > EXPORT_SYMBOL(console_unlock);
> >
> > -/**
> > - * console_conditional_schedule - yield the CPU if required
>
> Egad! That goes all the way back to 2002:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=a880f45a48be2956d2c78a839c472287d54435c1
>
> > - *
> > - * If the console code is currently allowed to sleep, and
> > - * if this CPU should yield the CPU to another task, do
> > - * so here.
> > - *
> > - * Must be called within console_lock();.
> > - */
> > -void __sched console_conditional_schedule(void)
> > -{
> > - if (console_may_schedule)
> > - cond_resched();
> > -}
> > -EXPORT_SYMBOL(console_conditional_schedule);
>
> I'm assuming this likely isn't needed anymore. I don't know of any reason
> it needs to stay.
I know that there was a plan to get rid of cond_resched().
But what is the status now, please?
I still see more that 1k cond_resched() calls in the code:
$> git grep cond_resched\(\) | grep "\.c:" | wc -l
1263
And config PREEMPT_VOLUNTARY still talks about the explicit
preemption points.
> Should we just remove it and see what breaks?
Honestly, I do not feel comfortable with removing it. It is true that
it has no effect in the printk() code path. But the vt code is used
also when working on the terminal.
The vt code still uses console_lock() because it was intertwined
with printk console code since very old days. console_lock is a kind
of big kernel lock there.
Alternative solution is to get rid of the spin_trylock(). The only
purpose is to prevent race in console_flush_on_panic(). It used
to be a simple bit operation. The spin_lock() was added just to
get barriers right. But we have a great atomic_t API these days.
IMHO, it is a win-win solution because a preemptive context is
always better.
What about?
From 0fc61b6877e9beb20429effc599bc4bc6ec3a475 Mon Sep 17 00:00:00 2001
From: Petr Mladek <pmladek@suse.com>
Date: Wed, 21 Jan 2026 10:47:15 +0100
Subject: [RFC] tty/vt: Prevent re-entering vt_console_print() in panic()
without spin_lock
The commit b0940003f25dd ("vt: bitlock fix") replaced a simple bit
operation with spin_lock() to get proper memory barriers.
But the code called under this lock calls console_conditional_schedule()
which calls cond_resched() when console_sem() has been acquired
in a preemptive context using console_lock(). Note that the semaphore
can be taken also in an atomic context using console_trylock()
which is used by printk().
One solution would be to remove console_conditional_schedule().
It does not have any effect in the printk() code path anyway.
But the affected VT code is not used just by printk(). And
the cond_resched() calls were likely added for a reason.
Instead, convert the spin_lock back to an atomic operation with
proper barriers. The only purpose of the lock is to prevent
a concurrent access to the guarded code in
console_flush_on_panic() where console_lock() is ignored.
Using a full featured spin_trylock, just to get memory barriers
right, looks like an overkill anyway.
Fixes: b0940003f25dd ("vt: bitlock fix")
Closes: https://lore.kernel.org/all/20260114145955.d924Z-zu@linutronix.de/
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
drivers/tty/vt/vt.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba..5be64d1bba91 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3353,15 +3353,19 @@ static void vt_console_print(struct console *co, const char *b, unsigned count)
{
struct vc_data *vc = vc_cons[fg_console].d;
unsigned char c;
- static DEFINE_SPINLOCK(printing_lock);
+ static atomic_t printing_lock = ATOMIC_INIT(0);
const ushort *start;
ushort start_x, cnt;
int kmsg_console;
WARN_CONSOLE_UNLOCKED();
- /* this protects against concurrent oops only */
- if (!spin_trylock(&printing_lock))
+ /*
+ * Prevent concurrent printing in console_flush_on_panic() where
+ * console_lock is ignored. Easier (serial) console drivers
+ * have bigger chance to get the messages out.
+ */
+ if (atomic_cmpxchg_acquire(&printing_lock, 0, 1) != 0)
return;
kmsg_console = vt_get_kmsg_redirect();
@@ -3422,7 +3426,7 @@ static void vt_console_print(struct console *co, const char *b, unsigned count)
notify_update(vc);
quit:
- spin_unlock(&printing_lock);
+ atomic_set_release(&printing_lock, 0);
}
static struct tty_driver *vt_console_device(struct console *c, int *index)
--
2.52.0
Best Regards,
Petr
^ permalink raw reply related
* Re: [PATCH v5 06/11] dt-bindings: pinctrl: pinctrl-microchip-sgpio: add LAN969x
From: Linus Walleij @ 2026-01-21 12:44 UTC (permalink / raw)
To: Robert Marko
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
kuba, pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver,
olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial, luka.perkov, Conor Dooley
In-Reply-To: <20260115114021.111324-7-robert.marko@sartura.hr>
Hi Robert,
On Thu, Jan 15, 2026 at 12:41 PM Robert Marko <robert.marko@sartura.hr> wrote:
> Document LAN969x compatibles for SGPIO.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Should I just merge this one patch to the pinctrl tree?
Looks good to me.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao (陶志勇) @ 2026-01-21 6:23 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: Project_Global_Digits_Upstream_Group, fred2599@gmail.com,
Yenchia Chen (陳彥嘉),
AngeloGioacchino Del Regno, Vasanth Reddy,
linux-kernel@vger.kernel.org,
Liguo Zhang (张立国), jirislaby@kernel.org,
linux-serial@vger.kernel.org, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2026010643-ladybug-tiring-7f3c@gregkh>
On Tue, 2026-01-06 at 11:02 +0100, Greg KH wrote:
> On Mon, Jan 05, 2026 at 10:39:55AM +0800, Zhiyong Tao wrote:
> > From: "Zhiyong.Tao" <zhiyong.tao@mediatek.com>
> >
> > Add ACPI support to 8250_mtk driver. This makes it possible to
> > use UART on ARM-based desktops with EDK2 UEFI firmware.
> >
> > Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
> > Signed-off-by: Zhiyong.Tao <zhiyong.tao@mediatek.com>
> > ---
> > drivers/tty/serial/8250/8250_mtk.c | 23 +++++++++++++++++++----
> > 1 file changed, 19 insertions(+), 4 deletions(-)
>
> This is a resend of the previous version, right? Or did something
> change?
>
> confused,
>
> greg k-h
==> Hi Greg,
Yes, previously Yenchia Chen helped to send out a version. Currently,
this solution is specifically for the GB10 project and was made to
support Windows ACPI settings.
In actual application scenarios, the apdma clk will not be turned off
in normal mode. It is only turned off in the SSPM microprocessor after
entering standby, and when resuming, the apdma clk is re-enabled by
SSPM.
As for other Linux projects, apdma still uses the DTS node.
Thanks
^ permalink raw reply
* Re: [PATCH v5 10/11] dt-bindings: net: sparx5: do not require phys when RGMII is used
From: Jakub Kicinski @ 2026-01-21 2:38 UTC (permalink / raw)
To: Robert Marko
Cc: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, lee, andrew+netdev, edumazet,
pabeni, Steen.Hegelund, daniel.machon, UNGLinuxDriver, linusw,
olivia, richard.genoud, radu_nicolae.pirea, gregkh,
richardcochran, horatiu.vultur, Ryan.Wanner, tudor.ambarus,
kavyasree.kotagiri, lars.povlsen, devicetree, linux-arm-kernel,
linux-kernel, linux-crypto, netdev, linux-gpio, linux-spi,
linux-serial, luka.perkov
In-Reply-To: <20260115114021.111324-11-robert.marko@sartura.hr>
On Thu, 15 Jan 2026 12:37:35 +0100 Robert Marko wrote:
> LAN969x has 2 dedicated RGMII ports, so regular SERDES lanes are not used
> for RGMII.
>
> So, lets not require phys to be defined when any of the rgmii phy-modes are
> set.
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v5 10/11] dt-bindings: net: sparx5: do not require phys when RGMII is used
From: Rob Herring (Arm) @ 2026-01-21 2:20 UTC (permalink / raw)
To: Robert Marko
Cc: nicolas.ferre, UNGLinuxDriver, gregkh, horatiu.vultur,
andrew+netdev, luka.perkov, lars.povlsen, lee, kuba, linusw,
richardcochran, Steen.Hegelund, richard.genoud,
kavyasree.kotagiri, davem, krzk+dt, linux-spi, daniel.machon,
linux-kernel, edumazet, linux-crypto, conor+dt, linux-gpio,
linux-arm-kernel, pabeni, tudor.ambarus, claudiu.beznea, herbert,
alexandre.belloni, netdev, devicetree, olivia, radu_nicolae.pirea,
linux-serial, Ryan.Wanner
In-Reply-To: <20260115114021.111324-11-robert.marko@sartura.hr>
On Thu, 15 Jan 2026 12:37:35 +0100, Robert Marko wrote:
> LAN969x has 2 dedicated RGMII ports, so regular SERDES lanes are not used
> for RGMII.
>
> So, lets not require phys to be defined when any of the rgmii phy-modes are
> set.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
> ---
> .../bindings/net/microchip,sparx5-switch.yaml | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 3/6] dt-bindings: input: google,goldfish-events-keypad: Convert to DT schema
From: Dmitry Torokhov @ 2026-01-20 19:56 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, sre, gregkh, jirislaby, lgirdwood, broonie,
jserv, eleanor15x, dri-devel, devicetree, linux-kernel,
linux-input, linux-pm, linux-serial, linux-sound
In-Reply-To: <20260113092602.3197681-4-visitorckw@gmail.com>
On Tue, Jan 13, 2026 at 09:25:59AM +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish Events Keypad binding to DT schema format.
> Move the file to the input directory to match the subsystem.
> Update the example node name to 'keypad' to comply with generic node
> naming standards.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
From: Conor Dooley @ 2026-01-20 19:49 UTC (permalink / raw)
To: Biju
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Biju Das,
linux-kernel, linux-serial, devicetree, linux-renesas-soc,
Prabhakar Mahadev Lad
In-Reply-To: <20260120125232.349708-2-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* RE: [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
From: Fabrizio Castro @ 2026-01-20 17:34 UTC (permalink / raw)
To: biju.das.au, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
magnus.damm
Cc: Biju Das, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad,
biju.das.au
In-Reply-To: <20260120125232.349708-2-biju.das.jz@bp.renesas.com>
> From: Biju <biju.das.au@gmail.com>
> Sent: 20 January 2026 12:52
> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Geert
> Uytterhoeven <geert+renesas@glider.be>; magnus.damm <magnus.damm@gmail.com>
> Cc: Biju Das <biju.das.jz@bp.renesas.com>; linux-kernel@vger.kernel.org; linux-serial@vger.kernel.org;
> devicetree@vger.kernel.org; linux-renesas-soc@vger.kernel.org; Prabhakar Mahadev Lad
> <prabhakar.mahadev-lad.rj@bp.renesas.com>; biju.das.au <biju.das.au@gmail.com>
> Subject: [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
>
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add SCIF binding documentation for Renesas RZ/G3L SoC. SCIF block on the
> RZ/G3L is identical to one found on the RZ/G3S SoC.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> index a6ef02327be8..82f54446835e 100644
> --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> @@ -82,6 +82,7 @@ properties:
> - renesas,scif-r9a07g043 # RZ/G2UL and RZ/Five
> - renesas,scif-r9a07g054 # RZ/V2L
> - renesas,scif-r9a08g045 # RZ/G3S
> + - renesas,scif-r9a08g046 # RZ/G3L
> - const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback
>
> - items:
> --
> 2.43.0
>
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Sebastian Andrzej Siewior @ 2026-01-20 17:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-serial, linux-fbdev, Petr Mladek, John Ogness,
Sergey Senozhatsky, Greg Kroah-Hartman, Jiri Slaby, Simona Vetter,
Helge Deller
In-Reply-To: <20260120110845.2922a91a@gandalf.local.home>
On 2026-01-20 11:08:45 [-0500], Steven Rostedt wrote:
>
> I'm assuming this likely isn't needed anymore. I don't know of any reason
> it needs to stay.
>
> Should we just remove it and see what breaks?
I would say so.
> -- Steve
Sebastian
^ permalink raw reply
* Re: printk's threaded legacy console + fbcon => schedule where it should not
From: Steven Rostedt @ 2026-01-20 16:08 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, linux-serial, linux-fbdev, Petr Mladek, John Ogness,
Sergey Senozhatsky, Greg Kroah-Hartman, Jiri Slaby, Simona Vetter,
Helge Deller
In-Reply-To: <20260114145955.d924Z-zu@linutronix.de>
On Wed, 14 Jan 2026 15:59:55 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> @@ -3362,22 +3362,6 @@ void console_unlock(void)
> }
> EXPORT_SYMBOL(console_unlock);
>
> -/**
> - * console_conditional_schedule - yield the CPU if required
Egad! That goes all the way back to 2002:
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=a880f45a48be2956d2c78a839c472287d54435c1
> - *
> - * If the console code is currently allowed to sleep, and
> - * if this CPU should yield the CPU to another task, do
> - * so here.
> - *
> - * Must be called within console_lock();.
> - */
> -void __sched console_conditional_schedule(void)
> -{
> - if (console_may_schedule)
> - cond_resched();
> -}
> -EXPORT_SYMBOL(console_conditional_schedule);
I'm assuming this likely isn't needed anymore. I don't know of any reason
it needs to stay.
Should we just remove it and see what breaks?
-- Steve
> -
> void console_unblank(void)
> {
> bool found_unblank = false;
^ permalink raw reply
* Re: (subset) [PATCH v4 02/15] dt-bindings: mfd: atmel,sama5d2-flexcom: add microchip,lan9691-flexcom
From: Lee Jones @ 2026-01-20 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, herbert, davem, vkoul, andi.shyti, lee,
andrew+netdev, edumazet, kuba, pabeni, linusw, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, olivia, radu_nicolae.pirea,
richard.genoud, gregkh, jirislaby, broonie, lars.povlsen,
devicetree, linux-arm-kernel, linux-kernel, linux-crypto,
dmaengine, linux-i2c, netdev, linux-gpio, linux-spi, linux-serial,
linux-usb, Robert Marko
Cc: luka.perkov, Conor Dooley
In-Reply-To: <20251229184004.571837-3-robert.marko@sartura.hr>
On Mon, 29 Dec 2025 19:37:43 +0100, Robert Marko wrote:
> Add binding documentation for Microchip LAN969x.
>
>
Applied, thanks!
[02/15] dt-bindings: mfd: atmel,sama5d2-flexcom: add microchip,lan9691-flexcom
commit: 41d1f3cf1f52c75f72ce1a3e2f2ee82e7c6eb59a
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH 01/12] dt-bindings: serial: renesas,scif: Document RZ/G3L SoC
From: Biju @ 2026-01-20 12:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-kernel, linux-serial, devicetree,
linux-renesas-soc, Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260120125232.349708-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Add SCIF binding documentation for Renesas RZ/G3L SoC. SCIF block on the
RZ/G3L is identical to one found on the RZ/G3S SoC.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index a6ef02327be8..82f54446835e 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -82,6 +82,7 @@ properties:
- renesas,scif-r9a07g043 # RZ/G2UL and RZ/Five
- renesas,scif-r9a07g054 # RZ/V2L
- renesas,scif-r9a08g045 # RZ/G3S
+ - renesas,scif-r9a08g046 # RZ/G3L
- const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback
- items:
--
2.43.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