Re: ttyACM versus ttyUSB

[Greg KH <gregkh@linuxfoundation.org>]

On Sun, Oct 12, 2025 at 01:01:00PM -0600, Alex Henrie wrote:
> On Sun, Oct 12, 2025 at 10:21 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sun, Oct 12, 2025 at 09:55:27AM -0600, Alex Henrie wrote:
> > > On Sun, Oct 12, 2025 at 12:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Sat, Oct 11, 2025 at 11:00:00PM -0600, Alex Henrie wrote:
> > > > > Dear kernel developers,
> > > > >
> > > > > I am very curious and I haven't been able to find a definitive answer
> > > > > anywhere: Why is the cdc-acm driver separate from the general
> > > > > usbserial driver? There are lots of drivers that use usbserial, each
> > > > > with its own unique protocol. What makes ACM so special that it needs
> > > > > to be separated out as /dev/ttyACM* instead of going with everything
> > > > > else in /dev/ttyUSB*?
> > > > >
> > > > > I can think of several possible reasons, but I'd really like to know
> > > > > what reasons matter to the kernel architects/maintainers.
> > > >
> > > > cdc-acm implements the USB specification for that protocol, which is
> > > > defined by the USB group.  All of the usb-serial drivers do NOT follow
> > > > that protocol and use their own vendor-specific ways of talking to the
> > > > device.
> > >
> > > OK, so it's just a matter of policy that drivers for standard USB
> > > protocols name the device nodes differently than drivers for
> > > vendor-defined USB protocols do?
> >
> > These drivers are decades old, originally written in 1999 and handled
> > different hardware types so they got different device nodes.  Just like
> > many different serial drivers today have different named device nodes,
> > it was just following that well-known practice at the time.
> >
> > And that practice continues today, when people write new serial/tty
> > drivers, they usually name the device nodes something new, much to many
> > of us arguing that maybe they shouldn't do that and they should learn
> > from our past history :)
> >
> > Also, cdc-acm does not support as wide of a range of devices as the
> > usb-serial driver does, which can handle multiple-port devices and full
> > hardware line controls, which cdc-acm can not as it's not part of the
> > spec for that protocol.
> >
> > There was a time that cdc-acm almost did not become a specification due
> > to internal arguments at USB-IF, which is why the usb-serial devices all
> > were using custom vendor protocols first, before cdc-acm eventually got
> > ratified.
> 
> Ah, so the name ttyACM is a historical accident, from the time when it
> was the norm to use different device node names in different serial
> drivers.

It wasn't an "accident", it was on purpose at the time.

> I did notice that the ACM protocol has no way to set the baud rate or
> read the CTS line and I wondered if those limitations were the reason
> for keeping its driver separate. Today there are ttyUSB drivers that
> likewise have limitations on the baud rate and the flow control lines
> (some are even based on ACM), but they weren't around in 1999, so I
> can see how the difference in capabilities would have been another
> motivation for the difference in naming conventions.

Yes, baud rate and line control is important for the usb-serial devices
that were real serial ports.  The ACM protocol did not want to implement
those for various reasons best discussed over your favorite beverage :)

thanks,

greg k-h