Re: [PATCH 0/3] USB-Serial serdev support

[Johan Hovold <johan@kernel.org>]

On Fri, Oct 24, 2025 at 02:40:47PM +0200, Marco Felsch wrote:
> On 25-10-24, Johan Hovold wrote:
> > On Fri, Oct 24, 2025 at 11:27:38AM +0200, Marco Felsch wrote:
> > > On 25-10-24, Johan Hovold wrote:
> > > > On Thu, Oct 23, 2025 at 03:48:28PM +0200, Marco Felsch wrote:
> > > > > On 25-10-23, Johan Hovold wrote:
> > > > > > On Thu, Mar 13, 2025 at 08:40:44PM +0100, Marco Felsch wrote:
> > > > > > > On 25-03-11, Johan Hovold wrote:
> > > > > > > > On Tue, Sep 17, 2024 at 06:49:48AM +0200, Marco Felsch wrote:
> > > > > > > > > On 24-09-09, Johan Hovold wrote:
> > 
> > > > It's still one of the issues that need to addressed.
> > > 
> > > Yes but this shouldn't be an issue with this patchset. So far the
> > > smallest DT-describale USB entities are the interfaces.
> > 
> > It is an issue with this patchset since any binding for USB serdev will
> > need to take both kind of devices into account. Period.
> 
> Sorry but I really don't see the issue. As of now DT abstractions
> supports all my use-cases. If $another_developer has an USB device which
> actually exposes multiple serial ports behind a single usb-interface,
> fine. But in that case $another_developer needs to add the
> support/extend the support for it if he wants to use it in combination
> with serdev.

Fine, but if you only care about your use case then you can keep your
implementation out-of-tree until someone comes with along with enough
time to solve this properly.

> > > > > > You will also see the following kind of warnings in the logs:
> > > > > > 
> > > > > > ttyUSB ttyUSB0: tty_hangup: tty->count(1) != (#fd's(0) + #kopen's(0))
> > > > > > ttyUSB ttyUSB0: tty_port_close_start: tty->count = 1 port count = 0
> > > > > > 
> > > > > > which are due to the fact that serdev does not support hangups which are
> > > > > > used during teardown of USB serial ports.

> > You should see it in your test setup as well. Unless the bluetooth
> > driver you use is doing something funky (e.g. not closing the port).
> > 
> > I'm testing with a mock gnss device here.
> 
> Okay, let me test this. Just that we're on the same page: The test is to
> remove the serdev (bluetooth, gnss, ...) driver, right?

No, trigger a disconnect like you did before, or do a physical
disconnect, by wiring up a regular USB port.
 
> > > > Also, that commit message needs to more work since you don't really
> > > > motivate why you think it's needed (e.g. as serdev ports can't be shared
> > > > with user space).

> > No, my point was that serdev devices *are* not shared with user space,
> > you don't need to use that new kopen helper for that.

> > That helper sets the new TTY_PORT_KOPENED flag which suppresses the
> > warning on hangups.
> 
> Okay, so you meant the TTY_PORT_KOPENED flag. According the
> documentation of tty_kopen_exclusive():
> 
> | tty_kopen_exclusive - open a tty device for kernel
> 
> isn't that exactly what serdev-ttyport should do to "not share it with
> user space"? IMHO it's an implementation detail if the logic behind
> "open a tty device for kernel" is only built around a flag to suppress
> the warning.

I give up. I've already told you that serdev does not share anything
with user space.

Johan