From: arnd@arndb•de (Arnd Bergmann)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2] USB: Support for LPC32xx SoC
Date: Mon, 27 Feb 2012 14:03:16 +0000 [thread overview]
Message-ID: <201202271403.16893.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1202261040020.22970-100000@netrider.rowland.org>
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
next prev parent reply other threads:[~2012-02-27 14:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 20:57 [PATCH v2] USB: Support for LPC32xx SoC Roland Stigge
2012-02-23 21:05 ` Roland Stigge
2012-02-24 6:35 ` Wolfram Sang
2012-02-24 15:03 ` Arnd Bergmann
2012-02-25 3:51 ` Wolfram Sang
2012-02-25 8:45 ` Arnd Bergmann
2012-02-25 15:46 ` Alan Stern
2012-02-26 10:01 ` Arnd Bergmann
2012-02-26 15:59 ` Alan Stern
2012-02-27 14:03 ` Arnd Bergmann [this message]
2012-02-27 16:42 ` Alan Stern
2012-02-27 22:01 ` Arnd Bergmann
2012-02-28 15:01 ` Alan Stern
2012-02-28 15:53 ` Arnd Bergmann
2012-02-28 16:51 ` Alan Stern
2012-02-25 14:03 ` Roland Stigge
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=201202271403.16893.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox