On Wed, Aug 29, 2012 at 01:18:10PM +0300, Alexander Shishkin wrote: > Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> writes: > > > On Wed, Aug 29, 2012 at 10:50:08AM +0300, Alexander Shishkin wrote: > >> Richard Zhao <richard.zhao@xxxxxxxxxxxxx> writes: > >> > >> > i.MX usb controllers shares non-core registers, which may include > >> > SoC specific controls. We take it as a usbmisc device and usbmisc > >> > driver set operations needed by ci13xxx_imx driver. > >> > > >> > For example, Sabrelite board has bad over-current design, we can > >> > usbmisc to disable over-current detect. > >> > >> Why does this have to be part of the usb driver instead of SoC specific > >> code? It looks like you've created a whole new device/driver > >> infrastructure just to disable overcurrent for a specific board. > > > > Richards code indeed only handles overcurrent for a specific board, but > > there are more bits to configure in the longer run: power pin > > polarities, ULPI/serial mode select and some more. > > Sounds to me like these things that should be taken care of by the phy > driver, which will likely be simpler from both driver's and devicetree's > perspective. No, it's controlled by a set of usb misc registers, which is not in phy IP or usb controller IP. Thanks Richard > > > > >> > >> And the infrastructure boils down to a complex way of passing a callback > >> from imx driver to another imx driver, that only works if they are > >> probed in the right order. I don't see any point in doing it like this > >> other than inflating the device tree tables even further. > >> > >> Why can't this be part of the SoC code like it is done, for example in > >> arch/arm/mach-omap2/control.c? > > > > The settings are board specific, so there must be some way to configure > > them in the devicetree. > > But I'm sure there's a way to control board-specific settings/kludges > from devicetree? > > Regards, > -- > Alex > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
