[PATCH v2] USB: Support for LPC32xx SoC

[Arnd Bergmann]

On Sunday 26 February 2012, Alan Stern wrote:
> On Sun, 26 Feb 2012, Arnd Bergmann wrote:
> 
> > We are doing a major rework of the ARM architecture tree right now
> > to allow building multiple SoC platforms together, which has not
> > been possible traditionally. The "PLATFORM_DRIVER" macro in ohci
> > and ehci is one of many things standing in the way still and will have
> > to be dealt with at some point.
> 
> Is there anybody in particular who is going to attack this issue?

Not the USB portion, we're still busy with more fundamental issues like
conflicting header files between the various subarchitectures.

> > > A little progress has been made already.  We just received a submission
> > > for a "generic" platform bus glue file that will be able to take over
> > > the jobs of several of the existiing files.  If anyone wants to take
> > > this further I won't object, but I don't plan to work on it myself
> > > soon.
> > 
> > Ok, good to know. The approach of a generic glue is exactly what I
> > was going to suggest. As we get to ARM platforms that are currently
> > using PLATFORM_DRIVER, I will then ask people to convert the ohci
> > glue to use that generic glue instead of adding another *_DRIVER
> > macro to ohci/ehci.
> 
> The problem is that several platforms have highly specialized needs
> that can't sanely be handled in a single generic driver.  Although a
> lot of drivers can be converted over, not all of them will.

Can you give an example? We have recently converted the sdhci mmc drivers
in a similar way, and we have the libata drivers that have always worked
in this manner.

> > I'm not sure about what we should do for lpc32xx. Is that
> > generic glue going into v3.4?
> 
> That's up to Greg.  At the moment it isn't used by anything, and unless
> an existing driver can be converted over I'd guess it's not likely to
> get merged right away.

Where is that patch? Maybe I can help out by converting the PCI
variants of ohci and ehci to the generic glue, because they are
easy to test.

> >  If so, we could convert the
> > pnx4008 driver to use that and abstract it in a way that works
> > nicely for pnx4008 and lpc32xx. OTOH, we might just let this
> > one go in as before and ask people to do it right for the next
> > one.
> 
> I don't know anything about these two platforms.  If they are
> sufficiently similar then it does make sense to combine the drivers
> into a single file, with various platform-specific decisions made at
> runtime.  These decisions don't necessarily have to use a machine_is_*
> kind of test (although they can); it might be simpler to do such a
> test once during probe and store the result in a flag for later reuse.
> Or then again, it might not since there's no obvious place to keep 
> such a flag...
> 
> At the moment, switching the pnx4008 driver to use the generic bus glue
> doesn't look easy.  The generic code doesn't know anything about i2c.

Maybe I misunderstood what the generic bus glue does then, because I
would not expect that it should know about i2c ;-)

I would think the generic bus glue would be a very simple library that
just exports the various symbols that are defined in ohci-hcd.c and
used in the bus specific driver so that the driver can be a separate
module. Is it something different from that?

	Arnd