Use tty_port_register_device_serdev() to allow attaching serdev
devices to USB serial ports. Also set the ACPI companion device on the
USB serial device to let the serdev matching work on ACPI systems.

Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
---
 drivers/usb/serial/bus.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c
index 9e2a18c0b2183..0b0a5ea1ba5aa 100644
--- a/drivers/usb/serial/bus.c
+++ b/drivers/usb/serial/bus.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/acpi.h>
 #include <linux/errno.h>
 #include <linux/tty.h>
 #include <linux/slab.h>
@@ -49,9 +50,13 @@ static int usb_serial_device_probe(struct device *dev)
 			goto err_autopm_put;
 	}
 
+	ACPI_COMPANION_SET(dev, ACPI_COMPANION(&port->serial->dev->dev));
+
 	minor = port->minor;
-	tty_dev = tty_port_register_device(&port->port, usb_serial_tty_driver,
-					   minor, dev);
+	tty_dev = tty_port_register_device_serdev(&port->port,
+						  usb_serial_tty_driver,
+						  minor, dev,
+						  &port->serial->dev->dev);
 	if (IS_ERR(tty_dev)) {
 		retval = PTR_ERR(tty_dev);
 		goto err_port_remove;
-- 
2.39.5

On Thu, Sep 17, 2026 at 10:11:03AM +0200, Alban Bedel wrote:
> Use tty_port_register_device_serdev() to allow attaching serdev
> devices to USB serial ports. Also set the ACPI companion device on the
> USB serial device to let the serdev matching work on ACPI systems.

"also" should be a separate patch, right?

And I didn't think that serdev could handle devices going away at any
point in time, when did that change?  How was this all tested and what
ACPI device wants to use this?

thanks,

greg k-h

On Thu, 17 Sep 2026 09:27:42 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Thu, Sep 17, 2026 at 10:11:03AM +0200, Alban Bedel wrote:
> > Use tty_port_register_device_serdev() to allow attaching serdev
> > devices to USB serial ports. Also set the ACPI companion device on the
> > USB serial device to let the serdev matching work on ACPI systems.  
> 
> "also" should be a separate patch, right?

Will do.

> And I didn't think that serdev could handle devices going away at any
> point in time, when did that change?  How was this all tested and what
> ACPI device wants to use this?

The use case here is an x86 embedded platform with a soldered USB serial
adapter connecting to a MAX9265 GMSL serializer. As everything is on a
single PCB there is no question of anything getting disconnected at
runtime.

But I now see that I missed that the bus remove also need to be
adjusted to use tty_port_unregister_device() instead of
tty_unregister_device().  With that done the serdev device get properly
taken down when I manually disable the port. With a small fix to the
serdev core it also comes back up when the port is enabled again.

The ACPI part is a custom DSDT overlay that defines the chain
starting from the USB port. At this level there is no difference to 
classic UART where serdev are already working.

Alban

On Thu, Sep 17, 2026 at 03:37:36PM +0200, Alban Bedel wrote:
> On Thu, 17 Sep 2026 09:27:42 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > On Thu, Sep 17, 2026 at 10:11:03AM +0200, Alban Bedel wrote:
> > > Use tty_port_register_device_serdev() to allow attaching serdev
> > > devices to USB serial ports. Also set the ACPI companion device on the
> > > USB serial device to let the serdev matching work on ACPI systems.  
> > 
> > "also" should be a separate patch, right?
> 
> Will do.
> 
> > And I didn't think that serdev could handle devices going away at any
> > point in time, when did that change?  How was this all tested and what
> > ACPI device wants to use this?
> 
> The use case here is an x86 embedded platform with a soldered USB serial
> adapter connecting to a MAX9265 GMSL serializer. As everything is on a
> single PCB there is no question of anything getting disconnected at
> runtime.

You hope :)

> But I now see that I missed that the bus remove also need to be
> adjusted to use tty_port_unregister_device() instead of
> tty_unregister_device().  With that done the serdev device get properly
> taken down when I manually disable the port. With a small fix to the
> serdev core it also comes back up when the port is enabled again.

Please read the archives for why we don't want to do this unless/until
serdev is "fixed" to properly handle dynamic device removals.

> The ACPI part is a custom DSDT overlay that defines the chain
> starting from the USB port. At this level there is no difference to 
> classic UART where serdev are already working.

So acpi now defines USB to serial devices?  Is that new?

thanks,

greg k-h

