linux-kernel - Re: [PATCH] USB: gadget driver for LPC32xx

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: <201203201921.51253.arnd@arndb.de>
Date:	Tue, 20 Mar 2012 19:21:50 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Roland Stigge <stigge@...com.de>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	w.sang@...gutronix.de, kevin.wells@....com,
	linux-arm-kernel@...ts.infradead.org, arm@...nel.org,
	srinivas.bakki@....com
Subject: Re: [PATCH] USB: gadget driver for LPC32xx

On Tuesday 20 March 2012, Roland Stigge wrote:
> The ISP1301 is a relatively simple transceiver where the actual
> differential USB signals end up being generated/decoded. It contains
> some registers and is controlled via I2C to manipulate electrical
> settings (pull up / power etc.).
> 
> At a first glance, I found the following drivers to be using it:
> 
> ohci-nxp (was: ohci-pnx4008 + ohci-lpc32xx)
> isp1301_omap
> lpc32xx_udc (WIP)
> 
> The common functions that all of them are using are some low-level
> functions like read/write byte, read/write word. (For ohci-nxp, I used
> smbus commands.) I propose exporting just the defines for all the
> registers and their bits together with some accessor functions.

Sounds great. 

> Would those be the correct places for header and driver:
> 
> drivers/usb/misc/isp1301.c
> include/linux/usb/isp1301.h

I believe drivers/usb/misc/ is for usb devices, not for usb hots
(otg or otherwise), but I'm not sure where else it would go.

> As an example usage, I would let the next update of the lpc32xx_udc use
> it and separately provide patches to make the other drivers above also
> use it.

Ok. One thing I'm not sure about is how you would pair the i2c
device with the platform specific driver. The easiest solution would
be to assume that there is always just one of each, so isp1301 binds
to the i2c device and exports functions to be used by the platform
driver. This would fail if you ever have more than one isp1301
in the system, but neither omap nor pnx4008 seem to be doing that.

I guess we can always add support for that later if needed, using
a device tree phandle link, or a pointer to the i2c device in
platform_data.

	Arnd
--
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/