* Re: [PATCH 01/15] serial: 8250: split Moxa PCIe serial board support out of 8250_pci
From: Andy Shevchenko @ 2026-05-04 13:27 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-2-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:49 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> The Moxa PCIe multiport serial boards are currently handled as part of
> 8250_pci.c. In preparation for adding Moxa-specific UART features and
> optimizations, move the Moxa PCIe implementation into a dedicated
> driver.
>
> This introduces drivers/tty/serial/8250/8250_mxpcie.c and wires it up
> via Kconfig and Makefile, while preserving the existing probe flow and
> device IDs.
Thanks for doing this!
> This change was suggested during earlier review by Andy Shevchenko.
an earlier
Perhaps you wanted to add a link references here, something like this
This change was suggested during earlier reviews by Andy Shevchenko [1][2].
> No functional change intended.
> Link: https://lore.kernel.org/all/ZmQovC6TbDpTb3c8@surfacebook.localdomain/
> Link: https://lore.kernel.org/all/CAHp75VeDsVt0GQYUFxLM+obfmqXBPa3hM3YMsFbc26uzWZG-SQ@mail.gmail.com/
...and hence
Link: https://lore.kernel.org/all/ZmQovC6TbDpTb3c8@surfacebook.localdomain/
[1]
Link: https://lore.kernel.org/all/CAHp75VeDsVt0GQYUFxLM+obfmqXBPa3hM3YMsFbc26uzWZG-SQ@mail.gmail.com/
[2]
(note [*] references)
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Crescent Hsieh <crescentcy.hsieh@moxa.com>
...
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/device.h>
> +#include <linux/dev_printk.h>
> +#include <linux/types.h>
> +#include <linux/io.h>
> +#include <linux/ioport.h>
> +#include <linux/bits.h>
> +#include <linux/bitfield.h>
Keep above sorted alphabetically, it makes it easier to read and
follow and see if anything is missing or a leftover.
+ blank line (i.o.w. keep the below headers in a separate group as
this driver is 8250 driver)
> +#include <linux/serial_8250.h>
> +#include <linux/serial_core.h>
> +#include <linux/serial_reg.h>
Only the first one is needed.
> +#include <linux/8250_pci.h>
...
> +static unsigned int mxpcie8250_get_supp_rs(unsigned short device)
> +{
> + switch (device & MOXA_DEV_ID_IFACE_MASK) {
> + case 0x0000:
> + case 0x0600:
> + return MOXA_SUPP_RS232;
> + case 0x0100:
> + return MOXA_SUPP_RS232 | MOXA_SUPP_RS422 | MOXA_SUPP_RS485;
> + case 0x0300:
> + return MOXA_SUPP_RS422 | MOXA_SUPP_RS485;
> + }
> +
> + return 0;
Simply make it a default case.
> +}
> +
> +static unsigned short mxpcie8250_get_nports(unsigned short device)
> +{
> + switch (device) {
> + case PCI_DEVICE_ID_MOXA_CP116E_A_A:
> + case PCI_DEVICE_ID_MOXA_CP116E_A_B:
> + return 8;
> + }
> +
> + return FIELD_GET(MOXA_DEV_ID_NPORTS_MASK, device);
Ditto.
> +}
> +
> +static void mxpcie8250_set_interface(struct mxpcie8250 *priv,
> + unsigned int port_idx,
> + u8 mode)
> +{
> + void __iomem *uir_addr = priv->bar2_base + MOXA_UIR_OFFSET + port_idx / 2;
> + u8 cval;
> +
> + cval = ioread8(uir_addr);
> +
> + if (port_idx & 1)
% 2
With them (/2, %2) going closer to each other some compilers gain a
few bytes, see this for example
9b3cd5c7099f ("regmap: place foo / 8 and foo % 8 closer to each other").
> + cval = FIELD_MODIFY(MOXA_ODD_RS_MASK, &cval, mode);
> + else
> + cval = FIELD_MODIFY(MOXA_EVEN_RS_MASK, &cval, mode);
> +
> + iowrite8(cval, uir_addr);
> +}
...
> + priv = devm_kzalloc(dev, struct_size(priv, line, num_ports), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->supp_rs = mxpcie8250_get_supp_rs(device);
> + priv->num_ports = num_ports;
Swap these two lines (by the order) and add __counted_by() to the data
structure.
...
> + for (i = 0; i < num_ports; i++) {
Seems i is not used outside the loop, hence just
for (int i = 0; i < num_ports; i++) {
> + }
...
> +static void mxpcie8250_remove(struct pci_dev *pdev)
> +{
> + struct mxpcie8250 *priv = dev_get_drvdata(&pdev->dev);
platform_get_drvdata() IIRC
> + unsigned int i;
> +
> + for (i = 0; i < priv->num_ports; i++)
As per above.
> + serial8250_unregister_port(priv->line[i]);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 01/15] serial: 8250: split Moxa PCIe serial board support out of 8250_pci
From: Andy Shevchenko @ 2026-05-04 13:29 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <CAHp75VfFMLnLDP0V3U=4zG4Ayj71-ZgVkJsVtgNE=52tGQ963w@mail.gmail.com>
On Mon, May 4, 2026 at 4:27 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, May 4, 2026 at 11:49 AM Crescent Hsieh
> <crescentcy.hsieh@moxa.com> wrote:
...
> > +static void mxpcie8250_remove(struct pci_dev *pdev)
> > +{
> > + struct mxpcie8250 *priv = dev_get_drvdata(&pdev->dev);
>
> platform_get_drvdata() IIRC
Note, for the sake of consistency the probe may use platform_set_drvdata().
> > + unsigned int i;
> > +
> > + for (i = 0; i < priv->num_ports; i++)
>
> As per above.
>
> > + serial8250_unregister_port(priv->line[i]);
> > +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 02/15] serial: core: add uart_iotype_mmio/legacy_io helper functions
From: Andy Shevchenko @ 2026-05-04 14:30 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Hugo Villeneuve, Greg Kroah-Hartman, Jiri Slaby,
Ilpo Järvinen, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <alpine.DEB.2.21.2605041220540.23161@angie.orcam.me.uk>
On Mon, May 04, 2026 at 12:44:41PM +0100, Maciej W. Rozycki wrote:
> On Mon, 4 May 2026, Andy Shevchenko wrote:
...
> > > > Why do we use 'legacy'? Still in use in modern CPUs...
> > >
> > > Deprecated in PCIe and not available in numerous systems. Also actually
> > > called "legacy" in some serial port datasheets aged ~20 years now. While
> > > some contemporary CPUs indeed retain the port I/O address space, it's for
> > > legacy use anyway, you don't want to rely on it in new designs.
> >
> > For the holder of the new (modern) CPU which supports the IO ports, this is
> > definitely not a legacy interface despite on whatever PCIe or other datasheets
> > call it.
>
> I appreciate your point of view, however I disagree that the presence of an
> interface in a contemporary chip makes the interface modern.
I appreciate a bike shedding.
> I see the port I/O space so much legacy as say the PC/AT DMA controller
> (8237 pair), which is similarly present in current x86 chipsets. If this
> stuff was not present, such as say the PC/AT interrupt controller (8259A
> pair), which I believe has been removed from some x86 system designs, then
> it would be obsolete/removed rather than legacy.
>
> It is analogous to PCI/e systems that lack a southbridge and are called
> "legacy-free", as the whole southbridge stuff, the main consumer of the
> port I/O space still remaining in use, is legacy nowadays (the other one I
> know of being the 8255-based PC parallel port, which has been considered a
> legacy interface as well, even though you can still buy and plug one into
> a modern PCIe system).
>
> NB I have a couple of modern x86 CPUs around too that support the port
> I/O space, but it doesn't change my view as to the nomenclature.
Is the regular user assumed to go to dig to the mailing list (at best) or drawn
into the search of the documentation for all this? In their perspective they
possess modern CPU with support of that technology. If the same user possesses
the HW uses that ("legacy") technology, it doesn't make so in their eyes.
On top of that the additional word occupies more space in the code, making it
harder to read. It's just a redundant word. I see no value at all of using it.
P.S.
I see no value in this discussion. And I see no point to add a word where it's
not needed at all.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v1 1/1] serial: 8250_fsl: Export fsl8250_handle_irq() conditionally
From: Andy Shevchenko @ 2026-05-04 15:12 UTC (permalink / raw)
To: Andy Shevchenko, linux-serial, linux-kernel; +Cc: Greg Kroah-Hartman
Move fsl8250_handle_irq() prototype out of the rest of 8250 generic APIs
in the header and export it conditionally when CONFIG_SERIAL_8250_FSL
is provided.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
include/linux/serial_8250.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 1be007225b0e..43eb0d15012f 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -197,7 +197,6 @@ void serial8250_do_pm(struct uart_port *port, unsigned int state,
void serial8250_do_set_mctrl(struct uart_port *port, unsigned int mctrl);
void serial8250_do_set_divisor(struct uart_port *port, unsigned int baud,
unsigned int quot);
-int fsl8250_handle_irq(struct uart_port *port);
void serial8250_handle_irq_locked(struct uart_port *port, unsigned int iir);
int serial8250_handle_irq(struct uart_port *port, unsigned int iir);
u16 serial8250_rx_chars(struct uart_8250_port *up, u16 lsr);
@@ -220,6 +219,10 @@ extern int hp300_setup_serial_console(void) __init;
static inline int hp300_setup_serial_console(void) { return 0; }
#endif
+#if IS_REACHABLE(CONFIG_SERIAL_8250_FSL)
+int fsl8250_handle_irq(struct uart_port *port);
+#endif
+
#ifdef CONFIG_SERIAL_8250_RT288X
int rt288x_setup(struct uart_port *p);
int au_platform_setup(struct plat_serial8250_port *p);
--
2.50.1
^ permalink raw reply related
* Re: [PATCH 03/15] serial: 8250_mxpcie: enable enhanced mode and program FIFO trigger levels
From: Andy Shevchenko @ 2026-05-04 15:18 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-4-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:49 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> The MUEx50 UART provides an enhanced register set and programmable FIFO
> trigger levels for RX, TX, and flow control.
>
> Enable enhanced mode during port startup and program the MUEx50 FIFO
> trigger registers according to the configured port settings. Clear the
> programmed state again during shutdown to restore the default UART
> configuration.
...
> +static int mxpcie8250_startup(struct uart_port *port)
> +{
> + struct uart_8250_port *up = up_to_u8250p(port);
> + unsigned int i;
> + int ret;
> +
> + ret = serial8250_do_startup(port);
> + if (ret)
> + return ret;
This needs a good comment explaining the retry logic. Why do we even need this?
> + for (i = 0; i < 5; ++i)
for (unsigned int i ...)
> + serial_out(up, UART_FCR, UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
> +
> + serial_out(up, MOXA_PUART_EFR, MOXA_PUART_EFR_ENHANCED);
> + serial_out(up, MOXA_PUART_SFR, MOXA_PUART_SFR_950);
> +
> + serial_out(up, MOXA_PUART_TTL, 0);
> + serial_out(up, MOXA_PUART_RTL, 96);
> + serial_out(up, MOXA_PUART_FCL, 16);
> + serial_out(up, MOXA_PUART_FCH, 110);
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 02/15] serial: core: add uart_iotype_mmio/legacy_io helper functions
From: Maciej W. Rozycki @ 2026-05-04 15:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Hugo Villeneuve, Greg Kroah-Hartman, Jiri Slaby,
Ilpo Järvinen, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <afitf0I1izLup5TR@ashevche-desk.local>
On Mon, 4 May 2026, Andy Shevchenko wrote:
> I see no value in this discussion. And I see no point to add a word where it's
> not needed at all.
Agreed. I just pointed out that the use of "legacy" in this context is
not incorrect. And "regular users" won't see any of this stuff anyway.
Maciej
^ permalink raw reply
* Re: [PATCH 05/15] serial: 8250_mxpcie: offload XON/XOFF flow control to MUEx50 hardware
From: Andy Shevchenko @ 2026-05-04 15:20 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-6-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:50 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> The MUEx50 UART can handle in-band software flow control (XON/XOFF)
> directly in hardware.
>
> Program the on-chip XON/XOFF characters from termios settings and enable
> the corresponding MUEx50 flow control modes when IXON or IXOFF is
> requested. Provide throttle and unthrottle callbacks so RX can be
> stopped and resumed cleanly.
...
> +static void mxpcie8250_throttle(struct uart_port *port)
> +{
> + unsigned long flags;
> + uart_port_lock_irqsave(port, &flags);
You may use guard()() from cleanup.h.
> + port->ops->stop_rx(port);
> +
> + uart_port_unlock_irqrestore(port, flags);
> +}
> +
> +static void mxpcie8250_unthrottle(struct uart_port *port)
> +{
> + struct uart_8250_port *up = up_to_u8250p(port);
> + unsigned long flags;
> +
> + uart_port_lock_irqsave(port, &flags);
> +
> + up->ier |= UART_IER_RLSI | UART_IER_RDI;
> + port->read_status_mask |= UART_LSR_DR;
> + serial_out(up, UART_IER, up->ier);
> +
> + uart_port_unlock_irqrestore(port, flags);
Ditto.
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 05/15] serial: core: replace snprintf with more robust scnprintf
From: Hugo Villeneuve @ 2026-05-04 15:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, ilpo.jarvinen, linux-kernel,
linux-serial, Hugo Villeneuve
In-Reply-To: <afNwH01y_6Dk2hVb@black.igk.intel.com>
On Thu, 30 Apr 2026 17:07:11 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Apr 28, 2026 at 01:53:51PM -0400, Hugo Villeneuve wrote:
> >
> > Use scnprintf() so we could perhaps one day get rid of snprintf() entirely.
>
> Ah, now I understand the approach in earlycon. Hmm... Still not sure which one
> I prefer (it's not related to the contents of this patch anyway).
>
> ...
>
> > default:
> > strscpy(address, "*unknown*", sizeof(address));
>
> Side note: This may use 2-argument strscpy().
This section is now removed in patch:
serial: core: use uart_iotype_*() to simplify uart_report_port()
But interesting to know this 2-argument variant :)
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v2 08/15] serial: earlycon: use uart_iotype_*() to simplify code
From: Hugo Villeneuve @ 2026-05-04 15:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, ilpo.jarvinen, linux-kernel,
linux-serial, Hugo Villeneuve
In-Reply-To: <afNvR59jmKu3-CoF@black.igk.intel.com>
On Thu, 30 Apr 2026 17:03:35 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Apr 28, 2026 at 01:53:54PM -0400, Hugo Villeneuve wrote:
>
> > Make use of new functions uart_iotype_mmio() and uart_iotype_legacy_io()
> > to simplify and improve code readability.
>
> ...
>
> > + char address[64] = "";
>
> TBH, I prefer two pr_info() calls as that approach
> - doesn't require temporary buffer
> - doesn't use heavy s*printf() on top of the existing printing
> - doesn't limit the flexibility of each of the strings (64 might
> become not enough in some cases, however unlikely to happen)
Note that this approach is already used in uart_report_port().
Also this patch may be reworked if patch "serial: uniformize serial
port I/O infos display" is deemed ok...
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v2 05/15] serial: core: replace snprintf with more robust scnprintf
From: Andy Shevchenko @ 2026-05-04 15:59 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, ilpo.jarvinen, linux-kernel,
linux-serial, Hugo Villeneuve
In-Reply-To: <20260504112712.7f3d74b47d76d0956b1911fc@hugovil.com>
On Mon, May 04, 2026 at 11:27:12AM -0400, Hugo Villeneuve wrote:
> On Thu, 30 Apr 2026 17:07:11 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Apr 28, 2026 at 01:53:51PM -0400, Hugo Villeneuve wrote:
...
> > > default:
> > > strscpy(address, "*unknown*", sizeof(address));
> >
> > Side note: This may use 2-argument strscpy().
>
> This section is now removed in patch:
> serial: core: use uart_iotype_*() to simplify uart_report_port()
>
> But interesting to know this 2-argument variant :)
Yep, we have a handful of functions (actually macros) that use some magic
to allow supply different number of arguments to the same macro and behave
accordingly.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 02/15] serial: core: add uart_iotype_mmio/legacy_io helper functions
From: Andy Shevchenko @ 2026-05-04 15:59 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Hugo Villeneuve, Greg Kroah-Hartman, Jiri Slaby,
Ilpo Järvinen, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <alpine.DEB.2.21.2605041617190.23161@angie.orcam.me.uk>
On Mon, May 04, 2026 at 04:20:13PM +0100, Maciej W. Rozycki wrote:
> On Mon, 4 May 2026, Andy Shevchenko wrote:
>
> > I see no value in this discussion. And I see no point to add a word where it's
> > not needed at all.
>
> Agreed. I just pointed out that the use of "legacy" in this context is
> not incorrect. And "regular users" won't see any of this stuff anyway.
Good, thanks for the point!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 08/15] serial: earlycon: use uart_iotype_*() to simplify code
From: Andy Shevchenko @ 2026-05-04 16:01 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, ilpo.jarvinen, linux-kernel,
linux-serial, Hugo Villeneuve
In-Reply-To: <20260504114001.a20541e974060c6fe2f26ba1@hugovil.com>
On Mon, May 04, 2026 at 11:40:01AM -0400, Hugo Villeneuve wrote:
> On Thu, 30 Apr 2026 17:03:35 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Apr 28, 2026 at 01:53:54PM -0400, Hugo Villeneuve wrote:
...
> > > + char address[64] = "";
> >
> > TBH, I prefer two pr_info() calls as that approach
> > - doesn't require temporary buffer
> > - doesn't use heavy s*printf() on top of the existing printing
> > - doesn't limit the flexibility of each of the strings (64 might
> > become not enough in some cases, however unlikely to happen)
>
> Note that this approach is already used in uart_report_port().
Yeah, yeah... I noticed that after review.
> Also this patch may be reworked if patch "serial: uniformize serial
> port I/O infos display" is deemed ok...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] tty: synclink_gt: remove broken driver
From: Jakub Kicinski @ 2026-05-05 0:03 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, netdev, linux-serial, rust-for-linux, Jonathan Corbet,
Shuah Khan, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Greg Kroah-Hartman,
Jiri Slaby, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Bagas Sanjaya, Haren Myneni,
Eric Biggers, Julian Braha, Qingfang Deng
In-Reply-To: <20260504031519.18877-1-enelsonmoore@gmail.com>
On Sun, 3 May 2026 20:14:53 -0700 Ethan Nelson-Moore wrote:
> drivers/net/ppp/Kconfig | 4 +-
Acked-by: Jakub Kicinski <kuba@kernel.org>
^ permalink raw reply
* [PATCH 0/3] Small cleanups to serial driver organization, configuration, and documentation
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
This patch series moves some serial drivers into the serial/ directory
to improve organization, and removes the SERIAL_NONSTANDARD config
option, which adds unnecessary complexity. It also fixes a number of
issues in Documentation/driver-api/tty/index.rst, which I noticed
while making the above changes. The patch to remove SERIAL_NONSTANDARD
touches sections of the tty and serial Kconfig files which are also
touched by the patch to move drivers, and therefore the patches would
fail to apply separately, so I am sending them as a series.
Ethan Nelson-Moore (3):
tty: move remaining serial drivers into the serial/ directory
tty: remove unnecessary SERIAL_NONSTANDARD config option
docs: driver-api/tty/index.rst: copy-editing; improve organization
Documentation/driver-api/serial/index.rst | 1 +
.../{tty => serial}/moxa-smartio.rst | 0
Documentation/driver-api/tty/index.rst | 47 +++++++++----------
MAINTAINERS | 4 +-
arch/arm/configs/footbridge_defconfig | 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/mps2_defconfig | 1 -
arch/arm/configs/neponset_defconfig | 1 -
arch/arm/configs/stm32_defconfig | 1 -
arch/csky/configs/defconfig | 1 -
arch/loongarch/configs/loongson32_defconfig | 1 -
arch/loongarch/configs/loongson64_defconfig | 1 -
arch/mips/configs/bigsur_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 1 -
arch/mips/configs/loongson2k_defconfig | 1 -
arch/mips/configs/loongson3_defconfig | 1 -
arch/powerpc/configs/cell_defconfig | 1 -
arch/powerpc/configs/microwatt_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/sh/configs/polaris_defconfig | 1 -
arch/x86/configs/i386_defconfig | 1 -
arch/x86/configs/x86_64_defconfig | 1 -
drivers/tty/Kconfig | 41 ----------------
drivers/tty/Makefile | 3 --
drivers/tty/serial/Kconfig | 23 +++++++++
drivers/tty/serial/Makefile | 6 ++-
drivers/tty/{ => serial}/amiserial.c | 0
drivers/tty/{ => serial}/moxa.c | 0
drivers/tty/{ => serial}/mxser.c | 0
tools/testing/selftests/bpf/config.x86_64 | 1 -
tools/testing/selftests/hid/config.common | 1 -
31 files changed, 54 insertions(+), 91 deletions(-)
rename Documentation/driver-api/{tty => serial}/moxa-smartio.rst (100%)
rename drivers/tty/{ => serial}/amiserial.c (100%)
rename drivers/tty/{ => serial}/moxa.c (100%)
rename drivers/tty/{ => serial}/mxser.c (100%)
--
2.43.0
^ permalink raw reply
* [PATCH 1/3] tty: move remaining serial drivers into the serial/ directory
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
In-Reply-To: <cover.1777943090.git.enelsonmoore@gmail.com>
A few TTY drivers are outside the serial/ directory despite being for
serial devices. Move them and their documentation into the correct
directories.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/driver-api/serial/index.rst | 1 +
.../{tty => serial}/moxa-smartio.rst | 0
Documentation/driver-api/tty/index.rst | 1 -
MAINTAINERS | 4 ++--
drivers/tty/Kconfig | 23 -------------------
drivers/tty/Makefile | 3 ---
drivers/tty/serial/Kconfig | 23 +++++++++++++++++++
drivers/tty/serial/Makefile | 6 ++++-
drivers/tty/{ => serial}/amiserial.c | 0
drivers/tty/{ => serial}/moxa.c | 0
drivers/tty/{ => serial}/mxser.c | 0
11 files changed, 31 insertions(+), 30 deletions(-)
rename Documentation/driver-api/{tty => serial}/moxa-smartio.rst (100%)
rename drivers/tty/{ => serial}/amiserial.c (100%)
rename drivers/tty/{ => serial}/moxa.c (100%)
rename drivers/tty/{ => serial}/mxser.c (100%)
diff --git a/Documentation/driver-api/serial/index.rst b/Documentation/driver-api/serial/index.rst
index 610744df5e8d..f92581fc3478 100644
--- a/Documentation/driver-api/serial/index.rst
+++ b/Documentation/driver-api/serial/index.rst
@@ -18,3 +18,4 @@ Serial drivers
serial-iso7816
serial-rs485
+ moxa-smartio
diff --git a/Documentation/driver-api/tty/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst
similarity index 100%
rename from Documentation/driver-api/tty/moxa-smartio.rst
rename to Documentation/driver-api/serial/moxa-smartio.rst
diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst
index c1ffe3d1ec46..6a08aebbc47c 100644
--- a/Documentation/driver-api/tty/index.rst
+++ b/Documentation/driver-api/tty/index.rst
@@ -70,6 +70,5 @@ Miscellaneous documentation can be further found in these documents:
.. toctree::
:maxdepth: 2
- moxa-smartio
n_gsm
n_tty
diff --git a/MAINTAINERS b/MAINTAINERS
index 882214b0e7db..c99671d465af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18022,8 +18022,8 @@ F: net/dsa/tag_yt921x.c
MOXA SMARTIO/INDUSTIO/INTELLIO SERIAL CARD
M: Jiri Slaby <jirislaby@kernel.org>
S: Maintained
-F: Documentation/driver-api/tty/moxa-smartio.rst
-F: drivers/tty/mxser.*
+F: Documentation/driver-api/serial/moxa-smartio.rst
+F: drivers/tty/serial/mxser.*
MP3309C BACKLIGHT DRIVER
M: Flavio Suligoi <f.suligoi@asem.it>
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index df6832a4c237..63b378e44a59 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -208,29 +208,6 @@ config SERIAL_NONSTANDARD
Most people can say N here.
-config MOXA_INTELLIO
- tristate "Moxa Intellio support"
- depends on SERIAL_NONSTANDARD && PCI
- select FW_LOADER
- help
- Say Y here if you have a Moxa Intellio multiport serial card.
-
- To compile this driver as a module, choose M here: the
- module will be called moxa.
-
-config MOXA_SMARTIO
- tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI && HAS_IOPORT
- help
- Say Y here if you have a Moxa SmartIO multiport serial card and/or
- want to help develop a new version of this driver.
-
- This is upgraded (1.9.1) driver from original Moxa drivers with
- changes finally resulting in PCI probing.
-
- This driver can also be built as a module. The module will be called
- mxser. If you want to do that, say M here.
-
config N_HDLC
tristate "HDLC line discipline support"
depends on SERIAL_NONSTANDARD
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 8ca1a0a2229f..fd88830b925d 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -16,9 +16,6 @@ obj-y += serial/
obj-$(CONFIG_SERIAL_DEV_BUS) += serdev/
# tty drivers
-obj-$(CONFIG_AMIGA_BUILTIN_SERIAL) += amiserial.o
-obj-$(CONFIG_MOXA_INTELLIO) += moxa.o
-obj-$(CONFIG_MOXA_SMARTIO) += mxser.o
obj-$(CONFIG_NOZOMI) += nozomi.o
obj-$(CONFIG_NULL_TTY) += ttynull.o
obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 9aa61c93d7bc..999f56307445 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1592,6 +1592,29 @@ config SERIAL_NUVOTON_MA35D1_CONSOLE
but you can alter that using a kernel command line option such as
"console=ttyNVTx".
+config MOXA_INTELLIO
+ tristate "Moxa Intellio support"
+ depends on SERIAL_NONSTANDARD && PCI
+ select FW_LOADER
+ help
+ Say Y here if you have a Moxa Intellio multiport serial card.
+
+ To compile this driver as a module, choose M here: the
+ module will be called moxa.
+
+config MOXA_SMARTIO
+ tristate "Moxa SmartIO support v. 2.0"
+ depends on SERIAL_NONSTANDARD && PCI && HAS_IOPORT
+ help
+ Say Y here if you have a Moxa SmartIO multiport serial card and/or
+ want to help develop a new version of this driver.
+
+ This is upgraded (1.9.1) driver from original Moxa drivers with
+ changes finally resulting in PCI probing.
+
+ This driver can also be built as a module. The module will be called
+ mxser. If you want to do that, say M here.
+
endmenu
config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index bba7b21a4a1d..246e0cf29fcc 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -10,9 +10,11 @@ obj-$(CONFIG_SERIAL_EARLYCON) += earlycon.o
obj-$(CONFIG_SERIAL_EARLYCON_SEMIHOST) += earlycon-semihost.o
obj-$(CONFIG_SERIAL_EARLYCON_RISCV_SBI) += earlycon-riscv-sbi.o
-# These Sparc drivers have to appear before others such as 8250
+# These drivers have to appear before others such as 8250
# which share ttySx minor node space. Otherwise console device
# names change and other unplesantries.
+obj-$(CONFIG_AMIGA_BUILTIN_SERIAL) += amiserial.o
+
obj-$(CONFIG_SERIAL_SUNCORE) += suncore.o
obj-$(CONFIG_SERIAL_SUNHV) += sunhv.o
obj-$(CONFIG_SERIAL_SUNZILOG) += sunzilog.o
@@ -53,12 +55,14 @@ obj-$(CONFIG_SERIAL_MCF) += mcf.o
obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o
obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o
obj-$(CONFIG_SERIAL_MESON) += meson_uart.o
+obj-$(CONFIG_MOXA_INTELLIO) += moxa.o
obj-$(CONFIG_SERIAL_MPC52xx) += mpc52xx_uart.o
obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o
obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
obj-$(CONFIG_SERIAL_MUX) += mux.o
obj-$(CONFIG_SERIAL_MVEBU_UART) += mvebu-uart.o
obj-$(CONFIG_SERIAL_MXS_AUART) += mxs-auart.o
+obj-$(CONFIG_MOXA_SMARTIO) += mxser.o
obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_SERIAL_OWL) += owl-uart.o
obj-$(CONFIG_SERIAL_PCH_UART) += pch_uart.o
diff --git a/drivers/tty/amiserial.c b/drivers/tty/serial/amiserial.c
similarity index 100%
rename from drivers/tty/amiserial.c
rename to drivers/tty/serial/amiserial.c
diff --git a/drivers/tty/moxa.c b/drivers/tty/serial/moxa.c
similarity index 100%
rename from drivers/tty/moxa.c
rename to drivers/tty/serial/moxa.c
diff --git a/drivers/tty/mxser.c b/drivers/tty/serial/mxser.c
similarity index 100%
rename from drivers/tty/mxser.c
rename to drivers/tty/serial/mxser.c
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] tty: remove unnecessary SERIAL_NONSTANDARD config option
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
In-Reply-To: <cover.1777943090.git.enelsonmoore@gmail.com>
The SERIAL_NONSTANDARD config option currently only guards the
selection of two Moxa multiport serial card drivers and the HDLC line
discipline, so it does not significantly simplify configuration. Make
the configuration process more straightforward by dropping this option
and dependencies on it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
| 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/mps2_defconfig | 1 -
arch/arm/configs/neponset_defconfig | 1 -
arch/arm/configs/stm32_defconfig | 1 -
arch/csky/configs/defconfig | 1 -
arch/loongarch/configs/loongson32_defconfig | 1 -
arch/loongarch/configs/loongson64_defconfig | 1 -
arch/mips/configs/bigsur_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 1 -
arch/mips/configs/loongson2k_defconfig | 1 -
arch/mips/configs/loongson3_defconfig | 1 -
arch/powerpc/configs/cell_defconfig | 1 -
arch/powerpc/configs/microwatt_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/sh/configs/polaris_defconfig | 1 -
arch/x86/configs/i386_defconfig | 1 -
arch/x86/configs/x86_64_defconfig | 1 -
drivers/tty/Kconfig | 18 ------------------
drivers/tty/serial/Kconfig | 4 ++--
tools/testing/selftests/bpf/config.x86_64 | 1 -
tools/testing/selftests/hid/config.common | 1 -
22 files changed, 2 insertions(+), 40 deletions(-)
--git a/arch/arm/configs/footbridge_defconfig b/arch/arm/configs/footbridge_defconfig
index 5f6963687ee4..58234fd3af4b 100644
--- a/arch/arm/configs/footbridge_defconfig
+++ b/arch/arm/configs/footbridge_defconfig
@@ -70,7 +70,6 @@ CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_SERIAL_21285=y
CONFIG_SERIAL_21285_CONSOLE=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_PRINTER=m
CONFIG_DS1620=y
CONFIG_NWBUTTON=y
diff --git a/arch/arm/configs/lpc18xx_defconfig b/arch/arm/configs/lpc18xx_defconfig
index f142a6637ede..9ca18939b82a 100644
--- a/arch/arm/configs/lpc18xx_defconfig
+++ b/arch/arm/configs/lpc18xx_defconfig
@@ -92,7 +92,6 @@ CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C_LPC2K=y
CONFIG_SPI=y
diff --git a/arch/arm/configs/mps2_defconfig b/arch/arm/configs/mps2_defconfig
index e995e50537ef..a1045dee7e8a 100644
--- a/arch/arm/configs/mps2_defconfig
+++ b/arch/arm/configs/mps2_defconfig
@@ -66,7 +66,6 @@ CONFIG_SMSC911X=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_MPS2_UART_CONSOLE=y
CONFIG_SERIAL_MPS2_UART=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
diff --git a/arch/arm/configs/neponset_defconfig b/arch/arm/configs/neponset_defconfig
index 8a5dcca743fc..2080e4dfdd6c 100644
--- a/arch/arm/configs/neponset_defconfig
+++ b/arch/arm/configs/neponset_defconfig
@@ -51,7 +51,6 @@ CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CS=y
CONFIG_SERIAL_SA1100=y
CONFIG_SERIAL_SA1100_CONSOLE=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_WATCHDOG=y
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 82190b155b14..919c70107371 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -39,7 +39,6 @@ CONFIG_KEYBOARD_GPIO=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_STM32=y
CONFIG_SERIAL_STM32_CONSOLE=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
diff --git a/arch/csky/configs/defconfig b/arch/csky/configs/defconfig
index ff559e5162aa..481b51eadf41 100644
--- a/arch/csky/configs/defconfig
+++ b/arch/csky/configs/defconfig
@@ -20,7 +20,6 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=65536
CONFIG_VT_HW_CONSOLE_BINDING=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
diff --git a/arch/loongarch/configs/loongson32_defconfig b/arch/loongarch/configs/loongson32_defconfig
index d5ef396dffe3..5dd7b8cb8957 100644
--- a/arch/loongarch/configs/loongson32_defconfig
+++ b/arch/loongarch/configs/loongson32_defconfig
@@ -723,7 +723,6 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_LOONGSON=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_PRINTER=m
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
diff --git a/arch/loongarch/configs/loongson64_defconfig b/arch/loongarch/configs/loongson64_defconfig
index cba4cdff5acd..80396cd61755 100644
--- a/arch/loongarch/configs/loongson64_defconfig
+++ b/arch/loongarch/configs/loongson64_defconfig
@@ -739,7 +739,6 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_LOONGSON=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_PRINTER=m
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
diff --git a/arch/mips/configs/bigsur_defconfig b/arch/mips/configs/bigsur_defconfig
index aa63ada62e28..602795e2659c 100644
--- a/arch/mips/configs/bigsur_defconfig
+++ b/arch/mips/configs/bigsur_defconfig
@@ -121,7 +121,6 @@ CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_INPUT is not set
CONFIG_SERIO_RAW=m
# CONFIG_VT is not set
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
diff --git a/arch/mips/configs/lemote2f_defconfig b/arch/mips/configs/lemote2f_defconfig
index b9f3e1641105..084b569cf8d8 100644
--- a/arch/mips/configs/lemote2f_defconfig
+++ b/arch/mips/configs/lemote2f_defconfig
@@ -125,7 +125,6 @@ CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_HW_RANDOM=y
CONFIG_GPIO_LOONGSON=y
CONFIG_THERMAL=y
diff --git a/arch/mips/configs/loongson2k_defconfig b/arch/mips/configs/loongson2k_defconfig
index ca534a6b66de..0b29ad43b62b 100644
--- a/arch/mips/configs/loongson2k_defconfig
+++ b/arch/mips/configs/loongson2k_defconfig
@@ -222,7 +222,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_HW_RANDOM=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_PIIX4=y
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 12cb1a6a1360..00bf6358357f 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -254,7 +254,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_I2C_CHARDEV=y
diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig
index 7a31b52e92e1..439c03172deb 100644
--- a/arch/powerpc/configs/cell_defconfig
+++ b/arch/powerpc/configs/cell_defconfig
@@ -135,7 +135,6 @@ CONFIG_GELIC_WIRELESS=y
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO_I8042 is not set
# CONFIG_LEGACY_PTYS is not set
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
index d81989a6f59b..60dce8b41f97 100644
--- a/arch/powerpc/configs/microwatt_defconfig
+++ b/arch/powerpc/configs/microwatt_defconfig
@@ -64,7 +64,6 @@ CONFIG_LITEX_LITEETH=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_NVRAM is not set
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index 4ddd2c01b8b7..b745965c5215 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -550,7 +550,6 @@ CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m
# CONFIG_LEGACY_PTYS is not set
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_NOZOMI=m
CONFIG_N_HDLC=m
CONFIG_SERIAL_8250=y
diff --git a/arch/sh/configs/polaris_defconfig b/arch/sh/configs/polaris_defconfig
index 4f0396c2ac79..0b51a85300a6 100644
--- a/arch/sh/configs/polaris_defconfig
+++ b/arch/sh/configs/polaris_defconfig
@@ -54,7 +54,6 @@ CONFIG_SMSC911X=y
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
CONFIG_VT_HW_CONSOLE_BINDING=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=3
CONFIG_SERIAL_SH_SCI_CONSOLE=y
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 79fa38ca954d..b67e7073da10 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -182,7 +182,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 269f7d808be4..5db8acec1e37 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -177,7 +177,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_INTEL is not set
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 63b378e44a59..a9ade8bc88b2 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -191,26 +191,8 @@ config LDISC_AUTOLOAD
source "drivers/tty/serial/Kconfig"
-config SERIAL_NONSTANDARD
- bool "Non-standard serial port support"
- depends on HAS_IOMEM
- help
- Say Y here if you have any non-standard serial boards -- boards
- which aren't supported using the standard "dumb" serial driver.
- This includes intelligent serial boards such as
- Digiboards, etc. These are usually used for systems that need many
- serial ports because they serve many terminals or dial-in
- connections.
-
- Note that the answer to this question won't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about non-standard serial boards.
-
- Most people can say N here.
-
config N_HDLC
tristate "HDLC line discipline support"
- depends on SERIAL_NONSTANDARD
help
Allows synchronous HDLC communications with tty device drivers that
support synchronous HDLC.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 999f56307445..6e448a6f1020 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1594,7 +1594,7 @@ config SERIAL_NUVOTON_MA35D1_CONSOLE
config MOXA_INTELLIO
tristate "Moxa Intellio support"
- depends on SERIAL_NONSTANDARD && PCI
+ depends on PCI
select FW_LOADER
help
Say Y here if you have a Moxa Intellio multiport serial card.
@@ -1604,7 +1604,7 @@ config MOXA_INTELLIO
config MOXA_SMARTIO
tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI && HAS_IOPORT
+ depends on PCI && HAS_IOPORT
help
Say Y here if you have a Moxa SmartIO multiport serial card and/or
want to help develop a new version of this driver.
diff --git a/tools/testing/selftests/bpf/config.x86_64 b/tools/testing/selftests/bpf/config.x86_64
index 42ad817b00ae..2fc3e7e6ae5e 100644
--- a/tools/testing/selftests/bpf/config.x86_64
+++ b/tools/testing/selftests/bpf/config.x86_64
@@ -189,7 +189,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SGI_PARTITION=y
CONFIG_SMP=y
diff --git a/tools/testing/selftests/hid/config.common b/tools/testing/selftests/hid/config.common
index 38c51158adf8..89a83cda737b 100644
--- a/tools/testing/selftests/hid/config.common
+++ b/tools/testing/selftests/hid/config.common
@@ -201,7 +201,6 @@ CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SGI_PARTITION=y
CONFIG_SMP=y
--
2.43.0
^ permalink raw reply related
* [PATCH 3/3] docs: driver-api/tty/index.rst: copy-editing; improve organization
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
In-Reply-To: <cover.1777943090.git.enelsonmoore@gmail.com>
The TTY driver API intro document contains a number of grammar and
capitalization issues. Fix them.
Now that the MOXA Smartio driver documentation is in the serial/
directory, the "Other Documentation" section only contains TTY line
disciplines. Rename it to reflect that.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/driver-api/tty/index.rst | 46 +++++++++++++-------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst
index 6a08aebbc47c..eb5d602450f8 100644
--- a/Documentation/driver-api/tty/index.rst
+++ b/Documentation/driver-api/tty/index.rst
@@ -4,29 +4,30 @@
TTY
===
-Teletypewriter (TTY) layer takes care of all those serial devices. Including
-the virtual ones like pseudoterminal (PTY).
+The teletypewriter (TTY) layer handles all serial devices, including
+virtual ones like pseudoterminals (PTYs).
-TTY structures
+TTY Structures
==============
There are several major TTY structures. Every TTY device in a system has a
corresponding struct tty_port. These devices are maintained by a TTY driver
-which is struct tty_driver. This structure describes the driver but also
-contains a reference to operations which could be performed on the TTYs. It is
-struct tty_operations. Then, upon open, a struct tty_struct is allocated and
+defined by struct tty_driver. This structure describes the driver but also
+contains a reference to struct tty_operations, which defines operations which
+can be performed on the TTY. Upon open, a struct tty_struct is allocated and
lives until the final close. During this time, several callbacks from struct
tty_operations are invoked by the TTY layer.
-Every character received by the kernel (both from devices and users) is passed
+Every character received by the kernel (from both devices and users) is passed
through a preselected :doc:`tty_ldisc` (in
short ldisc; in C, struct tty_ldisc_ops). Its task is to transform characters
-as defined by a particular ldisc or by user too. The default one is n_tty,
-implementing echoes, signal handling, jobs control, special characters
-processing, and more. The transformed characters are passed further to
-user/device, depending on the source.
+as defined by a particular ldisc or by the user. The default one is n_tty,
+which implements echoes, signal handling, jobs control, special characters
+processing, and more. The transformed characters are passed on further to the
+user or device, depending on the source.
-In-detail description of the named TTY structures is in separate documents:
+A detailed description of the named TTY structures is contained in separate
+documents:
.. toctree::
:maxdepth: 2
@@ -40,14 +41,14 @@ In-detail description of the named TTY structures is in separate documents:
tty_internals
console
-Writing TTY Driver
-==================
+Writing TTY Drivers
+===================
-Before one starts writing a TTY driver, they must consider
-:doc:`Serial <../serial/driver>` and :doc:`USB Serial <../../usb/usb-serial>`
+Before you start writing a TTY driver, you should consider using the
+:doc:`serial <../serial/driver>` and :doc:`USB serial <../../usb/usb-serial>`
layers first. Drivers for serial devices can often use one of these specific
layers to implement a serial driver. Only special devices should be handled
-directly by the TTY Layer. If you are about to write such a driver, read on.
+directly by the TTY layer. If you are about to write such a driver, read on.
A *typical* sequence a TTY driver performs is as follows:
@@ -58,14 +59,13 @@ A *typical* sequence a TTY driver performs is as follows:
#. Remove devices as they are going away (remove function)
#. Unregister and free the TTY driver (module exit)
-Steps regarding driver, i.e. 1., 3., and 5. are described in detail in
-:doc:`tty_driver`. For the other two (devices handling), look into
-:doc:`tty_port`.
+Steps regarding the driver, i.e., steps 1, 3, and 5, are described in detail in
+:doc:`tty_driver`. For the other two (device handling), see :doc:`tty_port`.
-Other Documentation
-===================
+Line Disciplines
+================
-Miscellaneous documentation can be further found in these documents:
+Documentation for TTY line disciplines can be found in the following documents:
.. toctree::
:maxdepth: 2
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/3] tty: move remaining serial drivers into the serial/ directory
From: Jiri Slaby @ 2026-05-05 5:59 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-serial
Cc: Greg Kroah-Hartman, Ilpo Järvinen, Andy Shevchenko,
Ray Chen (陳松昱), Crescent CY Hsieh,
linux-m68k, Geert Uytterhoeven
In-Reply-To: <042d993686c87fdfd4130f11b57c3b559944603d.1777943090.git.enelsonmoore@gmail.com>
On 05. 05. 26, 3:20, Ethan Nelson-Moore wrote:
> A few TTY drivers are outside the serial/ directory despite being for
> serial devices.
Yes, but serial/ (historically) contains drivers using serial_core. tty/
contains drivers using tty_driver (which all of three unfortunately do).
There was a patchset from Crescent Hsieh (Moxa) to convert mxser [1].
Amiserial should be likely converted too -- Amiga users still around?
There is no MAINTAINERS entry for Amiga, trying to CC m68k...
I am not sure even about users of Moxa Intellio. I think I prompted long
time ago. Oh yes, Ray Chen (CCed) from Moxa wrote me back in 2021:
=== 8< ===
For the Intellio cards, we phased them out in 2017.
You may find the discontinuance notification as attached.
We will keep the software support for 5 years, to 2023.
=== 8< ===
I believe we can mark it as BROKEN to let someone convert it to
serial_core. Or drop it for good already.
[1]
https://lore.kernel.org/all/20251130104222.63077-1-crescentcy.hsieh@moxa.com/
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH] serial: jsm: Use named initializers for struct pci_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-05 7:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Lukas Wunner, Dave Jiang,
Giovanni Cabiddu, Kees Cook
Cc: linux-serial, linux-kernel, Markus Schneider-Pargmann
Initializing structures using list initializers is harder to read than
using named initializers. Seeing the member name is more ideomatic and
easier to understand.
Use named initializers for the driver's pci_device_id array. While at it
also drop an explicit zero in the terminating array entry.
There are no changes to the compiled result of the array; verified with
builds for x86 and arm64.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
this is a preparing change for making struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/).
This requires named initializers for .driver_data. But even without that
this is a nice cleanup making the array better readable.
Having said that I didn't find where .driver_data is used, so unless I
missed something the assignments can just go away???
For earlier patches of this type against other drivers I got the
feedback to use PCI_DEVICE_DATA() but I don't like that as it mixes
hardware properties (.vendor and .device) with driver specific software
properties (.driver_data) and thus I prefer the explicit listing
(involving more repetition) over the shorter variant (being more opaque
and harder to read).
Best regards
Uwe
drivers/tty/serial/jsm/jsm_driver.c | 75 +++++++++++++++++++++--------
1 file changed, 56 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
index 4b73e51f83fb..422cac8d8d71 100644
--- a/drivers/tty/serial/jsm/jsm_driver.c
+++ b/drivers/tty/serial/jsm/jsm_driver.c
@@ -296,25 +296,62 @@ static void jsm_remove_one(struct pci_dev *pdev)
}
static const struct pci_device_id jsm_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9), 0, 0, 0 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI), 0, 0, 1 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45), 0, 0, 2 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0, 0, 3 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM), 0, 0, 4 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8), 0, 0, 5 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4), 0, 0, 6 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422), 0, 0, 7 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485), 0, 0, 8 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485), 0, 0, 9 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8), 0, 0, 10 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4), 0, 0, 11 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45), 0, 0, 12 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45), 0, 0, 13 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4), 0, 0, 14 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422), 0, 0, 15 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8), 0, 0, 16 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422), 0, 0, 17 },
- { 0, }
+ {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9),
+ .driver_data = 0,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI),
+ .driver_data = 1,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45),
+ .driver_data = 2,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI),
+ .driver_data = 3,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM),
+ .driver_data = 4,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8),
+ .driver_data = 5,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4),
+ .driver_data = 6,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422),
+ .driver_data = 7,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485),
+ .driver_data = 8,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485),
+ .driver_data = 9,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8),
+ .driver_data = 10,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4),
+ .driver_data = 11,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45),
+ .driver_data = 12,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45),
+ .driver_data = 13,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4),
+ .driver_data = 14,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422),
+ .driver_data = 15,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8),
+ .driver_data = 16,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422),
+ .driver_data = 17,
+ },
+ { }
};
MODULE_DEVICE_TABLE(pci, jsm_pci_tbl);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] serial: jsm: Use named initializers for struct pci_device_id
From: Jiri Slaby @ 2026-05-05 7:46 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Greg Kroah-Hartman,
Lukas Wunner, Dave Jiang, Giovanni Cabiddu, Kees Cook
Cc: linux-serial, linux-kernel, Markus Schneider-Pargmann
In-Reply-To: <20260505073044.2258674-2-u.kleine-koenig@baylibre.com>
On 05. 05. 26, 9:30, Uwe Kleine-König (The Capable Hub) wrote:
> Initializing structures using list initializers is harder to read than
> using named initializers. Seeing the member name is more ideomatic and
> easier to understand.
>
> Use named initializers for the driver's pci_device_id array. While at it
> also drop an explicit zero in the terminating array entry.
>
> There are no changes to the compiled result of the array; verified with
> builds for x86 and arm64.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> this is a preparing change for making struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/).
> This requires named initializers for .driver_data. But even without that
> this is a nice cleanup making the array better readable.
>
> Having said that I didn't find where .driver_data is used, so unless I
> missed something the assignments can just go away???
>
> For earlier patches of this type against other drivers I got the
> feedback to use PCI_DEVICE_DATA() but I don't like that as it mixes
> hardware properties (.vendor and .device) with driver specific software
> properties (.driver_data) and thus I prefer the explicit listing
> (involving more repetition) over the shorter variant (being more opaque
> and harder to read).
>
> Best regards
> Uwe
>
> drivers/tty/serial/jsm/jsm_driver.c | 75 +++++++++++++++++++++--------
> 1 file changed, 56 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
> index 4b73e51f83fb..422cac8d8d71 100644
> --- a/drivers/tty/serial/jsm/jsm_driver.c
> +++ b/drivers/tty/serial/jsm/jsm_driver.c
> @@ -296,25 +296,62 @@ static void jsm_remove_one(struct pci_dev *pdev)
> }
>
> static const struct pci_device_id jsm_pci_tbl[] = {
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9), 0, 0, 0 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI), 0, 0, 1 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45), 0, 0, 2 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0, 0, 3 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM), 0, 0, 4 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8), 0, 0, 5 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4), 0, 0, 6 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422), 0, 0, 7 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485), 0, 0, 8 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485), 0, 0, 9 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8), 0, 0, 10 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4), 0, 0, 11 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45), 0, 0, 12 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45), 0, 0, 13 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4), 0, 0, 14 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422), 0, 0, 15 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8), 0, 0, 16 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422), 0, 0, 17 },
> - { 0, }
> + {
> + PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9),
> + .driver_data = 0,
> + }, {
Sorry, but this is definitely NOT "making the array better readable".
Esp. due to the split to multiple lines. PCI_DEVICE_DATA() would be far
better IMO. Or PCI_VDEVICE() + .driver_data on a single line...
Anyway, you're right, pci_device_id is not currently used at all.
Instead, there are big switches in the probe doing the casing. This
should be rewritten to actually use driver_data and drop the whole
switch-case stuff from probe.
So you can likely drop driver_data completely for now. It won't/can't be
used in the current form anyway.
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH v2] serial: jsm: Drop unused driver_data assigment and redundant zeros
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-05 8:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Lukas Wunner, Dave Jiang,
Giovanni Cabiddu, Kees Cook
Cc: linux-serial, linux-kernel, Markus Schneider-Pargmann
The driver doesn't use the driver_data field, so drop the assigment
together with the then redundant zero assigment for .class and
.class_mask. Also drop the zero in the list terminator.
While at it also use PCI_VDEVICE() to allow dropping "PCI_VENDOR_ID_".
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
(implicit) v1 is available at
https://lore.kernel.org/linux-serial/20260505073044.2258674-2-u.kleine-koenig@baylibre.com
.
In the v1 discussion I mentioned that I don't spot a usage of
.driver_data and Jiri confirmed these are unused. So this v2 just drops
the respective assignments and thus circumvents the subjective
discussion if my v1 really made the array better readable. Also the
usage of PCI_VDEVICE() is new.
Best regards
Uwe
drivers/tty/serial/jsm/jsm_driver.c | 38 ++++++++++++++---------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
index 4b73e51f83fb..8cd9b981bf20 100644
--- a/drivers/tty/serial/jsm/jsm_driver.c
+++ b/drivers/tty/serial/jsm/jsm_driver.c
@@ -296,25 +296,25 @@ static void jsm_remove_one(struct pci_dev *pdev)
}
static const struct pci_device_id jsm_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9), 0, 0, 0 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI), 0, 0, 1 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45), 0, 0, 2 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0, 0, 3 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM), 0, 0, 4 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8), 0, 0, 5 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4), 0, 0, 6 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422), 0, 0, 7 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485), 0, 0, 8 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485), 0, 0, 9 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8), 0, 0, 10 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4), 0, 0, 11 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45), 0, 0, 12 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45), 0, 0, 13 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4), 0, 0, 14 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422), 0, 0, 15 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8), 0, 0, 16 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422), 0, 0, 17 },
- { 0, }
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2DB9) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2DB9PRI) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2RJ45) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_4_IBM) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_DIGI_NEO_8) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_4) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_1_422) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_1_422_485) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2_422_485) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_8) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_4) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_4RJ45) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_8RJ45) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_4) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_4_422) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_8) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_8_422) },
+ { }
};
MODULE_DEVICE_TABLE(pci, jsm_pci_tbl);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 13/15] serial: 8250_mxpcie: add break support for RS485 using MUEx50 features
From: Andy Shevchenko @ 2026-05-05 9:25 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-14-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:51 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> On MUEx50, break signaling under RS485 requires a driver-specific
> sequence and cannot be handled correctly by the generic 8250 break
> implementation alone.
>
> Implement a mxpcie break_ctl callback that performs MUEx50-specific
> break handling when RS485 is enabled and fall back to the default 8250
> break handling for other modes.
...
> + uart_port_lock_irqsave(port, &flags);
guard()() ?
> +
> + if (break_state == -1) {
> + serial_out(up, UART_LCR, up->lcr | UART_LCR_DLAB);
> + serial_out(up, UART_DLL, 0);
> + serial_out(up, UART_DLM, 0);
> + serial_out(up, UART_LCR, up->lcr);
Don't we have a helper doing this?
serial_dl_write()
> + serial_out(up, MOXA_PUART_TX_FIFO_MEM, tx_byte);
> +
> + sfr = serial_in(up, MOXA_PUART_SFR);
> + serial_out(up, MOXA_PUART_SFR, sfr | MOXA_PUART_SFR_FORCE_TX);
> +
> + up->lcr |= UART_LCR_SBC;
> + serial_out(up, UART_LCR, up->lcr);
> + } else {
> + up->lcr &= ~UART_LCR_SBC;
> + serial_out(up, UART_LCR, up->lcr);
> +
> + sfr = serial_in(up, MOXA_PUART_SFR);
> + serial_out(up, MOXA_PUART_SFR, sfr &= ~MOXA_PUART_SFR_FORCE_TX);
> +
> + serial_out(up, UART_FCR, UART_FCR_CLEAR_XMIT);
> +
> + baud = tty_get_baud_rate(tty);
> + quot = uart_get_divisor(port, baud);
> + serial8250_do_set_divisor(port, baud, quot);
> + serial_out(up, UART_LCR, up->lcr);
> + }
> + uart_port_unlock_irqrestore(port, flags);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 14/15] serial: 8250: allow UART drivers to override rx_trig_bytes handling
From: Andy Shevchenko @ 2026-05-05 9:30 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-15-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:51 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> The rx_trig_bytes sysfs attribute currently relies on 8250-internal
> helper functions and assumes a fixed mapping between trigger levels and
> FIFO behavior.
>
> Some UARTs provide hardware-specific RX trigger mechanisms that do not
> fit this model. Add optional uart_port callbacks for setting and getting
> the RX trigger level, and use them when provided, while preserving the
> existing 8250 helpers as the default fallback.
...
> struct uart_port {
> void (*pm)(struct uart_port *, unsigned int state,
> unsigned int old);
> void (*handle_break)(struct uart_port *);
> + int (*set_rxtrig)(struct uart_port *port, unsigned char bytes);
> + int (*get_rxtrig)(struct uart_port *port);
Seems to me a suboptimal location for these. Why not moving up to be
closer to other getter/setter pairs?
> int (*rs485_config)(struct uart_port *,
> struct ktermios *termios,
> struct serial_rs485 *rs485);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 15/15] serial: 8250_mxpcie: implement rx_trig_bytes callbacks via MUEx50 RTL
From: Andy Shevchenko @ 2026-05-05 9:34 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-16-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:51 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> The MUEx50 UART exposes a programmable RX trigger level via the RTL
> register.
>
> Implement uart_port RX trigger set/get callbacks for the mxpcie driver
> and wire them up to the generic rx_trig_bytes sysfs interface. Store the
> configured trigger level in the per-port private data.
...
> struct mxpcie8250_port {
> int line;
> + u8 rx_trig_level;
> unsigned long event_flags;
> struct uart_port *port;
> struct work_struct work;
Whenever you add a member to or modify existing data structure, always
run `pahole` to check if the layout is good enough (or even the best
fit). Same applies to the whole series.
...
> +static int mxpcie8250_set_rxtrig(struct uart_port *port, unsigned char bytes)
> +{
> + struct mxpcie8250 *priv = dev_get_drvdata(port->dev);
> + struct uart_8250_port *up = up_to_u8250p(port);
> +
> + if (bytes > 128)
Magic! Should it be defined or already has been?
> + return -EINVAL;
> +
> + serial_out(up, MOXA_PUART_RTL, bytes);
> + priv->port[port->port_id].rx_trig_level = bytes;
> +
> + return 0;
> +}
...
> +static int mxpcie8250_get_rxtrig(struct uart_port *port)
> +{
> + struct uart_8250_port *up = up_to_u8250p(port);
> +
> + return serial_in(up, MOXA_PUART_RTL);
No need to have an intermediate pointer as you can simply use
serial_port_in(). Same applies to other places when the uart_8250_port
is not used otherwise.
> +}
...
> + priv->port[i].rx_trig_level = 96;
As per above, this magic together with the above should be defined
somehow. And together they make more context to the reader.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 5/6] ARM: dts: zte: Add D-Link DWR-932M support
From: Linus Walleij @ 2026-05-05 9:53 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260429-send-v7-5-b432e00d2db8@gmail.com>
On Wed, Apr 29, 2026 at 9:14 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> This adds base DT definition for zx297520v3 and one board that consumes it.
>
> The stock kernel does not use the armv7 timer, but it seems to work
> fine. The board has other board-specific timers that would need a driver
> and I see no reason to bother with them since the arm standard timer
> works.
>
> The caveat is the non-standard GIC setup needed to handle the timer's
> level-low PPI. This is the responsibility of the boot loader and
> documented in Documentation/arch/arm/zte/zx297520v3.rst.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox