2020-10-14 17:41:06

by Alan Stern

[permalink] [raw]
Subject: Re: [patch 03/12] USB: serial: keyspan_pda: Consolidate room query

On Wed, Oct 14, 2020 at 04:52:18PM +0200, Thomas Gleixner wrote:
> From: Sebastian Andrzej Siewior <[email protected]>
>
> Having two copies of the same code doesn't make the code more readable and
> allocating a buffer of 1 byte for a synchronous operation is a pointless
> exercise.

Not so. In fact, it is required, because a portion of a structure
cannot be mapped for DMA unless it is aligned at a cache line boundary.

> Add a byte buffer to struct keyspan_pda_private which can be used
> instead. The buffer is only used in open() and tty->write().

This won't work.

> Console writes
> are not calling into the query. open() obviously happens before write() and
> the writes are serialized by bit 0 of port->write_urbs_free which protects
> also the transaction itself.
>
> Move the actual query into a helper function and cleanup the usage sites in
> keyspan_pda_write() and keyspan_pda_open().
>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Cc: Johan Hovold <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: [email protected]
> ---
> drivers/usb/serial/keyspan_pda.c | 102 ++++++++++++++++-----------------------
> 1 file changed, 43 insertions(+), 59 deletions(-)
>
> --- a/drivers/usb/serial/keyspan_pda.c
> +++ b/drivers/usb/serial/keyspan_pda.c
> @@ -47,6 +47,7 @@ struct keyspan_pda_private {
> struct work_struct unthrottle_work;
> struct usb_serial *serial;
> struct usb_serial_port *port;
> + u8 query_buf;
> };
>
>
> @@ -436,6 +437,31 @@ static int keyspan_pda_tiocmset(struct t
> return rc;
> }
>
> +/*
> + * Using priv->query_buf is safe here because this is only called for TTY
> + * operations open() and write(). write() comes post open() obviously and
> + * write() itself is serialized via bit 0 of port->write_urbs_free. Console
> + * writes are never calling into this.
> + */
> +static int keyspan_pda_query_room(struct usb_serial *serial,
> + struct keyspan_pda_private *priv)
> +{
> + int res;
> +
> + res = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
> + 6, /* write_room */
> + USB_TYPE_VENDOR | USB_RECIP_INTERFACE | USB_DIR_IN,
> + 0, /* value */
> + 0, /* index */
> + &priv->query_buf,
> + 1,
> + 2000);

Instead, consider using the new usb_control_msg_recv() API. But it
might be better to allocate the buffer once and for all.

Alan Stern


2020-10-14 17:41:15

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [patch 03/12] USB: serial: keyspan_pda: Consolidate room query

On Wed, Oct 14 2020 at 12:14, Alan Stern wrote:
> On Wed, Oct 14, 2020 at 04:52:18PM +0200, Thomas Gleixner wrote:
>> From: Sebastian Andrzej Siewior <[email protected]>
>>
>> Having two copies of the same code doesn't make the code more readable and
>> allocating a buffer of 1 byte for a synchronous operation is a pointless
>> exercise.
>
> Not so. In fact, it is required, because a portion of a structure
> cannot be mapped for DMA unless it is aligned at a cache line boundary.
>
>> Add a byte buffer to struct keyspan_pda_private which can be used
>> instead. The buffer is only used in open() and tty->write().
>
> This won't work.

Ok.

>> + res = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
>> + 6, /* write_room */
>> + USB_TYPE_VENDOR | USB_RECIP_INTERFACE | USB_DIR_IN,
>> + 0, /* value */
>> + 0, /* index */
>> + &priv->query_buf,
>> + 1,
>> + 2000);
>
> Instead, consider using the new usb_control_msg_recv() API. But it
> might be better to allocate the buffer once and for all.

Let me have a look.

Thanks,

tglx

Subject: Re: [patch 03/12] USB: serial: keyspan_pda: Consolidate room query

On 2020-10-14 12:14:33 [-0400], Alan Stern wrote:
> Instead, consider using the new usb_control_msg_recv() API. But it
> might be better to allocate the buffer once and for all.

This will still allocate and free buffer on each invocation. What about
moving the query_buf to the begin of the struct / align it?

> Alan Stern

Sebastian