All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang YanQing <udknight@gmail.com>
To: Johan Hovold <johan@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	gregkh@linuxfoundation.org, jhovold@gmail.com, andi@lisas.de,
	dforsi@gmail.com, gnomes@lxorguk.ukuu.org.uk,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] usb:serial:pl2303: add GPIOs interface on PL2303
Date: Sun, 17 Aug 2014 09:04:32 +0800	[thread overview]
Message-ID: <20140817010432.GA2907@localhost.localdomain> (raw)
In-Reply-To: <20140812144625.GB9799@localhost>

On Tue, Aug 12, 2014 at 04:46:25PM +0200, Johan Hovold wrote:
> On Sat, Aug 09, 2014 at 01:28:28PM +0800, Wang YanQing wrote:
> > PL2303 USB Serial devices always has GPIOs,
> 
> Always? Are you sure? It's probably better to write "might have" as they
> are unlikely to be accessible even if the pins exist.
http://prolificusa.com/docs/2303/all/an_PL2303_GPIO_LED_Indicator_v1.0.pdf

"
All of the PL2303
chips aside from PL2303HXD have two dedicated GPIO pins (GP0 and GP1) while PL2303HXD have
four GPIO pins (GP0, GP1, GP2, GP3)."

> 
> >  enum pl2303_type {
> >  	TYPE_01,	/* Type 0 and 1 (difference unknown) */
> > @@ -141,11 +145,15 @@ enum pl2303_type {
> >  struct pl2303_type_data {
> >  	speed_t max_baud_rate;
> >  	unsigned long quirks;
> > +	u16 ngpio;
> 
> u8 should be enough.

Yes, but struct gpio_chip use u16, so maybe u16 is better?.

> 
> > +	int (*gpio_startup)(struct usb_serial *serial);
> > +	void (*gpio_release)(struct usb_serial *serial);
> 
> This isn't the right place for this abstraction. Most of the setup code
> would be common for any device type with GPIOs.

For any pl2303 variant instead of any device type ?

> Just keep the generic gpio_startup and release from v6, and verify that
> ngpio > 0. Any further abstraction should only be added once we know how
> the other types handles GPIOs.
> 
> >  };
> >  
> >  struct pl2303_serial_private {
> >  	const struct pl2303_type_data *type;
> >  	unsigned long quirks;
> > +	void *gpio;
> 
> No void pointers, please.

void pointer is abstraction for different pl2303 gpio_data struct, just like driver core or subsystem core does.
I mean void pointer is right thing when we need abstraction, and we don't need type-specified startup|release, 
we don't need this void pointer.

> > +
> > +static int pl2303hx_gpio_direction_in(struct gpio_chip *chip, unsigned offset)
> > +{
> > +	struct pl2303hx_gpio_data *gpio = to_pl2303hx_gpio_data(chip);
> > +	int ret;
> > +
> > +	mutex_lock(&gpio->lock);
> > +	gpio->index &= ~pl2303hx_gpio_dir_mask(offset);
> > +	ret = pl2303_vendor_write(gpio->serial, PL2303HX_REG_GPIO_CONTROL, gpio->index);
> 
> This line is too long.
> 
> Apparently you did not run checkpatch on v7 because there are a whole
> bunch of warning and errors now.

Yes, I haven't run checkpatch on v7, I will do it on v8 if there is one.

> > +static void pl2303hx_gpio_release(struct usb_serial *serial)
> > +{
> > +	struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
> > +	struct pl2303hx_gpio_data *gpio = (struct pl2303hx_gpio_data *)spriv->gpio;
> > +
> > +	gpiochip_remove(&gpio->gpio_chip);
> 
> So this will corrupt the gpiolib structures if there are requested /
> exported gpios.

We can do nothing here, indeed we must call gpiochip_remove to notify 
gpio layer our leave, and hope gpio layer could handle it.

Thanks.

  parent reply	other threads:[~2014-08-17  1:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-09  5:28 [PATCH v7] usb:serial:pl2303: add GPIOs interface on PL2303 Wang YanQing
2014-08-12 14:46 ` Johan Hovold
2014-08-13  6:17   ` Hannes Petermaier
2014-08-13  7:05     ` Johan Hovold
2014-08-13  7:09       ` Greg KH
2014-08-17  1:04   ` Wang YanQing [this message]
2014-08-18 10:00     ` Johan Hovold
2014-08-17  2:05   ` Wang YanQing
2014-08-18 10:07     ` Johan Hovold
2014-08-27 23:43       ` Wang YanQing
2014-08-29 10:44         ` Johan Hovold

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=20140817010432.GA2907@localhost.localdomain \
    --to=udknight@gmail.com \
    --cc=andi@lisas.de \
    --cc=dforsi@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhovold@gmail.com \
    --cc=johan@kernel.org \
    --cc=linus.walleij@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.