TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.
The xmit_fifo_size parameter could be used to set the hardware transmit
fifo size of a legacy UART when it could not be detected, but the
interface is limited to eight bits and should be left unset when it is
not used.
Similarly, baud_base could be used to set the uart base clock when it
could not be detected, but might as well be left unset when it is not
known.
Fix the cdc-acm TIOCGSERIAL implementation by dropping its custom
interpretation of the unused xmit_fifo_size and baud_base fields, which
overflowed the former with the URB buffer size and set the latter to the
current line speed. Also return the port line number, which is the only
other value used besides the close parameters.
Fixes: 18c75720e667 ("USB: allow users to run setserial with cdc-acm")
Signed-off-by: Johan Hovold <[email protected]>
---
drivers/usb/class/cdc-acm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 43e31dad4831..b74713518b3a 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -929,8 +929,7 @@ static int get_serial_info(struct tty_struct *tty, struct serial_struct *ss)
{
struct acm *acm = tty->driver_data;
- ss->xmit_fifo_size = acm->writesize;
- ss->baud_base = le32_to_cpu(acm->line.dwDTERate);
+ ss->line = acm->minor;
ss->close_delay = jiffies_to_msecs(acm->port.close_delay) / 10;
ss->closing_wait = acm->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ?
ASYNC_CLOSING_WAIT_NONE :
--
2.26.3
Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
> serial devices is only useful for setting the close_delay and
> closing_wait parameters.
>
> The xmit_fifo_size parameter could be used to set the hardware transmit
> fifo size of a legacy UART when it could not be detected, but the
> interface is limited to eight bits and should be left unset when it is
> not used.
OK.
> Similarly, baud_base could be used to set the uart base clock when it
> could not be detected, but might as well be left unset when it is not
> known.
Well, the devices report it. It is part of the standard.
> Fix the cdc-acm TIOCGSERIAL implementation by dropping its custom
> interpretation of the unused xmit_fifo_size and baud_base fields, which
> overflowed the former with the URB buffer size and set the latter to the
> current line speed. Also return the port line number, which is the only
> other value used besides the close parameters.
>
> Fixes: 18c75720e667 ("USB: allow users to run setserial with cdc-acm")
> Signed-off-by: Johan Hovold <[email protected]>
> ---
> drivers/usb/class/cdc-acm.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 43e31dad4831..b74713518b3a 100644
> --- a/drivers/usb/class/cdc-acm.c
> +++ b/drivers/usb/class/cdc-acm.c
> @@ -929,8 +929,7 @@ static int get_serial_info(struct tty_struct *tty, struct serial_struct *ss)
> {
> struct acm *acm = tty->driver_data;
>
> - ss->xmit_fifo_size = acm->writesize;
> - ss->baud_base = le32_to_cpu(acm->line.dwDTERate);
If we do this, we have a value that can be set, but is not reported.
That looks a bit strange to me.
Regards
Oliver
On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
> > serial devices is only useful for setting the close_delay and
> > closing_wait parameters.
> >
> > The xmit_fifo_size parameter could be used to set the hardware transmit
> > fifo size of a legacy UART when it could not be detected, but the
> > interface is limited to eight bits and should be left unset when it is
> > not used.
>
> OK.
>
> > Similarly, baud_base could be used to set the uart base clock when it
> > could not be detected, but might as well be left unset when it is not
> > known.
>
> Well, the devices report it. It is part of the standard.
No, the standard doesn't include anything about a baud-base clock
AFAICT.
> > Fix the cdc-acm TIOCGSERIAL implementation by dropping its custom
> > interpretation of the unused xmit_fifo_size and baud_base fields, which
> > overflowed the former with the URB buffer size and set the latter to the
> > current line speed. Also return the port line number, which is the only
> > other value used besides the close parameters.
> >
> > Fixes: 18c75720e667 ("USB: allow users to run setserial with cdc-acm")
> > Signed-off-by: Johan Hovold <[email protected]>
> > ---
> > drivers/usb/class/cdc-acm.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> > index 43e31dad4831..b74713518b3a 100644
> > --- a/drivers/usb/class/cdc-acm.c
> > +++ b/drivers/usb/class/cdc-acm.c
> > @@ -929,8 +929,7 @@ static int get_serial_info(struct tty_struct *tty, struct serial_struct *ss)
> > {
> > struct acm *acm = tty->driver_data;
> >
> > - ss->xmit_fifo_size = acm->writesize;
> > - ss->baud_base = le32_to_cpu(acm->line.dwDTERate);
>
> If we do this, we have a value that can be set, but is not reported.
> That looks a bit strange to me.
Again, no, the baud_base cannot be set and it is unknown and unused.
The only reason to report back baud_base is to support the deprecated
ASYNC_SPD_CUST interface used to set a custom divisor. cdc-acm has never
supported that for obvious reasons.
Johan
Am Donnerstag, den 08.04.2021, 11:48 +0200 schrieb Johan Hovold:
> On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > Well, the devices report it. It is part of the standard.
>
> No, the standard doesn't include anything about a baud-base clock
> AFAICT.
Unfortunately it does.
dwDTERate - chapter 6.3.11 - table 17
If we does this wrongly, we should certainly fix it, but just removing
the reporting doesn't look right to me.
Regards
Oliver
On Thu, Apr 08, 2021 at 01:34:12PM +0200, Oliver Neukum wrote:
> Am Donnerstag, den 08.04.2021, 11:48 +0200 schrieb Johan Hovold:
> > On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> > > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
>
> > > Well, the devices report it. It is part of the standard.
> >
> > No, the standard doesn't include anything about a baud-base clock
> > AFAICT.
>
> Unfortunately it does.
> dwDTERate - chapter 6.3.11 - table 17
That's not the base clock rate, that's just the currently configured
line speed which you can read from termios.
> If we does this wrongly, we should certainly fix it, but just removing
> the reporting doesn't look right to me.
The driver got its interpretation of baud_base wrong, and CDC doesn't
even have a concept of base clock rate so removing it is the right thing
to do.
Again, baud_base is really only relevant with legacy UARTs and when
using the deprecated ASYNC_SPD_CUST.
And if the user wants to knows the current line speed we have a
different interface for that.
Johan
Am Donnerstag, den 08.04.2021, 13:54 +0200 schrieb Johan Hovold:
> On Thu, Apr 08, 2021 at 01:34:12PM +0200, Oliver Neukum wrote:
> > Am Donnerstag, den 08.04.2021, 11:48 +0200 schrieb Johan Hovold:
> > > On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> > > > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > > > Well, the devices report it. It is part of the standard.
> > >
> > > No, the standard doesn't include anything about a baud-base clock
> > > AFAICT.
> >
> > Unfortunately it does.
> > dwDTERate - chapter 6.3.11 - table 17
>
> That's not the base clock rate, that's just the currently configured
> line speed which you can read from termios
> > If we does this wrongly, we should certainly fix it, but just removing
> > the reporting doesn't look right to me.
>
> The driver got its interpretation of baud_base wrong, and CDC doesn't
> even have a concept of base clock rate so removing it is the right thing
> to do.
>
> Again, baud_base is really only relevant with legacy UARTs and when
> using the deprecated ASYNC_SPD_CUST.
>
> And if the user wants to knows the current line speed we have a
> different interface for that.
Hi,
thank you, that clarifies things. I am happy with the patch itself,
but could I ask you to do two things:
1. Edit the commit description
making clear that the difference
between the base clock rate and the line speed.
2. Mark the patch specially to NOT be included in stable. We may
have
users misusing the current API.
Regards
Oliver
On Thu, Apr 08, 2021 at 01:59:43PM +0200, Oliver Neukum wrote:
> Am Donnerstag, den 08.04.2021, 13:54 +0200 schrieb Johan Hovold:
> > On Thu, Apr 08, 2021 at 01:34:12PM +0200, Oliver Neukum wrote:
> > > Am Donnerstag, den 08.04.2021, 11:48 +0200 schrieb Johan Hovold:
> > > > On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> > > > > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > > > > Well, the devices report it. It is part of the standard.
> > > >
> > > > No, the standard doesn't include anything about a baud-base clock
> > > > AFAICT.
> > >
> > > Unfortunately it does.
> > > dwDTERate - chapter 6.3.11 - table 17
> >
> > That's not the base clock rate, that's just the currently configured
> > line speed which you can read from termios
> > > If we does this wrongly, we should certainly fix it, but just removing
> > > the reporting doesn't look right to me.
> >
> > The driver got its interpretation of baud_base wrong, and CDC doesn't
> > even have a concept of base clock rate so removing it is the right thing
> > to do.
> >
> > Again, baud_base is really only relevant with legacy UARTs and when
> > using the deprecated ASYNC_SPD_CUST.
> >
> > And if the user wants to knows the current line speed we have a
> > different interface for that.
>
> Hi,
>
> thank you, that clarifies things. I am happy with the patch itself,
> but could I ask you to do two things:
>
> 1. Edit the commit description
> making clear that the difference
> between the base clock rate and the line speed.
>
> 2. Mark the patch specially to NOT be included in stable. We may
> have
> users misusing the current API.
That doesn't matter, if there are misusers then their use will "break"
on newer kernels. And if so, then it doesn't deserve to be in any
release.
If a change is good enough for Linus's tree, that means it is good
enough for a stable tree, the requirements are exactly the same when it
comes to userspace interactions.
thanks,
greg k-h