* Re: [PATCH] serial: max310x: implement gpio_chip::get_direction()
From: Linus Walleij @ 2026-06-08 22:45 UTC (permalink / raw)
To: Tapio Reijonen
Cc: Greg Kroah-Hartman, Jiri Slaby, Bartosz Golaszewski,
Alexander Shiyan, linux-kernel, linux-serial, linux-gpio
In-Reply-To: <20260602-b4-serial-max310x-gpio-get-direction-v1-1-23bf84e8ee14@vaisala.com>
On Tue, Jun 2, 2026 at 12:02 PM Tapio Reijonen
<tapio.reijonen@vaisala.com> wrote:
> It's strongly recommended for GPIO drivers to always implement the
> .get_direction() callback - even when the direction is tracked in
> software. The GPIO core emits a warning when the callback is missing
> and a user reads the direction of a line, e.g. via
> /sys/kernel/debug/gpio.
>
> The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit
> selects output), which the existing direction_input/output callbacks
> already program, so the current direction can be read back directly.
>
> Fixes: f65444187a66 ("serial: New serial driver MAX310X")
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RESEND v2 2/2] ACPI: SPCR: Support UART clock frequency field
From: Markus Probst @ 2026-06-08 22:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Geert Uytterhoeven,
Thomas Bogendoerfer, Ard Biesheuvel, Ilias Apalodimas,
Greg Kroah-Hartman, Jiri Slaby
Cc: linux-acpi, linux-kernel, linux-m68k, linux-mips, linux-efi,
linux-serial, Markus Probst
In-Reply-To: <20260609-acpi_spcr-v2-0-3cd9a3bda727@posteo.de>
The Microsoft Serial Port Console Redirection (SPCR) specification
revision 1.08 comprises additional field: UART Clock Frequency [1].
It contains a non-zero value indicating the UART clock frequency in Hz.
Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table [1]
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
drivers/acpi/spcr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index cfacbe53f279..16f94073fde6 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -228,7 +228,7 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
pr_info("console: %s\n", opts);
if (enable_earlycon)
- setup_earlycon(opts, 0);
+ setup_earlycon(opts, table->header.revision >= 3 ? table->uart_clk_freq : 0);
if (enable_console)
err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
--
2.53.0
^ permalink raw reply related
* [PATCH RESEND v2 1/2] serial: earlycon: add uart_clk_freq parameter
From: Markus Probst @ 2026-06-08 22:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Geert Uytterhoeven,
Thomas Bogendoerfer, Ard Biesheuvel, Ilias Apalodimas,
Greg Kroah-Hartman, Jiri Slaby
Cc: linux-acpi, linux-kernel, linux-m68k, linux-mips, linux-efi,
linux-serial, Markus Probst
In-Reply-To: <20260609-acpi_spcr-v2-0-3cd9a3bda727@posteo.de>
Add `uart_clk_freq` parameter to `setup_earlycon`. This allows the
options string to be reused with `add_preferred_console`, while still
allowing to set the uart clock frequency. This will be used in the
following commit ("ACPI: SPCR: Support UART clock frequency field").
No logical change intended.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
arch/m68k/virt/config.c | 2 +-
arch/mips/mti-malta/malta-init.c | 2 +-
drivers/acpi/spcr.c | 2 +-
drivers/firmware/efi/earlycon.c | 2 +-
drivers/tty/serial/earlycon.c | 17 ++++++++++++-----
include/linux/serial_core.h | 7 +++++--
6 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/m68k/virt/config.c b/arch/m68k/virt/config.c
index b338e2a8da6a..2c35ec15a51b 100644
--- a/arch/m68k/virt/config.c
+++ b/arch/m68k/virt/config.c
@@ -83,7 +83,7 @@ void __init config_virt(void)
snprintf(earlycon, sizeof(earlycon), "early_gf_tty,0x%08x",
virt_bi_data.tty.mmio);
- setup_earlycon(earlycon);
+ setup_earlycon(earlycon, 0);
mach_init_IRQ = virt_init_IRQ;
mach_sched_init = virt_sched_init;
diff --git a/arch/mips/mti-malta/malta-init.c b/arch/mips/mti-malta/malta-init.c
index 82b0fd8576a2..88ef17967ced 100644
--- a/arch/mips/mti-malta/malta-init.c
+++ b/arch/mips/mti-malta/malta-init.c
@@ -75,7 +75,7 @@ static void __init console_config(void)
if ((strstr(fw_getcmdline(), "earlycon=")) == NULL) {
sprintf(console_string, "uart8250,io,0x3f8,%d%c%c", baud,
parity, bits);
- setup_earlycon(console_string);
+ setup_earlycon(console_string, 0);
}
if ((strstr(fw_getcmdline(), "console=")) == NULL) {
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 73cb933fdc89..cfacbe53f279 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -228,7 +228,7 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
pr_info("console: %s\n", opts);
if (enable_earlycon)
- setup_earlycon(opts);
+ setup_earlycon(opts, 0);
if (enable_console)
err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
diff --git a/drivers/firmware/efi/earlycon.c b/drivers/firmware/efi/earlycon.c
index 3d060d59968c..0e3c2cb08966 100644
--- a/drivers/firmware/efi/earlycon.c
+++ b/drivers/firmware/efi/earlycon.c
@@ -221,7 +221,7 @@ static bool __initdata fb_probed;
void __init efi_earlycon_reprobe(void)
{
if (fb_probed)
- setup_earlycon("efifb");
+ setup_earlycon("efifb", 0);
}
static int __init efi_earlycon_setup(struct earlycon_device *device,
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index ab9af37f6cda..a419943e083b 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -135,11 +135,14 @@ static int __init parse_options(struct earlycon_device *device, char *options)
return 0;
}
-static int __init register_earlycon(char *buf, const struct earlycon_id *match)
+static int __init register_earlycon(char *buf, unsigned int uart_clk_freq,
+ const struct earlycon_id *match)
{
int err;
struct uart_port *port = &early_console_dev.port;
+ port->uartclk = uart_clk_freq;
+
/* On parsing error, pass the options buf to the setup function */
if (buf && !parse_options(&early_console_dev, buf))
buf = NULL;
@@ -164,7 +167,8 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
/**
* setup_earlycon - match and register earlycon console
- * @buf: earlycon param string
+ * @buf: earlycon param string
+ * @uart_clk_freq: uart clock frequency in Hz or 0 for BASE_BAUD*16
*
* Registers the earlycon console matching the earlycon specified
* in the param string @buf. Acceptable param strings are of the form
@@ -177,10 +181,13 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
* <options> string in the 'options' parameter; all other forms set
* the parameter to NULL.
*
+ * If the uart clock frequency is specified in the 'options' parameter,
+ * the value of the param @uart_clk_freq will be ignored.
+ *
* Returns 0 if an attempt to register the earlycon was made,
* otherwise negative error code
*/
-int __init setup_earlycon(char *buf)
+int __init setup_earlycon(char *buf, unsigned int uart_clk_freq)
{
const struct earlycon_id *match;
bool empty_compatible = true;
@@ -209,7 +216,7 @@ int __init setup_earlycon(char *buf)
} else
buf = NULL;
- return register_earlycon(buf, match);
+ return register_earlycon(buf, uart_clk_freq, match);
}
if (empty_compatible) {
@@ -241,7 +248,7 @@ static int __init param_setup_earlycon(char *buf)
}
}
- err = setup_earlycon(buf);
+ err = setup_earlycon(buf, 0);
if (err == -ENOENT || err == -EALREADY)
return 0;
return err;
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 666430b47899..5c60fda9dd3a 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -1097,10 +1097,13 @@ int of_setup_earlycon(const struct earlycon_id *match, unsigned long node,
#ifdef CONFIG_SERIAL_EARLYCON
extern bool earlycon_acpi_spcr_enable __initdata;
-int setup_earlycon(char *buf);
+int setup_earlycon(char *buf, unsigned int uart_clk_freq);
#else
static const bool earlycon_acpi_spcr_enable EARLYCON_USED_OR_UNUSED;
-static inline int setup_earlycon(char *buf) { return 0; }
+static inline int setup_earlycon(char *buf, unsigned int uart_clk_freq)
+{
+ return 0;
+}
#endif
/* Variant of uart_console_registered() when the console_list_lock is held. */
--
2.53.0
^ permalink raw reply related
* [PATCH RESEND v2 0/2] ACPI: SPCR: Support UART clock frequency field
From: Markus Probst @ 2026-06-08 22:40 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Geert Uytterhoeven,
Thomas Bogendoerfer, Ard Biesheuvel, Ilias Apalodimas,
Greg Kroah-Hartman, Jiri Slaby
Cc: linux-acpi, linux-kernel, linux-m68k, linux-mips, linux-efi,
linux-serial, Markus Probst
Support the uart clock frequency in the SPCR table.
See the commit messages for details.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
Changes in v2:
- fix uart_clk_freq possibly being interpreted as parity/bits/flow
- Link to v1: https://patch.msgid.link/20260505-acpi_spcr-v1-1-fd4bc6f4eb53@posteo.de
---
Markus Probst (2):
serial: earlycon: add uart_clk_freq parameter
ACPI: SPCR: Support UART clock frequency field
arch/m68k/virt/config.c | 2 +-
arch/mips/mti-malta/malta-init.c | 2 +-
drivers/acpi/spcr.c | 2 +-
drivers/firmware/efi/earlycon.c | 2 +-
drivers/tty/serial/earlycon.c | 17 ++++++++++++-----
include/linux/serial_core.h | 7 +++++--
6 files changed, 21 insertions(+), 11 deletions(-)
---
base-commit: aa61612ab641d7d62b0b6889f2c7c9251489f6e3
change-id: 20260430-acpi_spcr-61902fd923f2
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEgnQYxPSsWOdyMMRzNHYf+OetQ9IFAmoTfSQbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEDR2H/jnrUPS9e4P/3ObHEJDC0UywwA9xj1z
kzoUrs/iZrus7ROb6ri7MzHVY8riTrzHZrvMOkdWBAxuMXrnzdLwDx96qnQuiaHm
GJBDNBAxoRzBxVkkQJi9Osa+zr8DOEC3+gsv3dCqNqI4DT1wXsBEMi4zgg5dJ5Ye
oFFjEXN/EAiFVa6DHeNMaoJ69sLbYjvWUxAvU74Zpa6zjQMc1n9oCcJFc5D6cvkx
9/WozDV7rTNjmqDy9kcmyb3geeEMd14/y3j8adIe6qB0kkIJQwQr671eIWzGA7pg
353gxRmbLaT9YCKJvHsP32N7Z2EUhrp/o3U6Od/Q0I+qDz13RBSuDLUTogi/mhAw
U7i9a2WHaD2LvwQdt5azLjuo7etx5si84E/cT5G2xJBwUeC2ftYjZulJZs8BMKZp
Oac3Ln/qWCEVw52DWOcxPPIkxlGfjEZOqWBajkRI4NdY3+d0o0/nBK+RYfOt30sf
L3+yLnMmqBjF1RkF1Lm3kTZ589K2KSxGOKMGoYKZqyvV4Ato4w4EoIwL+MQJw7SD
De/BNNpFpTDqJxqgnl4HuELZRzmiKAQCGMwDq285I0Ng1r7xlxFCDYBJnyjnm2Qd
LbD/ZH5yl0beq/S1qZla+JIRjYdbRNQlLUSh3MqBxgll0Xg5GYLk2qeeF+xJJDCq
LkXKR59axau1efToWKWn7CBZ
=EGzU
-----END PGP SIGNATURE-----
--
Markus Probst <markus.probst@posteo.de>
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 17:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Torokhov, linux-arm-kernel, linux-input, linux-serial,
Russell King, Greg Kroah-Hartman, Jiri Slaby, Russell King,
Linus Walleij, Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weißschuh,
Peter Zijlstra
In-Reply-To: <86765df4-0d2d-435e-85d8-b9bd4f3ea85d@app.fastmail.com>
Hi, Arnd,
On Mon, Jun 8, 2026 at 10:11 AM Arnd Bergmann <arnd@arndb.de> wrote:
> I think this is correct, as footbridge is the only one that selects
> CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
I came to the same conclusion.
Ethan
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Arnd Bergmann @ 2026-06-08 17:11 UTC (permalink / raw)
To: Dmitry Torokhov, Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Greg Kroah-Hartman, Jiri Slaby, Russell King, Linus Walleij,
Kees Cook, Nathan Chancellor, Sebastian Andrzej Siewior,
Steven Rostedt, Thomas Weißschuh, Peter Zijlstra
In-Reply-To: <aibz3auoiq4CFa9l@google.com>
On Mon, Jun 8, 2026, at 18:56, Dmitry Torokhov wrote:
> On Sat, May 09, 2026 at 10:20:49PM -0700, Ethan Nelson-Moore wrote:
>> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
>> index a8f4b2d70e59..cea72bd888af 100644
>>
>> -#if defined(__arm__)
>> -/* defined in include/asm-arm/arch-xxx/irqs.h */
>> -#include <asm/irq.h>
>> +#ifdef CONFIG_ARCH_FOOTBRIDGE
>> +/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
>> +#include <mach/irqs.h>
>> #elif defined(CONFIG_PPC)
>> extern int of_i8042_kbd_irq;
>> extern int of_i8042_aux_irq;
>
> This does not look right. Did you mean to drop inclusion of asm/irq.h
> for all other arms?
I think this is correct, as footbridge is the only one that selects
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
Arnd
^ permalink raw reply
* [PATCH] serial: 8250_pnp: Drop unused assignments from pnp_device_id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-08 17:00 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-kernel, linux-serial
Explicitly assigning .driver_data in drivers that don't use this member
is silly and a bit irritating. Drop these. Also simplify the list
terminator entry to be just empty to match what most other device_id
tables do.
There is no changed semantic, not even a change in the compiled result.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/tty/serial/8250/8250_pnp.c | 308 ++++++++++++++---------------
1 file changed, 154 insertions(+), 154 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pnp.c b/drivers/tty/serial/8250/8250_pnp.c
index 7a837fdf9df1..850709bb4a73 100644
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -28,351 +28,351 @@
static const struct pnp_device_id pnp_dev_table[] = {
/* Archtek America Corp. */
/* Archtek SmartLink Modem 3334BT Plug & Play */
- { "AAC000F", 0 },
+ { .id = "AAC000F", .driver_data = 0 },
/* Anchor Datacomm BV */
/* SXPro 144 External Data Fax Modem Plug & Play */
- { "ADC0001", 0 },
+ { .id = "ADC0001", .driver_data = 0 },
/* SXPro 288 External Data Fax Modem Plug & Play */
- { "ADC0002", 0 },
+ { .id = "ADC0002", .driver_data = 0 },
/* PROLiNK 1456VH ISA PnP K56flex Fax Modem */
- { "AEI0250", 0 },
+ { .id = "AEI0250", .driver_data = 0 },
/* Actiontec ISA PNP 56K X2 Fax Modem */
- { "AEI1240", 0 },
+ { .id = "AEI1240", .driver_data = 0 },
/* Rockwell 56K ACF II Fax+Data+Voice Modem */
- { "AKY1021", 0 /*SPCI_FL_NO_SHIRQ*/ },
+ { .id ="AKY1021", .driver_data = 0 /*SPCI_FL_NO_SHIRQ*/ },
/*
* ALi Fast Infrared Controller
* Native driver (ali-ircc) is broken so at least
* it can be used with irtty-sir.
*/
- { "ALI5123", 0 },
+ { .id = "ALI5123", .driver_data = 0 },
/* AZT3005 PnP SOUND DEVICE */
- { "AZT4001", 0 },
+ { .id = "AZT4001", .driver_data = 0 },
/* Best Data Products Inc. Smart One 336F PnP Modem */
- { "BDP3336", 0 },
+ { .id = "BDP3336", .driver_data = 0 },
/* Boca Research */
/* Boca Complete Ofc Communicator 14.4 Data-FAX */
- { "BRI0A49", 0 },
+ { .id = "BRI0A49", .driver_data = 0 },
/* Boca Research 33,600 ACF Modem */
- { "BRI1400", 0 },
+ { .id = "BRI1400", .driver_data = 0 },
/* Boca 33.6 Kbps Internal FD34FSVD */
- { "BRI3400", 0 },
+ { .id = "BRI3400", .driver_data = 0 },
/* Computer Peripherals Inc */
/* EuroViVa CommCenter-33.6 SP PnP */
- { "CPI4050", 0 },
+ { .id = "CPI4050", .driver_data = 0 },
/* Creative Labs */
/* Creative Labs Phone Blaster 28.8 DSVD PnP Voice */
- { "CTL3001", 0 },
+ { .id = "CTL3001", .driver_data = 0 },
/* Creative Labs Modem Blaster 28.8 DSVD PnP Voice */
- { "CTL3011", 0 },
+ { .id = "CTL3011", .driver_data = 0 },
/* Davicom ISA 33.6K Modem */
- { "DAV0336", 0 },
+ { .id = "DAV0336", .driver_data = 0 },
/* Creative */
/* Creative Modem Blaster Flash56 DI5601-1 */
- { "DMB1032", 0 },
+ { .id = "DMB1032", .driver_data = 0 },
/* Creative Modem Blaster V.90 DI5660 */
- { "DMB2001", 0 },
+ { .id = "DMB2001", .driver_data = 0 },
/* E-Tech */
/* E-Tech CyberBULLET PC56RVP */
- { "ETT0002", 0 },
+ { .id = "ETT0002", .driver_data = 0 },
/* FUJITSU */
/* Fujitsu 33600 PnP-I2 R Plug & Play */
- { "FUJ0202", 0 },
+ { .id = "FUJ0202", .driver_data = 0 },
/* Fujitsu FMV-FX431 Plug & Play */
- { "FUJ0205", 0 },
+ { .id = "FUJ0205", .driver_data = 0 },
/* Fujitsu 33600 PnP-I4 R Plug & Play */
- { "FUJ0206", 0 },
+ { .id = "FUJ0206", .driver_data = 0 },
/* Fujitsu Fax Voice 33600 PNP-I5 R Plug & Play */
- { "FUJ0209", 0 },
+ { .id = "FUJ0209", .driver_data = 0 },
/* Archtek America Corp. */
/* Archtek SmartLink Modem 3334BT Plug & Play */
- { "GVC000F", 0 },
+ { .id = "GVC000F", .driver_data = 0 },
/* Archtek SmartLink Modem 3334BRV 33.6K Data Fax Voice */
- { "GVC0303", 0 },
+ { .id = "GVC0303", .driver_data = 0 },
/* Hayes */
/* Hayes Optima 288 V.34-V.FC + FAX + Voice Plug & Play */
- { "HAY0001", 0 },
+ { .id = "HAY0001", .driver_data = 0 },
/* Hayes Optima 336 V.34 + FAX + Voice PnP */
- { "HAY000C", 0 },
+ { .id = "HAY000C", .driver_data = 0 },
/* Hayes Optima 336B V.34 + FAX + Voice PnP */
- { "HAY000D", 0 },
+ { .id = "HAY000D", .driver_data = 0 },
/* Hayes Accura 56K Ext Fax Modem PnP */
- { "HAY5670", 0 },
+ { .id = "HAY5670", .driver_data = 0 },
/* Hayes Accura 56K Ext Fax Modem PnP */
- { "HAY5674", 0 },
+ { .id = "HAY5674", .driver_data = 0 },
/* Hayes Accura 56K Fax Modem PnP */
- { "HAY5675", 0 },
+ { .id = "HAY5675", .driver_data = 0 },
/* Hayes 288, V.34 + FAX */
- { "HAYF000", 0 },
+ { .id = "HAYF000", .driver_data = 0 },
/* Hayes Optima 288 V.34 + FAX + Voice, Plug & Play */
- { "HAYF001", 0 },
+ { .id = "HAYF001", .driver_data = 0 },
/* IBM */
/* IBM Thinkpad 701 Internal Modem Voice */
- { "IBM0033", 0 },
+ { .id = "IBM0033", .driver_data = 0 },
/* Intermec */
/* Intermec CV60 touchscreen port */
- { "PNP4972", 0 },
+ { .id = "PNP4972", .driver_data = 0 },
/* Intertex */
/* Intertex 28k8 33k6 Voice EXT PnP */
- { "IXDC801", 0 },
+ { .id = "IXDC801", .driver_data = 0 },
/* Intertex 33k6 56k Voice EXT PnP */
- { "IXDC901", 0 },
+ { .id = "IXDC901", .driver_data = 0 },
/* Intertex 28k8 33k6 Voice SP EXT PnP */
- { "IXDD801", 0 },
+ { .id = "IXDD801", .driver_data = 0 },
/* Intertex 33k6 56k Voice SP EXT PnP */
- { "IXDD901", 0 },
+ { .id = "IXDD901", .driver_data = 0 },
/* Intertex 28k8 33k6 Voice SP INT PnP */
- { "IXDF401", 0 },
+ { .id = "IXDF401", .driver_data = 0 },
/* Intertex 28k8 33k6 Voice SP EXT PnP */
- { "IXDF801", 0 },
+ { .id = "IXDF801", .driver_data = 0 },
/* Intertex 33k6 56k Voice SP EXT PnP */
- { "IXDF901", 0 },
+ { .id = "IXDF901", .driver_data = 0 },
/* Kortex International */
/* KORTEX 28800 Externe PnP */
- { "KOR4522", 0 },
+ { .id = "KOR4522", .driver_data = 0 },
/* KXPro 33.6 Vocal ASVD PnP */
- { "KORF661", 0 },
+ { .id = "KORF661", .driver_data = 0 },
/* Lasat */
/* LASAT Internet 33600 PnP */
- { "LAS4040", 0 },
+ { .id = "LAS4040", .driver_data = 0 },
/* Lasat Safire 560 PnP */
- { "LAS4540", 0 },
+ { .id = "LAS4540", .driver_data = 0 },
/* Lasat Safire 336 PnP */
- { "LAS5440", 0 },
+ { .id = "LAS5440", .driver_data = 0 },
/* Microcom, Inc. */
/* Microcom TravelPorte FAST V.34 Plug & Play */
- { "MNP0281", 0 },
+ { .id = "MNP0281", .driver_data = 0 },
/* Microcom DeskPorte V.34 FAST or FAST+ Plug & Play */
- { "MNP0336", 0 },
+ { .id = "MNP0336", .driver_data = 0 },
/* Microcom DeskPorte FAST EP 28.8 Plug & Play */
- { "MNP0339", 0 },
+ { .id = "MNP0339", .driver_data = 0 },
/* Microcom DeskPorte 28.8P Plug & Play */
- { "MNP0342", 0 },
+ { .id = "MNP0342", .driver_data = 0 },
/* Microcom DeskPorte FAST ES 28.8 Plug & Play */
- { "MNP0500", 0 },
+ { .id = "MNP0500", .driver_data = 0 },
/* Microcom DeskPorte FAST ES 28.8 Plug & Play */
- { "MNP0501", 0 },
+ { .id = "MNP0501", .driver_data = 0 },
/* Microcom DeskPorte 28.8S Internal Plug & Play */
- { "MNP0502", 0 },
+ { .id = "MNP0502", .driver_data = 0 },
/* Motorola */
/* Motorola BitSURFR Plug & Play */
- { "MOT1105", 0 },
+ { .id = "MOT1105", .driver_data = 0 },
/* Motorola TA210 Plug & Play */
- { "MOT1111", 0 },
+ { .id = "MOT1111", .driver_data = 0 },
/* Motorola HMTA 200 (ISDN) Plug & Play */
- { "MOT1114", 0 },
+ { .id = "MOT1114", .driver_data = 0 },
/* Motorola BitSURFR Plug & Play */
- { "MOT1115", 0 },
+ { .id = "MOT1115", .driver_data = 0 },
/* Motorola Lifestyle 28.8 Internal */
- { "MOT1190", 0 },
+ { .id = "MOT1190", .driver_data = 0 },
/* Motorola V.3400 Plug & Play */
- { "MOT1501", 0 },
+ { .id = "MOT1501", .driver_data = 0 },
/* Motorola Lifestyle 28.8 V.34 Plug & Play */
- { "MOT1502", 0 },
+ { .id = "MOT1502", .driver_data = 0 },
/* Motorola Power 28.8 V.34 Plug & Play */
- { "MOT1505", 0 },
+ { .id = "MOT1505", .driver_data = 0 },
/* Motorola ModemSURFR External 28.8 Plug & Play */
- { "MOT1509", 0 },
+ { .id = "MOT1509", .driver_data = 0 },
/* Motorola Premier 33.6 Desktop Plug & Play */
- { "MOT150A", 0 },
+ { .id = "MOT150A", .driver_data = 0 },
/* Motorola VoiceSURFR 56K External PnP */
- { "MOT150F", 0 },
+ { .id = "MOT150F", .driver_data = 0 },
/* Motorola ModemSURFR 56K External PnP */
- { "MOT1510", 0 },
+ { .id = "MOT1510", .driver_data = 0 },
/* Motorola ModemSURFR 56K Internal PnP */
- { "MOT1550", 0 },
+ { .id = "MOT1550", .driver_data = 0 },
/* Motorola ModemSURFR Internal 28.8 Plug & Play */
- { "MOT1560", 0 },
+ { .id = "MOT1560", .driver_data = 0 },
/* Motorola Premier 33.6 Internal Plug & Play */
- { "MOT1580", 0 },
+ { .id = "MOT1580", .driver_data = 0 },
/* Motorola OnlineSURFR 28.8 Internal Plug & Play */
- { "MOT15B0", 0 },
+ { .id = "MOT15B0", .driver_data = 0 },
/* Motorola VoiceSURFR 56K Internal PnP */
- { "MOT15F0", 0 },
+ { .id = "MOT15F0", .driver_data = 0 },
/* Com 1 */
/* Deskline K56 Phone System PnP */
- { "MVX00A1", 0 },
+ { .id = "MVX00A1", .driver_data = 0 },
/* PC Rider K56 Phone System PnP */
- { "MVX00F2", 0 },
+ { .id = "MVX00F2", .driver_data = 0 },
/* NEC 98NOTE SPEAKER PHONE FAX MODEM(33600bps) */
- { "nEC8241", 0 },
+ { .id = "nEC8241", .driver_data = 0 },
/* Pace 56 Voice Internal Plug & Play Modem */
- { "PMC2430", 0 },
+ { .id = "PMC2430", .driver_data = 0 },
/* Generic */
/* Generic standard PC COM port */
- { "PNP0500", 0 },
+ { .id = "PNP0500", .driver_data = 0 },
/* Generic 16550A-compatible COM port */
- { "PNP0501", 0 },
+ { .id = "PNP0501", .driver_data = 0 },
/* Compaq 14400 Modem */
- { "PNPC000", 0 },
+ { .id = "PNPC000", .driver_data = 0 },
/* Compaq 2400/9600 Modem */
- { "PNPC001", 0 },
+ { .id = "PNPC001", .driver_data = 0 },
/* Dial-Up Networking Serial Cable between 2 PCs */
- { "PNPC031", 0 },
+ { .id = "PNPC031", .driver_data = 0 },
/* Dial-Up Networking Parallel Cable between 2 PCs */
- { "PNPC032", 0 },
+ { .id = "PNPC032", .driver_data = 0 },
/* Standard 9600 bps Modem */
- { "PNPC100", 0 },
+ { .id = "PNPC100", .driver_data = 0 },
/* Standard 14400 bps Modem */
- { "PNPC101", 0 },
+ { .id = "PNPC101", .driver_data = 0 },
/* Standard 28800 bps Modem*/
- { "PNPC102", 0 },
+ { .id = "PNPC102", .driver_data = 0 },
/* Standard Modem*/
- { "PNPC103", 0 },
+ { .id = "PNPC103", .driver_data = 0 },
/* Standard 9600 bps Modem*/
- { "PNPC104", 0 },
+ { .id = "PNPC104", .driver_data = 0 },
/* Standard 14400 bps Modem*/
- { "PNPC105", 0 },
+ { .id = "PNPC105", .driver_data = 0 },
/* Standard 28800 bps Modem*/
- { "PNPC106", 0 },
+ { .id = "PNPC106", .driver_data = 0 },
/* Standard Modem */
- { "PNPC107", 0 },
+ { .id = "PNPC107", .driver_data = 0 },
/* Standard 9600 bps Modem */
- { "PNPC108", 0 },
+ { .id = "PNPC108", .driver_data = 0 },
/* Standard 14400 bps Modem */
- { "PNPC109", 0 },
+ { .id = "PNPC109", .driver_data = 0 },
/* Standard 28800 bps Modem */
- { "PNPC10A", 0 },
+ { .id = "PNPC10A", .driver_data = 0 },
/* Standard Modem */
- { "PNPC10B", 0 },
+ { .id = "PNPC10B", .driver_data = 0 },
/* Standard 9600 bps Modem */
- { "PNPC10C", 0 },
+ { .id = "PNPC10C", .driver_data = 0 },
/* Standard 14400 bps Modem */
- { "PNPC10D", 0 },
+ { .id = "PNPC10D", .driver_data = 0 },
/* Standard 28800 bps Modem */
- { "PNPC10E", 0 },
+ { .id = "PNPC10E", .driver_data = 0 },
/* Standard Modem */
- { "PNPC10F", 0 },
+ { .id = "PNPC10F", .driver_data = 0 },
/* Standard PCMCIA Card Modem */
- { "PNP2000", 0 },
+ { .id = "PNP2000", .driver_data = 0 },
/* Rockwell */
/* Modular Technology */
/* Rockwell 33.6 DPF Internal PnP */
/* Modular Technology 33.6 Internal PnP */
- { "ROK0030", 0 },
+ { .id = "ROK0030", .driver_data = 0 },
/* Kortex International */
/* KORTEX 14400 Externe PnP */
- { "ROK0100", 0 },
+ { .id = "ROK0100", .driver_data = 0 },
/* Rockwell 28.8 */
- { "ROK4120", 0 },
+ { .id = "ROK4120", .driver_data = 0 },
/* Viking Components, Inc */
/* Viking 28.8 INTERNAL Fax+Data+Voice PnP */
- { "ROK4920", 0 },
+ { .id = "ROK4920", .driver_data = 0 },
/* Rockwell */
/* British Telecom */
/* Modular Technology */
/* Rockwell 33.6 DPF External PnP */
/* BT Prologue 33.6 External PnP */
/* Modular Technology 33.6 External PnP */
- { "RSS00A0", 0 },
+ { .id = "RSS00A0", .driver_data = 0 },
/* Viking 56K FAX INT */
- { "RSS0262", 0 },
+ { .id = "RSS0262", .driver_data = 0 },
/* K56 par,VV,Voice,Speakphone,AudioSpan,PnP */
- { "RSS0250", 0 },
+ { .id = "RSS0250", .driver_data = 0 },
/* SupraExpress 28.8 Data/Fax PnP modem */
- { "SUP1310", 0 },
+ { .id = "SUP1310", .driver_data = 0 },
/* SupraExpress 336i PnP Voice Modem */
- { "SUP1381", 0 },
+ { .id = "SUP1381", .driver_data = 0 },
/* SupraExpress 33.6 Data/Fax PnP modem */
- { "SUP1421", 0 },
+ { .id = "SUP1421", .driver_data = 0 },
/* SupraExpress 33.6 Data/Fax PnP modem */
- { "SUP1590", 0 },
+ { .id = "SUP1590", .driver_data = 0 },
/* SupraExpress 336i Sp ASVD */
- { "SUP1620", 0 },
+ { .id = "SUP1620", .driver_data = 0 },
/* SupraExpress 33.6 Data/Fax PnP modem */
- { "SUP1760", 0 },
+ { .id = "SUP1760", .driver_data = 0 },
/* SupraExpress 56i Sp Intl */
- { "SUP2171", 0 },
+ { .id = "SUP2171", .driver_data = 0 },
/* Phoebe Micro */
/* Phoebe Micro 33.6 Data Fax 1433VQH Plug & Play */
- { "TEX0011", 0 },
+ { .id = "TEX0011", .driver_data = 0 },
/* Archtek America Corp. */
/* Archtek SmartLink Modem 3334BT Plug & Play */
- { "UAC000F", 0 },
+ { .id = "UAC000F", .driver_data = 0 },
/* 3Com Corp. */
/* Gateway Telepath IIvi 33.6 */
- { "USR0000", 0 },
+ { .id = "USR0000", .driver_data = 0 },
/* U.S. Robotics Sporster 33.6K Fax INT PnP */
- { "USR0002", 0 },
+ { .id = "USR0002", .driver_data = 0 },
/* Sportster Vi 14.4 PnP FAX Voicemail */
- { "USR0004", 0 },
+ { .id = "USR0004", .driver_data = 0 },
/* U.S. Robotics 33.6K Voice INT PnP */
- { "USR0006", 0 },
+ { .id = "USR0006", .driver_data = 0 },
/* U.S. Robotics 33.6K Voice EXT PnP */
- { "USR0007", 0 },
+ { .id = "USR0007", .driver_data = 0 },
/* U.S. Robotics Courier V.Everything INT PnP */
- { "USR0009", 0 },
+ { .id = "USR0009", .driver_data = 0 },
/* U.S. Robotics 33.6K Voice INT PnP */
- { "USR2002", 0 },
+ { .id = "USR2002", .driver_data = 0 },
/* U.S. Robotics 56K Voice INT PnP */
- { "USR2070", 0 },
+ { .id = "USR2070", .driver_data = 0 },
/* U.S. Robotics 56K Voice EXT PnP */
- { "USR2080", 0 },
+ { .id = "USR2080", .driver_data = 0 },
/* U.S. Robotics 56K FAX INT */
- { "USR3031", 0 },
+ { .id = "USR3031", .driver_data = 0 },
/* U.S. Robotics 56K FAX INT */
- { "USR3050", 0 },
+ { .id = "USR3050", .driver_data = 0 },
/* U.S. Robotics 56K Voice INT PnP */
- { "USR3070", 0 },
+ { .id = "USR3070", .driver_data = 0 },
/* U.S. Robotics 56K Voice EXT PnP */
- { "USR3080", 0 },
+ { .id = "USR3080", .driver_data = 0 },
/* U.S. Robotics 56K Voice INT PnP */
- { "USR3090", 0 },
+ { .id = "USR3090", .driver_data = 0 },
/* U.S. Robotics 56K Message */
- { "USR9100", 0 },
+ { .id = "USR9100", .driver_data = 0 },
/* U.S. Robotics 56K FAX EXT PnP*/
- { "USR9160", 0 },
+ { .id = "USR9160", .driver_data = 0 },
/* U.S. Robotics 56K FAX INT PnP*/
- { "USR9170", 0 },
+ { .id = "USR9170", .driver_data = 0 },
/* U.S. Robotics 56K Voice EXT PnP*/
- { "USR9180", 0 },
+ { .id = "USR9180", .driver_data = 0 },
/* U.S. Robotics 56K Voice INT PnP*/
- { "USR9190", 0 },
+ { .id = "USR9190", .driver_data = 0 },
/* Wacom tablets */
- { "WACFXXX", 0 },
+ { .id = "WACFXXX", .driver_data = 0 },
/* Compaq touchscreen */
- { "FPI2002", 0 },
+ { .id = "FPI2002", .driver_data = 0 },
/* Fujitsu Stylistic touchscreens */
- { "FUJ02B2", 0 },
- { "FUJ02B3", 0 },
+ { .id = "FUJ02B2", .driver_data = 0 },
+ { .id = "FUJ02B3", .driver_data = 0 },
/* Fujitsu Stylistic LT touchscreens */
- { "FUJ02B4", 0 },
+ { .id = "FUJ02B4", .driver_data = 0 },
/* Passive Fujitsu Stylistic touchscreens */
- { "FUJ02B6", 0 },
- { "FUJ02B7", 0 },
- { "FUJ02B8", 0 },
- { "FUJ02B9", 0 },
- { "FUJ02BC", 0 },
+ { .id = "FUJ02B6", .driver_data = 0 },
+ { .id = "FUJ02B7", .driver_data = 0 },
+ { .id = "FUJ02B8", .driver_data = 0 },
+ { .id = "FUJ02B9", .driver_data = 0 },
+ { .id = "FUJ02BC", .driver_data = 0 },
/* Fujitsu Wacom Tablet PC device */
- { "FUJ02E5", 0 },
+ { .id = "FUJ02E5", .driver_data = 0 },
/* Fujitsu P-series tablet PC device */
- { "FUJ02E6", 0 },
+ { .id = "FUJ02E6", .driver_data = 0 },
/* Fujitsu Wacom 2FGT Tablet PC device */
- { "FUJ02E7", 0 },
+ { .id = "FUJ02E7", .driver_data = 0 },
/* Fujitsu Wacom 1FGT Tablet PC device */
- { "FUJ02E9", 0 },
+ { .id = "FUJ02E9", .driver_data = 0 },
/*
* LG C1 EXPRESS DUAL (C1-PB11A3) touch screen (actually a FUJ02E6
* in disguise).
*/
- { "LTS0001", 0 },
+ { .id = "LTS0001", .driver_data = 0 },
/* Rockwell's (PORALiNK) 33600 INT PNP */
- { "WCI0003", 0 },
+ { .id = "WCI0003", .driver_data = 0 },
/* Unknown PnP modems */
- { "PNPCXXX", UNKNOWN_DEV },
+ { .id = "PNPCXXX", .driver_data = UNKNOWN_DEV },
/* More unknown PnP modems */
- { "PNPDXXX", UNKNOWN_DEV },
+ { .id = "PNPDXXX", .driver_data = UNKNOWN_DEV },
/*
* Winbond CIR port, should not be probed. We should keep track of
* it to prevent the legacy serial driver from probing it.
*/
- { "WEC1022", CIR_PORT },
+ { .id = "WEC1022", .driver_data = CIR_PORT },
/*
* SMSC IrCC SIR/FIR port, should not be probed by serial driver as
* well so its own driver can bind to it.
*/
- { "SMCF010", CIR_PORT },
- { "", 0 }
+ { .id = "SMCF010", .driver_data = CIR_PORT },
+ { }
};
MODULE_DEVICE_TABLE(pnp, pnp_dev_table);
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Dmitry Torokhov @ 2026-06-08 16:56 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Jiri Slaby,
Russell King (Oracle), Linus Walleij, Kees Cook,
Nathan Chancellor, Sebastian Andrzej Siewior, Steven Rostedt,
Thomas Weissschuh, Peter Zijlstra
In-Reply-To: <20260510052107.555825-1-enelsonmoore@gmail.com>
Hi Ethan,
On Sat, May 09, 2026 at 10:20:49PM -0700, Ethan Nelson-Moore wrote:
> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
> index a8f4b2d70e59..cea72bd888af 100644
> --- a/drivers/input/serio/i8042-io.h
> +++ b/drivers/input/serio/i8042-io.h
> @@ -15,9 +15,9 @@
> * IRQs.
> */
>
> -#if defined(__arm__)
> -/* defined in include/asm-arm/arch-xxx/irqs.h */
> -#include <asm/irq.h>
> +#ifdef CONFIG_ARCH_FOOTBRIDGE
> +/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
> +#include <mach/irqs.h>
> #elif defined(CONFIG_PPC)
> extern int of_i8042_kbd_irq;
> extern int of_i8042_aux_irq;
This does not look right. Did you mean to drop inclusion of asm/irq.h
for all other arms?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] tty: serial: core: fix NULL pointer deref in uart_resume_port()
From: Weiming Shi @ 2026-06-08 16:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-kernel, linux-serial, Xiang Mei
uart_resume_port() looks up the tty device child with device_find_child()
and passes the result straight to device_may_wakeup(). device_find_child()
returns NULL when the port has no matching tty device child, and
device_may_wakeup() dereferences dev->power.can_wakeup, so a NULL tty_dev
faults. uart_suspend_port() already guards the same call with
"tty_dev && device_may_wakeup(tty_dev)"; the resume path does not.
Oops: general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x148-0x14f]
RIP: 0010:uart_resume_port (pm_wakeup.h:84 serial_core.c:2477)
serial_pnp_resume (8250/8250_pnp.c:522)
pnp_bus_resume (drivers/pnp/driver.c:234)
Mirror the NULL guard from uart_suspend_port(). put_device(tty_dev)
already tolerates a NULL argument, so only the device_may_wakeup() call
needs the check; the non-NULL path is unchanged.
Fixes: b3b708fa2780 ("wake up from a serial port")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
drivers/tty/serial/serial_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 89cebdd278410..7dd3ec3dea438 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2373,7 +2373,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
guard(mutex)(&port->mutex);
tty_dev = device_find_child(&uport->port_dev->dev, &match, serial_match_port);
- if (!uport->suspended && device_may_wakeup(tty_dev)) {
+ if (!uport->suspended && tty_dev && device_may_wakeup(tty_dev)) {
if (irqd_is_wakeup_set(irq_get_irq_data((uport->irq))))
disable_irq_wake(uport->irq);
put_device(tty_dev);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 16:40 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <CAD++jLmUW4KjxEjwv7_an_dEMTSOtvG=q2MjhqKvnuGrWaaCsQ@mail.gmail.com>
Hi, Linus,
On Mon, Jun 8, 2026 at 1:50 AM Linus Walleij <linusw@kernel.org> wrote:
> Have you tested this on real hardware?
> The commit doesn't really say.
No, I haven't. I can try to test it in GXemul, but I'm not sure if it
can boot Linux. The developer only lists it as capable of booting
NetBSD.
Ethan
^ permalink raw reply
* Re: [PATCH v5] serial: 8250_omap: clear rx_running on zero-length DMA completes
From: andriy.shevchenko @ 2026-06-08 11:35 UTC (permalink / raw)
To: Matthias Feser
Cc: Moteen Shah, linux-serial@vger.kernel.org,
gregkh@linuxfoundation.org, jirislaby@kernel.org,
linux-kernel@vger.kernel.org, k-willis@ti.com, msp@baylibre.com
In-Reply-To: <BE3P281MB5515D220F1679A21D35D9619EE1C2@BE3P281MB5515.DEUP281.PROD.OUTLOOK.COM>
On Mon, Jun 08, 2026 at 11:00:44AM +0000, Matthias Feser wrote:
> On Tue, Jun 02, 2026, Andy Shevchenko wrote:
> > I'm wondering if this opens a window when dma->rx_buf may be
> > rewritten (or unmapped or something else) before tty layer has
> > a chance to insert bytes to its ring buffer. I.o.w. is this
> > change synchronous to other threads?
>
> Good point.
>
> RX DMA can be started from the DMA callback, the IRQ path, and
> runtime resume. These paths appear to be protected by the same
> driver locking.
>
> At the point where rx_running is cleared, DMA has already been
> terminated.
>
> So I don't see a window where rx_buf could be overwritten, but
> please let me know if there is a path where this could happen.
I don't see either, that's why I was wondering. Btw, does AI notice
anything of a such? I haven't checked Sashiko myself, others may
have also run some other AI tools for that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5] serial: 8250_omap: clear rx_running on zero-length DMA completes
From: Matthias Feser @ 2026-06-08 11:00 UTC (permalink / raw)
To: andriy.shevchenko@linux.intel.com
Cc: Moteen Shah, linux-serial@vger.kernel.org,
gregkh@linuxfoundation.org, jirislaby@kernel.org,
linux-kernel@vger.kernel.org, k-willis@ti.com, msp@baylibre.com
In-Reply-To: <ah8i-aGuHTKcRpaA@ashevche-desk.local>
On Tue, Jun 02, 2026, Andy Shevchenko wrote:
> I'm wondering if this opens a window when dma->rx_buf may be
> rewritten (or unmapped or something else) before tty layer has
> a chance to insert bytes to its ring buffer. I.o.w. is this
> change synchronous to other threads?
Good point.
RX DMA can be started from the DMA callback, the IRQ path, and
runtime resume. These paths appear to be protected by the same
driver locking.
At the point where rx_running is cleared, DMA has already been
terminated.
So I don't see a window where rx_buf could be overwritten, but
please let me know if there is a path where this could happen.
^ permalink raw reply
* [PATCH next] drivers/tty/serial/kgdboc: Use strscpy() to copy strings into arrays
From: david.laight.linux @ 2026-06-08 9:54 UTC (permalink / raw)
To: Kees Cook, linux-hardening, kgdb-bugreport, linux-kernel,
linux-serial
Cc: Arnd Bergmann, Daniel Thompson, Greg Kroah-Hartman, Jason Wessel,
Jiri Slaby, David Laight
From: David Laight <david.laight.linux@gmail.com>
Replacing strcpy() with strscpy() ensures that overflow of the target
buffer cannot happen.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
drivers/tty/serial/kgdboc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
index 5a955c80a853..09648d643897 100644
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -363,7 +363,7 @@ static int param_set_kgdboc_var(const char *kmessage,
mutex_lock(&config_mutex);
- strcpy(config, kmessage);
+ strscpy(config, kmessage);
/* Chop out \n char as a result of echo */
if (len && config[len - 1] == '\n')
config[len - 1] = '\0';
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Linus Walleij @ 2026-06-08 8:49 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <20260510052107.555825-1-enelsonmoore@gmail.com>
On Sun, May 10, 2026 at 7:21 AM Ethan Nelson-Moore
<enelsonmoore@gmail.com> wrote:
> To improve future maintainability, change the interrupt handling for
> mach-footbridge to use sparse IRQs.
>
> Since the number of possible interrupts is already fixed and relatively
> small, just make it use all legacy interrupts preallocated using the
> .nr_irqs field in the machine descriptor, rather than actually
> allocating domains on the fly.
>
> Many files had to be adjusted to include <mach/irqs.h>
> explicitly because it is no longer implicitly included with sparse
> IRQs.
>
> Description adapted from commit c78a41fc04f0 ("ARM: s3c24xx: convert
> to sparse-irq").
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Have you tested this on real hardware?
The commit doesn't really say.
I might have to dig out my NetWinder to test this.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] tty: n_gsm: bound the EA scan in gsm_control_rls()
From: Greg Kroah-Hartman @ 2026-06-07 14:57 UTC (permalink / raw)
To: Michael Bommarito; +Cc: Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <CAJJ9bXw46vThuvzE-x73unRDm8n2ibq8+KF0+YO3gtipf1PNkQ@mail.gmail.com>
On Sun, Jun 07, 2026 at 07:09:06AM -0400, Michael Bommarito wrote:
> On Sun, Jun 7, 2026 at 2:38 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > While it's fun to throw LLMs at this codebase, how was this actually
> > tested? there are loads of documented "problems" with this file, but in
> > the real world, with real devices, it works fine so without testing of
> > the code with those devices, we have to be careful with changing
> > anything here.
>
> Understood. A few different notes for you to consider on this one:
>
> 1. This is almost certainly the continuation / completion of
> 669609cea1d29, where two other sites were similarly addressed. I
> think Daniel could answer if there was a reason why he didn't include
> this spot, but there's no evidence in the commit log or code comments
> otherwise.
It was perhaps missed, or not actually needed? Again, how was this
tested?
> 2. The backport situation on 67c37756898a5 (the CAP_NET_ADMIN gate)
> looks complicated because it wasn't originally stable tagged and
> didn't get actioned by vendors for awhile, so I think reachability for
> unprivileged chaining in attacks is still high.
Distros/vendors know all about this line dicipline and they enable it at
their own risk. There should not be any that has it enabled for normal
users, and I would not enabling it at all except for systems that
actually has this hardware.
> 3. I'm normally running tests on UML or qemu for every patch I submit.
> Sometimes, the AI assistance tag is more about the testing side of the
> patch than anything else.
That's fine, but where is the test?
> For example, for this patch, here's what Claude logged for the
> regression testing:
>
> <CLAUDE>
> repro/loopback.c stands up two real N_GSM0710 line disciplines in
> one UML kernel, wired back to back through a userspace byte relay — so
> the kernel runs both the
> initiator and responder TS 27.010 state machines (not a
> userspace-faked peer like trigger.c). Phases:
>
> - A — DLCI0 + DLCI1 SABM/UA handshake (kernel both ends)
> - B — bidirectional gsmtty data, byte-exact (PING/PONG)
> - C — drop/raise DTR/RTS → real MSC frames → peer modem lines track
> them (before=0x0 low=0x40 high=0x166)
> - D — inject a valid CMD_RLS (clen=2) on DLCI0 → accepted by the
> patched gsm_control_rls, mux keeps carrying data
> - E — clean teardown
> </CLAUDE>
Adding tests like this to the tree would be great.
> 4. Relatedly, I think it would be helpful for someone (Willy again?)
> to improve the guidance for AI assisted testing and establish some
> standards for documentation.
Why not submit it yourself?
> Because most of the kernel doesn't have
> established KUnit setups and dumping all this info is frowned upon in
> commit logs or notes, it seems like there is a tension between
> "showing your work" and sticking to general convention.
Add the test! We'll gladly take them, that would make it even easier to
prove changes work, AND prevent regressions in the future.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] tty: n_gsm: bound the EA scan in gsm_control_rls()
From: Michael Bommarito @ 2026-06-07 11:09 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <2026060715-quarterly-dexterity-982c@gregkh>
On Sun, Jun 7, 2026 at 2:38 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> While it's fun to throw LLMs at this codebase, how was this actually
> tested? there are loads of documented "problems" with this file, but in
> the real world, with real devices, it works fine so without testing of
> the code with those devices, we have to be careful with changing
> anything here.
Understood. A few different notes for you to consider on this one:
1. This is almost certainly the continuation / completion of
669609cea1d29, where two other sites were similarly addressed. I
think Daniel could answer if there was a reason why he didn't include
this spot, but there's no evidence in the commit log or code comments
otherwise.
2. The backport situation on 67c37756898a5 (the CAP_NET_ADMIN gate)
looks complicated because it wasn't originally stable tagged and
didn't get actioned by vendors for awhile, so I think reachability for
unprivileged chaining in attacks is still high.
3. I'm normally running tests on UML or qemu for every patch I submit.
Sometimes, the AI assistance tag is more about the testing side of the
patch than anything else.
For example, for this patch, here's what Claude logged for the
regression testing:
<CLAUDE>
repro/loopback.c stands up two real N_GSM0710 line disciplines in
one UML kernel, wired back to back through a userspace byte relay — so
the kernel runs both the
initiator and responder TS 27.010 state machines (not a
userspace-faked peer like trigger.c). Phases:
- A — DLCI0 + DLCI1 SABM/UA handshake (kernel both ends)
- B — bidirectional gsmtty data, byte-exact (PING/PONG)
- C — drop/raise DTR/RTS → real MSC frames → peer modem lines track
them (before=0x0 low=0x40 high=0x166)
- D — inject a valid CMD_RLS (clen=2) on DLCI0 → accepted by the
patched gsm_control_rls, mux keeps carrying data
- E — clean teardown
</CLAUDE>
4. Relatedly, I think it would be helpful for someone (Willy again?)
to improve the guidance for AI assisted testing and establish some
standards for documentation. Because most of the kernel doesn't have
established KUnit setups and dumping all this info is frowned upon in
commit logs or notes, it seems like there is a tension between
"showing your work" and sticking to general convention.
P.S. I know it's somewhat contentious, but maybe one of the best use
cases for AI would be helping maintainers add or improve KUnit or
out-of-kernel test frameworks. I have dozens of orphaned tests or
harnesses across the kernel now and would be happy to contribute them
or use my tokens for the cause.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
From: Krzysztof Kozlowski @ 2026-06-07 8:41 UTC (permalink / raw)
To: Tapio Reijonen
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hugo Villeneuve, linux-kernel, linux-serial,
devicetree
In-Reply-To: <20260601-b4-max310x-rs485-dt-v2-2-a105105f8e70@vaisala.com>
On Mon, Jun 01, 2026 at 10:25:32AM +0000, Tapio Reijonen wrote:
> The MAX310x is a family of one- (max3107, max3108), two- (max3109) and
> four-channel (max14830) UARTs. The binding pulls in
> /schemas/serial/rs485.yaml at the chip level, describing a single set of
> RS-485 properties - enough for the single-channel parts, but a
> multi-channel chip can wire RS-485 differently on each channel.
>
> Describe each channel as a "serial@N" subnode. Being a serial node (per
> serial.yaml) the channel carries the standard rs485.yaml properties and
> may also host a serial slave device. Constrain the channels per
> compatible: max3107 and max3108 have none and keep RS-485 on the chip
> node, max3109 has channels 0-1, and max14830 has 0-3. Chip-level rs485
> properties remain accepted and are the only form for the single-channel
> parts.
>
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
> ---
> .../devicetree/bindings/serial/maxim,max310x.yaml | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.yaml b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
> index 889eeaca64a027b4d9e8ec87bcf63fcc8fd9d55b..988864e7957416caea2d86c38957a894ce57c6fb 100644
> --- a/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
> +++ b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
> @@ -40,6 +40,36 @@ properties:
> minItems: 1
> maxItems: 16
>
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> +patternProperties:
> + "^serial@[0-3]$":
> + type: object
> + description:
> + A single UART channel of a multi-channel variant. Describe the
> + channel's RS-485 wiring here with the standard properties from
> + /schemas/serial/rs485.yaml#; being a serial node, the channel may
> + also host a serial slave device. Single-channel variants have no
> + such subnode - their settings stay on the chip node.
> +
> + allOf:
> + - $ref: /schemas/serial/serial.yaml#
> + - $ref: /schemas/serial/rs485.yaml#
So now both top-level node is serial and its children are. I don't think
that's correct. This binding should be split for two cases - single
channel and multi-channel, while multi-channels will require subnodes
(in the binding, keep driver backwards compatible).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] tty: n_gsm: bound the EA scan in gsm_control_rls()
From: Greg Kroah-Hartman @ 2026-06-07 6:37 UTC (permalink / raw)
To: Michael Bommarito; +Cc: Jiri Slaby, linux-serial, linux-kernel
In-Reply-To: <20260606170323.1522340-1-michael.bommarito@gmail.com>
On Sat, Jun 06, 2026 at 01:03:23PM -0400, Michael Bommarito wrote:
> gsm_control_rls() walks the control message looking for the end of the
> EA-encoded address, but it dereferences each byte before checking the
> remaining length:
>
> int len = clen;
> const u8 *dp = data;
>
> while (gsm_read_ea(&addr, *dp++) == 0) {
> len--;
> if (len == 0)
> return;
> }
>
> When a malformed RLS control message decodes to a control length of
> zero, len starts at 0, the loop reads *dp before testing len, len
> underflows to -1, and the "if (len == 0)" test never fires. The scan
> then keeps reading forward through gsm->buf (kmalloc(MAX_MRU + 1)) until
> it happens upon a byte whose EA bit is set, reading past the end of the
> allocation.
>
> A two byte DLCI 0 UIH control frame carrying CMD_RLS with an encoded
> length of zero reaches this from the receive path. KASAN reports a
> slab-out-of-bounds read in gsm_control_rls() (inlined into
> gsm_dlci_command()) when the bytes that follow the message in gsm->buf
> do not terminate the scan before the end of the buffer.
>
> The sibling control handlers gsm_control_modem() and gsm_dlci_data()
> already reject a too short message before walking it; gsm_control_rls()
> was missed. Bound the EA scan by the remaining length so a zero length
> message returns without dereferencing past the data.
>
> Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> drivers/tty/n_gsm.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index c13e050de83b1..4f8f2ce038bc8 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -1806,12 +1806,12 @@ static void gsm_control_rls(struct gsm_mux *gsm, const u8 *data, int clen)
> int len = clen;
> const u8 *dp = data;
>
> - while (gsm_read_ea(&addr, *dp++) == 0) {
> + while (len > 0) {
> + if (gsm_read_ea(&addr, *dp++))
> + break;
> len--;
> - if (len == 0)
> - return;
> }
> - /* Must be at least one byte following ea */
> + /* Must be at least one byte following the EA */
> len--;
> if (len <= 0)
> return;
>
> base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
While it's fun to throw LLMs at this codebase, how was this actually
tested? there are loads of documented "problems" with this file, but in
the real world, with real devices, it works fine so without testing of
the code with those devices, we have to be careful with changing
anything here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] serial: cpm_uart: replace irq_of_parse_and_map with platform_get_irq
From: Rosen Penev @ 2026-06-07 2:11 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby,
open list:TTY LAYER AND SERIAL DRIVERS
platform_get_irq is a newer API for this that does not require
irq_dispose_mapping().
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/cpm_uart.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/cpm_uart.c b/drivers/tty/serial/cpm_uart.c
index b778a20ec9b1..39f54bb7b485 100644
--- a/drivers/tty/serial/cpm_uart.c
+++ b/drivers/tty/serial/cpm_uart.c
@@ -27,7 +27,6 @@
#include <linux/memblock.h>
#include <linux/dma-mapping.h>
#include <linux/of_address.h>
-#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/gpio/consumer.h>
#include <linux/clk.h>
@@ -1530,16 +1529,14 @@ static int cpm_uart_probe(struct platform_device *ofdev)
/* initialize the device pointer for the port */
pinfo->port.dev = &ofdev->dev;
- pinfo->port.irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
- if (!pinfo->port.irq)
- return -EINVAL;
+ pinfo->port.irq = platform_get_irq(ofdev, 0);
+ if (pinfo->port.irq < 0)
+ return pinfo->port.irq;
ret = cpm_uart_init_port(ofdev->dev.of_node, pinfo);
if (!ret)
return uart_add_one_port(&cpm_reg, &pinfo->port);
- irq_dispose_mapping(pinfo->port.irq);
-
return ret;
}
--
2.54.0
^ permalink raw reply related
* [PATCH] tty: n_gsm: bound the EA scan in gsm_control_rls()
From: Michael Bommarito @ 2026-06-06 17:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby; +Cc: linux-serial, linux-kernel
gsm_control_rls() walks the control message looking for the end of the
EA-encoded address, but it dereferences each byte before checking the
remaining length:
int len = clen;
const u8 *dp = data;
while (gsm_read_ea(&addr, *dp++) == 0) {
len--;
if (len == 0)
return;
}
When a malformed RLS control message decodes to a control length of
zero, len starts at 0, the loop reads *dp before testing len, len
underflows to -1, and the "if (len == 0)" test never fires. The scan
then keeps reading forward through gsm->buf (kmalloc(MAX_MRU + 1)) until
it happens upon a byte whose EA bit is set, reading past the end of the
allocation.
A two byte DLCI 0 UIH control frame carrying CMD_RLS with an encoded
length of zero reaches this from the receive path. KASAN reports a
slab-out-of-bounds read in gsm_control_rls() (inlined into
gsm_dlci_command()) when the bytes that follow the message in gsm->buf
do not terminate the scan before the end of the buffer.
The sibling control handlers gsm_control_modem() and gsm_dlci_data()
already reject a too short message before walking it; gsm_control_rls()
was missed. Bound the EA scan by the remaining length so a zero length
message returns without dereferencing past the data.
Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
drivers/tty/n_gsm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c13e050de83b1..4f8f2ce038bc8 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1806,12 +1806,12 @@ static void gsm_control_rls(struct gsm_mux *gsm, const u8 *data, int clen)
int len = clen;
const u8 *dp = data;
- while (gsm_read_ea(&addr, *dp++) == 0) {
+ while (len > 0) {
+ if (gsm_read_ea(&addr, *dp++))
+ break;
len--;
- if (len == 0)
- return;
}
- /* Must be at least one byte following ea */
+ /* Must be at least one byte following the EA */
len--;
if (len <= 0)
return;
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write
From: Jiri Slaby @ 2026-06-04 6:54 UTC (permalink / raw)
To: Yi Yang, gregkh, kees, linux, george.kennedy
Cc: linux-kernel, linux-serial, lujialin4
In-Reply-To: <20260604060734.2914976-1-yiyang13@huawei.com>
On 04. 06. 26, 8:07, Yi Yang wrote:
> A KASAN null-ptr-deref was observed in vcs_notifier():
>
> BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130
> Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {}
>
> The issue is a race condition in vcs_write(). When the console_lock is
> temporarily dropped (to copy data from userspace), the vc_data pointer
> obtained from vcs_vc() may become stale. After re-acquiring the lock,
> vcs_vc() is called again to re-validate the pointer. If the vc has been
> deallocated in the meantime, vcs_vc() returns NULL, and the while loop
> breaks (with written > 0). However, after the loop, vcs_scr_updated(vc)
> is still called with the now-NULL vc pointer, leading to a null pointer
> dereference in the notifier chain (vcs_notifier dereferences param->vc).
>
> Fix this by adding a NULL check for vc before calling vcs_scr_updated().
And vc is still protected by console_lock at that point.
> Fixes: 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yi Yang <yiyang13@huawei.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
> ---
> drivers/tty/vt/vc_screen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
> index 4d2d46c95fef..7d40eacc21b3 100644
> --- a/drivers/tty/vt/vc_screen.c
> +++ b/drivers/tty/vt/vc_screen.c
> @@ -686,7 +686,7 @@ vcs_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
> }
> *ppos += written;
> ret = written;
> - if (written)
> + if (written && vc)
> vcs_scr_updated(vc);
>
> return ret;
--
js
suse labs
^ permalink raw reply
* [PATCH] vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write
From: Yi Yang @ 2026-06-04 6:07 UTC (permalink / raw)
To: gregkh, jirislaby, kees, linux, george.kennedy
Cc: linux-kernel, linux-serial, lujialin4, yiyang13
A KASAN null-ptr-deref was observed in vcs_notifier():
BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130
Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {}
The issue is a race condition in vcs_write(). When the console_lock is
temporarily dropped (to copy data from userspace), the vc_data pointer
obtained from vcs_vc() may become stale. After re-acquiring the lock,
vcs_vc() is called again to re-validate the pointer. If the vc has been
deallocated in the meantime, vcs_vc() returns NULL, and the while loop
breaks (with written > 0). However, after the loop, vcs_scr_updated(vc)
is still called with the now-NULL vc pointer, leading to a null pointer
dereference in the notifier chain (vcs_notifier dereferences param->vc).
Fix this by adding a NULL check for vc before calling vcs_scr_updated().
Fixes: 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF")
Cc: stable@vger.kernel.org
Signed-off-by: Yi Yang <yiyang13@huawei.com>
---
drivers/tty/vt/vc_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index 4d2d46c95fef..7d40eacc21b3 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -686,7 +686,7 @@ vcs_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
}
*ppos += written;
ret = written;
- if (written)
+ if (written && vc)
vcs_scr_updated(vc);
return ret;
--
2.25.1
^ permalink raw reply related
* [PATCH] serial: 8250_pci: fix -Winitializer-overrides for Brainboxes UC-260/271/701/756 entries
From: Rosen Penev @ 2026-06-03 23:26 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
PCI_VDEVICE() expands to set .class=0 and .class_mask=0, but the Brainboxes UC-260/271/701/756 entries immediately override those fields. This causes a build error with clang -Werror,-Winitializer-overrides.
Fix by expanding PCI_VDEVICE() manually, omitting the trailing .class/.class_mask zeroes so each field is set exactly once.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/8250/8250_pci.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 3e5bc9e8d269..0513f4b3c093 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5394,12 +5394,14 @@ static const struct pci_device_id serial_pci_tbl[] = {
* Brainboxes UC-260/271/701/756
*/
{
- PCI_VDEVICE(INTASHIELD, 0x0D21),
+ .vendor = PCI_VENDOR_ID_INTASHIELD, .device = 0x0D21,
+ .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
}, {
- PCI_VDEVICE(INTASHIELD, 0x0E34),
+ .vendor = PCI_VENDOR_ID_INTASHIELD, .device = 0x0E34,
+ .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID,
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 2/3] serial: mxs-auart: use devm resources for iomem and GPIO IRQs
From: Frank Li @ 2026-06-03 18:48 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260603025857.287148-3-rosenp@gmail.com>
On Tue, Jun 02, 2026 at 07:58:56PM -0700, Rosen Penev wrote:
> Replace platform_get_resource + ioremap with
> devm_platform_get_and_ioremap_resource and convert GPIO IRQ
> request_irq/free_irq to devm_request_irq. This eliminates the
> mxs_auart_free_gpio_irq function and its call sites, and the
> out_iounmap error label. Simplify the remove function accordingly.
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/tty/serial/mxs-auart.c | 55 ++++++++--------------------------
> 1 file changed, 12 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 1390fa000a5b..4499e3206e85 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1517,15 +1517,6 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
> return 0;
> }
>
> -static void mxs_auart_free_gpio_irq(struct mxs_auart_port *s)
> -{
> - enum mctrl_gpio_idx i;
> -
> - for (i = 0; i < UART_GPIO_MAX; i++)
> - if (s->gpio_irq[i] >= 0)
> - free_irq(s->gpio_irq[i], s);
> -}
> -
> static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
> {
> int *irq = s->gpio_irq;
> @@ -1537,21 +1528,13 @@ static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
> continue;
>
> irq_set_status_flags(irq[i], IRQ_NOAUTOEN);
> - err = request_irq(irq[i], mxs_auart_irq_handle,
> - IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
> + err = devm_request_irq(s->dev, irq[i], mxs_auart_irq_handle,
> + IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
> if (err)
> dev_err(s->dev, "%s - Can't get %d irq\n",
> __func__, irq[i]);
> }
>
> - /*
> - * If something went wrong, rollback.
> - * Be careful: i may be unsigned.
> - */
> - while (err && (i-- > 0))
> - if (irq[i] >= 0)
> - free_irq(irq[i], s);
> -
> return err;
> }
>
> @@ -1586,7 +1569,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - s->devtype = (enum mxs_auart_type)of_device_get_match_data(&pdev->dev);
> + s->devtype = (unsigned long)of_device_get_match_data(&pdev->dev);
This change need seperate patch
Frank
>
> ret = mxs_get_clks(s, pdev);
> if (ret)
> @@ -1596,18 +1579,12 @@ static int mxs_auart_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!r) {
> - ret = -ENXIO;
> + s->port.membase = devm_platform_get_and_ioremap_resource(pdev, 0, &r);
> + if (IS_ERR(s->port.membase)) {
> + ret = PTR_ERR(s->port.membase);
> goto out_disable_clk;
> }
> -
> s->port.mapbase = r->start;
> - s->port.membase = ioremap(r->start, resource_size(r));
> - if (!s->port.membase) {
> - ret = -ENOMEM;
> - goto out_disable_clk;
> - }
> s->port.ops = &mxs_auart_ops;
> s->port.iotype = UPIO_MEM;
> s->port.fifosize = MXS_AUART_FIFO_SIZE;
> @@ -1622,21 +1599,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> ret = irq;
> - goto out_iounmap;
> + goto out_disable_clk;
> }
>
> s->port.irq = irq;
> ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
> dev_name(&pdev->dev), s);
> if (ret)
> - goto out_iounmap;
> + goto out_disable_clk;
>
> platform_set_drvdata(pdev, s);
>
> ret = mxs_auart_init_gpios(s, &pdev->dev);
> if (ret) {
> dev_err(&pdev->dev, "Failed to initialize GPIOs.\n");
> - goto out_iounmap;
> + goto out_disable_clk;
> }
>
> /*
> @@ -1644,7 +1621,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
> */
> ret = mxs_auart_request_gpio_irq(s);
> if (ret)
> - goto out_iounmap;
> + goto out_disable_clk;
>
> auart_port[s->port.line] = s;
>
> @@ -1667,11 +1644,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
> return 0;
>
> out_free_qpio_irq:
> - mxs_auart_free_gpio_irq(s);
> - auart_port[pdev->id] = NULL;
> -
> -out_iounmap:
> - iounmap(s->port.membase);
> + auart_port[s->port.line] = NULL;
>
> out_disable_clk:
> clk_disable_unprepare(s->clk);
> @@ -1683,11 +1656,7 @@ static void mxs_auart_remove(struct platform_device *pdev)
> struct mxs_auart_port *s = platform_get_drvdata(pdev);
>
> uart_remove_one_port(&auart_driver, &s->port);
> - auart_port[pdev->id] = NULL;
> - mxs_auart_free_gpio_irq(s);
> - iounmap(s->port.membase);
> - if (is_asm9260_auart(s))
> - clk_disable_unprepare(s->clk);
> + auart_port[s->port.line] = NULL;
> }
>
> static struct platform_driver mxs_auart_driver = {
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH 1/3] serial: mxs-auart: rework clock handling in mxs_get_clks and probe
From: Frank Li @ 2026-06-03 18:45 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260603025857.287148-2-rosenp@gmail.com>
On Tue, Jun 02, 2026 at 07:58:55PM -0700, Rosen Penev wrote:
> Use devm_clk_get_enabled for the AHB clock so its enable/disable
> lifetime is managed by the driver model. Move the mod clock
> (clk) prepare_enable out of mxs_get_clks and into probe so that
> clk_set_rate is called while the clock is still disabled, avoiding
> CLK_SET_RATE_GATE failures. Clean up the error labels accordingly.
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/tty/serial/mxs-auart.c | 47 ++++++++++++----------------------
> 1 file changed, 17 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 697318dbb146..1390fa000a5b 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1470,34 +1470,22 @@ static int mxs_get_clks(struct mxs_auart_port *s,
> return PTR_ERR(s->clk);
> }
>
> - s->clk_ahb = devm_clk_get(s->dev, "ahb");
> + s->clk_ahb = devm_clk_get_enabled(s->dev, "ahb");
> if (IS_ERR(s->clk_ahb)) {
> dev_err(s->dev, "Failed to get \"ahb\" clk\n");
> return PTR_ERR(s->clk_ahb);
> }
>
> - err = clk_prepare_enable(s->clk_ahb);
> - if (err) {
> - dev_err(s->dev, "Failed to enable ahb_clk!\n");
> - return err;
> - }
> -
> + /*
> + * Set mod clock rate while it is still disabled so
> + * CLK_SET_RATE_GATE does not cause clk_set_rate to fail.
> + * The mod clock will be enabled in mxs_auart_startup()
> + * and in probe after mxs_get_clks returns.
> + */
> err = clk_set_rate(s->clk, clk_get_rate(s->clk_ahb));
> - if (err) {
> + if (err)
> dev_err(s->dev, "Failed to set rate!\n");
> - goto disable_clk_ahb;
> - }
>
> - err = clk_prepare_enable(s->clk);
> - if (err) {
> - dev_err(s->dev, "Failed to enable clk!\n");
> - goto disable_clk_ahb;
> - }
> -
> - return 0;
> -
> -disable_clk_ahb:
> - clk_disable_unprepare(s->clk_ahb);
> return err;
> }
>
> @@ -1604,17 +1592,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = clk_prepare_enable(s->clk);
> + if (ret)
> + return ret;
> +
why not direct enable clock when get?
s->clk = devm_clk_get(s->dev, "mod");
Frank
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!r) {
> ret = -ENXIO;
> - goto out_disable_clks;
> + goto out_disable_clk;
> }
>
> s->port.mapbase = r->start;
> s->port.membase = ioremap(r->start, resource_size(r));
> if (!s->port.membase) {
> ret = -ENOMEM;
> - goto out_disable_clks;
> + goto out_disable_clk;
> }
> s->port.ops = &mxs_auart_ops;
> s->port.iotype = UPIO_MEM;
> @@ -1681,11 +1673,8 @@ static int mxs_auart_probe(struct platform_device *pdev)
> out_iounmap:
> iounmap(s->port.membase);
>
> -out_disable_clks:
> - if (is_asm9260_auart(s)) {
> - clk_disable_unprepare(s->clk);
> - clk_disable_unprepare(s->clk_ahb);
> - }
> +out_disable_clk:
> + clk_disable_unprepare(s->clk);
> return ret;
> }
>
> @@ -1697,10 +1686,8 @@ static void mxs_auart_remove(struct platform_device *pdev)
> auart_port[pdev->id] = NULL;
> mxs_auart_free_gpio_irq(s);
> iounmap(s->port.membase);
> - if (is_asm9260_auart(s)) {
> + if (is_asm9260_auart(s))
> clk_disable_unprepare(s->clk);
> - clk_disable_unprepare(s->clk_ahb);
> - }
> }
>
> static struct platform_driver mxs_auart_driver = {
> --
> 2.54.0
>
^ permalink raw reply
page: next (older)
- 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