On Thu, 17 Sep 2026 15:08:11 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Thu, Sep 17, 2026 at 03:37:36PM +0200, Alban Bedel wrote:
> > On Thu, 17 Sep 2026 09:27:42 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >   
> > > On Thu, Sep 17, 2026 at 10:11:03AM +0200, Alban Bedel wrote:  
> > > > Use tty_port_register_device_serdev() to allow attaching serdev
> > > > devices to USB serial ports. Also set the ACPI companion device on the
> > > > USB serial device to let the serdev matching work on ACPI systems.    
> > > 
> > > "also" should be a separate patch, right?  
> > 
> > Will do.
> >   
> > > And I didn't think that serdev could handle devices going away at any
> > > point in time, when did that change?  How was this all tested and what
> > > ACPI device wants to use this?  
> > 
> > The use case here is an x86 embedded platform with a soldered USB serial
> > adapter connecting to a MAX9265 GMSL serializer. As everything is on a
> > single PCB there is no question of anything getting disconnected at
> > runtime.  
> 
> You hope :)

Obviously anything can fail, but I don't see why that should be treated
differently than an UART connected via PCI or LPC. The link could also
fail anytime.

> > But I now see that I missed that the bus remove also need to be
> > adjusted to use tty_port_unregister_device() instead of
> > tty_unregister_device().  With that done the serdev device get properly
> > taken down when I manually disable the port. With a small fix to the
> > serdev core it also comes back up when the port is enabled again.  
> 
> Please read the archives for why we don't want to do this unless/until
> serdev is "fixed" to properly handle dynamic device removals.

All I could find is the "USB-Serial serdev support" thread from last
year which sadly doesn't provides much details. Like Marco Felsch back
then I tested disabling/enabling the USB port and didn't have any
issue, the serdev device get removed and added back just fine. In my
case the serdev driver provides an I2C bus, all devices on it get
removed and added back again as well and work just fine.

I really fail to see an issue in pratice, would you care to explain
what I'm missing here?

> > The ACPI part is a custom DSDT overlay that defines the chain
> > starting from the USB port. At this level there is no difference to 
> > classic UART where serdev are already working.  
> 
> So acpi now defines USB to serial devices?  Is that new?

UARTSerialBusV2() is there to define devices using an UART, the
specification doesn't mention any limitation on the kind of UART it can
be pointed at. What is the issue here?

Alban

On Thu, Sep 17, 2026 at 05:21:52PM +0200, Alban Bedel wrote:
> On Thu, 17 Sep 2026 15:08:11 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> > Please read the archives for why we don't want to do this unless/until
> > serdev is "fixed" to properly handle dynamic device removals.
> 
> All I could find is the "USB-Serial serdev support" thread from last
> year which sadly doesn't provides much details. Like Marco Felsch back
> then I tested disabling/enabling the USB port and didn't have any
> issue, the serdev device get removed and added back just fine. In my
> case the serdev driver provides an I2C bus, all devices on it get
> removed and added back again as well and work just fine.
> 
> I really fail to see an issue in pratice, would you care to explain
> what I'm missing here?

Serial drivers use hangups when tearing down their ports. Serdev does
not support that so the port is shut down underneath the serdev client
while still in use, which can lead to all sorts of issues.

Johan

On Fri, 18 Sep 2026 16:56:38 +0200
Johan Hovold <johan@kernel.org> wrote:

> On Thu, Sep 17, 2026 at 05:21:52PM +0200, Alban Bedel wrote:
> > On Thu, 17 Sep 2026 15:08:11 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:  
> 
> > > Please read the archives for why we don't want to do this unless/until
> > > serdev is "fixed" to properly handle dynamic device removals.  
> > 
> > All I could find is the "USB-Serial serdev support" thread from last
> > year which sadly doesn't provides much details. Like Marco Felsch back
> > then I tested disabling/enabling the USB port and didn't have any
> > issue, the serdev device get removed and added back just fine. In my
> > case the serdev driver provides an I2C bus, all devices on it get
> > removed and added back again as well and work just fine.
> > 
> > I really fail to see an issue in pratice, would you care to explain
> > what I'm missing here?  
> 
> Serial drivers use hangups when tearing down their ports. Serdev does
> not support that so the port is shut down underneath the serdev client
> while still in use, which can lead to all sorts of issues.

Hangup from modem status are ignored because serdev set C_CLOCAL. So
that only leave the hangup sent when the USB device is disconnected.
But in this case, right after the hangup, the tty port device is
removed, which in turn remove the serdev device. At this point there no
way to comunicate with the tty anymore anyway, so I don't see what
signaling the hangup to the serdev device right before it get removed
would add.

Over the weekend I did some further test with a loopback cable and a
test serdev driver that continuously read/write on the tty. I could
disconnect and reconnect the USB device without any real issue.
check_tty_count() produce a warning because the serdev open is not
accounted for but that should be easy to fix.

One thing that I can see going wrong is if a serdev driver if waiting
on a write with a very long timeout. If the tty goes away while it is
waiting the wait is currently not interrupted which prevent the device
from being removed. But this is a more generic issue in serdev as that
could also happen by unbinding the serdev driver.

Alban