mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alon Ziv <alon@nolaviz.org>
To: Johan Hovold <jhovold@gmail.com>
Cc: Alon Ziv <alon+git@nolaviz.org>,
	linux-usb@vger.kernel.org, Greg Kroah-Hartman <gregkh@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] opticon: use generic code where possible
Date: Mon, 25 Oct 2010 21:48:50 +0200	[thread overview]
Message-ID: <4CC5DF22.6020203@nolaviz.org> (raw)
In-Reply-To: <20101025111126.GA4046@localhost>

Hi Johan,


Thanks for the review.

Please see my replies below.


On 10/25/2010 01:11 PM, Johan Hovold wrote:

>>  
>>  /* max number of write urbs in flight */
>>  #define URB_UPPER_LIMIT	4
>
> This one is no longer needed.
>
Removed.
>
> [...]
>
> Here it seems you're turning write into a blocking function if you have
> no bulk-out end-point. I'm not sure that is desired.
>

Right...
I considered doing it differently (which would require more code--I
would need to track the outstanding control URBs, and would need a
callback to free the kmalloc()ed setup packet). In the end, I left it as
blocking because the actual protocol used by the OPN2001 is very light
on writes (in fact, it never writes anything without waiting for a
response, and its longest outgoing message is
limited to 70 bytes).

>>  }
>>  
>>  static int opticon_write_room(struct tty_struct *tty)
>>  {
>>  	struct usb_serial_port *port = tty->driver_data;
>> -	struct opticon_private *priv = usb_get_serial_data(port->serial);
>> -	unsigned long flags;
>> -
>> -	dbg("%s - port %d", __func__, port->number);
>> -
>> -	/*
>> -	 * We really can take almost anything the user throws at us
>> -	 * but let's pick a nice big number to tell the tty
>> -	 * layer that we have lots of free space, unless we don't.
>> -	 */
>> -	spin_lock_irqsave(&priv->lock, flags);
>> -	if (priv->outstanding_urbs > URB_UPPER_LIMIT * 2 / 3) {
>> -		spin_unlock_irqrestore(&priv->lock, flags);
>> -		dbg("%s - write limit hit", __func__);
>> -		return 0;
>> -	}
>> -	spin_unlock_irqrestore(&priv->lock, flags);
>> -
>> -	return 2048;
>> +	if (port->bulk_out_endpointAddress)
>> +		return usb_serial_generic_write_room(tty);
>> +	else
>> +		return 64;
>
> Why limit to 64b in the no-bulk-out case when driver used to report and
> use 2048b (which matches tty-layers partitioning)?
>
Good question, actually...
(I remembered a control packet cannot transfer more than 64B, but my
memory was wrong)
 
>>  }
>>  
>>  static void opticon_throttle(struct tty_struct *tty)
>>  {
>> -	struct usb_serial_port *port = tty->driver_data;
>> -	struct opticon_private *priv = usb_get_serial_data(port->serial);
>> -	unsigned long flags;
>> -
>> -	dbg("%s - port %d", __func__, port->number);
>> -	spin_lock_irqsave(&priv->lock, flags);
>> -	priv->throttled = true;
>> -	spin_unlock_irqrestore(&priv->lock, flags);
>> +	usb_serial_generic_throttle(tty);
>>  }
>
> You should remove this function and set the throttle field to
> usb_serial_generic_throttle in opticon_device instead.
>
Will do.
>>  static void opticon_unthrottle(struct tty_struct *tty)
>>  {
>> -	struct usb_serial_port *port = tty->driver_data;
>> -	struct opticon_private *priv = usb_get_serial_data(port->serial);
>> -	unsigned long flags;
>> -	int result, was_throttled;
>> -
>> -	dbg("%s - port %d", __func__, port->number);
>> -
>> -	spin_lock_irqsave(&priv->lock, flags);
>> -	priv->throttled = false;
>> -	was_throttled = priv->actually_throttled;
>> -	priv->actually_throttled = false;
>> -	spin_unlock_irqrestore(&priv->lock, flags);
>> -
>> -	priv->bulk_read_urb->dev = port->serial->dev;
>> -	if (was_throttled) {
>> -		result = usb_submit_urb(priv->bulk_read_urb, GFP_ATOMIC);
>> -		if (result)
>> -			dev_err(&port->dev,
>> -				"%s - failed submitting read urb, error %d\n",
>> -							__func__, result);
>> -	}
>> +	usb_serial_generic_unthrottle(tty);
>>  }
>
> You should remove this function and set the unthrottle field in
> opticon_device instead.
>   
Ditto.

>>  static int opticon_tiocmget(struct tty_struct *tty, struct file *file)
>>  {
>>  	struct usb_serial_port *port = tty->driver_data;
>>  	struct opticon_private *priv = usb_get_serial_data(port->serial);
>> -	unsigned long flags;
>>  	int result = 0;
>>  
>>  	dbg("%s - port %d", __func__, port->number);
>>  
>> -	spin_lock_irqsave(&priv->lock, flags);
>>  	if (priv->rts)
>>  		result = TIOCM_RTS;
>> -	spin_unlock_irqrestore(&priv->lock, flags);
>>  
>>  	dbg("%s - %x", __func__, result);
>>  	return result;
>>  }
>
> Locking no longer needed?
>
It was never really there...
The old code used to set rts without the lock, and only read with the
lock--quite meaningless. And since there is only a single writer and a
single reader (and the data type is inherently atomic), I see no reason
for locking.
>
>>  
>>  static struct usb_serial_driver opticon_device = {
>> @@ -545,16 +223,15 @@ static struct usb_serial_driver opticon_device = {
>>  		.name =		"opticon",
>>  	},
>>  	.id_table =		id_table,
>> -	.usb_driver = 		&opticon_driver,
>> +	.usb_driver =		&opticon_driver,
>>  	.num_ports =		1,
>> -	.attach =		opticon_startup,
>> -	.open =			opticon_open,
>> -	.close =		opticon_close,
>> +	.bulk_out_size =	1024,
>
> This is a fairly large value. Have you made any benchmarking to
> determine it? 256b have otherwise proven to be a good trade-off value
> for several drivers. (In particular, having a too large buffer size
> implied a great penalty on some embedded system I used for
> benchmarking.)
>
Actually--no, I did not benchmark. I just looked at various other
drivers, saw the numbers are all over the map, and pulled a number out
of my (metaphorical) hat.
And anyway--the actual device I am using (OPN2001) does not use the
bulk-out at all.
So I'll change to 256, but I still won't be able to prove it right (or
wrong).

Thanks again,
-az

  reply	other threads:[~2010-10-25 19:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-23 18:43 [PATCH v2 0/2] Further cleanups to opticon driver Alon Ziv
2010-10-23 18:43 ` [PATCH v2 1/2] Export usb_serial_generic_write_room for use in modules Alon Ziv
2010-10-25 11:20   ` Johan Hovold
2010-10-25 19:57     ` Alon Ziv
2010-10-25 22:40       ` Johan Hovold
2010-10-23 18:43 ` [PATCH v2 2/2] opticon: use generic code where possible Alon Ziv
2010-10-25 11:11   ` Johan Hovold
2010-10-25 19:48     ` Alon Ziv [this message]
2010-11-11 16:23       ` Johan Hovold
2010-11-11 13:43 ` [PATCH v2 0/2] Further cleanups to opticon driver Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CC5DF22.6020203@nolaviz.org \
    --to=alon@nolaviz.org \
    --cc=alon+git@nolaviz.org \
    --cc=gregkh@suse.de \
    --cc=jhovold@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome