lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140818100720.GF31755@localhost>
Date:	Mon, 18 Aug 2014 12:07:20 +0200
From:	Johan Hovold <johan@...nel.org>
To:	Wang YanQing <udknight@...il.com>
Cc:	Johan Hovold <johan@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	gregkh@...uxfoundation.org, jhovold@...il.com, andi@...as.de,
	dforsi@...il.com, gnomes@...rguk.ukuu.org.uk,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7] usb:serial:pl2303: add GPIOs interface on PL2303

On Sun, Aug 17, 2014 at 10:05:36AM +0800, Wang YanQing wrote:
> Hi Johan Hovold.
> 
> Another two questions.
> 	
> On Tue, Aug 12, 2014 at 04:46:25PM +0200, Johan Hovold wrote:
> > 
> > > +	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.
> 
> I assume you mean any pl2303 variant, not any device type, because
> no device in drivers/gpio has common setup code except many of them
> use struct gpio_chip.

Yes, pl2303 type/variant. Specifically, much of the setup code will be
identical even if say the number of gpio differ (2 or 4) depending on
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.
> 
> Instead of assume code works for all situation firstly,  test and write
> code for only one type device, and make code become generic when we find
> it works for others' type.
> 
> I don't known which way is better.

Add support for your device type (HXA). We should verify that it also
works for the non-end-of-life HXD, or we might need to find a way to
detect those two different types of HX and limit it to HXA for now.

If and when someone reverse-engineers a device type with a different
protocol for dealing with GPIOs, that's when you add further abstraction.

> Thanks very much for your patient review !!

You're welcome.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