linux-kernel - Re: [PATCH v2] USB: Support for LPC32xx SoC

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]

Date:	Sun, 26 Feb 2012 10:59:47 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Arnd Bergmann <arnd@...db.de>
cc:	Wolfram Sang <w.sang@...gutronix.de>,
	<linux-arm-kernel@...ts.infradead.org>,
	Roland Stigge <stigge@...com.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<kevin.wells@....com>
Subject: Re: [PATCH v2] USB: Support for LPC32xx SoC

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?

> > 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.

> 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.

>  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.

Alan Stern

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