Date:	Fri, 18 Mar 2011 21:33:00 +0000
From:	Andy Green <andy@...mcat.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Greg KH <greg@...ah.com>, Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss@...ts.ozlabs.org,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On 03/18/2011 08:06 PM, Somebody in the thread at some point said:

Hi -

> The main deficiency of platform_data is that it's very inflexible,
> you have to write code for each new board you want to support,
> something that we've generally moved away from in Linux a decade
> ago.

Well: Greg was also reduced to explaining that device renaming in 
userland was decided "a long time ago".  It's not argumentation, it is 
an appeal to an alleged tradition.

You think that striving away to create this Device Tree description of a 
specific board and maintaining it in a bootloader is LESS work somehow 
that registering platform devices in an array in the board definition 
file?  I think not.

> Another problem is that you need to hardcode data structures,
> which is arguably less flexible than key/value pairs.

After you dereferenced your static string via your API, and I 
dereferenced my platform_data member, we both end up with a pointer to 
data.  Board definition file also gets a chance to set that data at 
runtime: for example, take a look at the MAC-setting part of my 
patchset.  What exactly was your point?

> That is 142 unique files in the kernel referencing this (mostly
> powerpc, but also some others), both device drivers and dts files,

Powerpc would appear to be fairly considered as legacy, not the future.

>> =====>  If Device Tree APIs is mandated to implement functionality fixes
>> to drivers and platform_data is blocked for this, then we end up with
>> different, rotting functionality for platform_data basis and drivers
>> that remain broken on the many, many, platforms that don't have and will
>> never have Device Tree.  That does NOT sound like the right approach.
>
> See the device tree fragment patches that Grant just posted.
> It should become really easy to combine both methods, or to
> gradually migrate without breaking anything.

I take it Grant got over his initial offhand opinion of this RFC -->

''Oh, please no.

platform_data is an ugly non-type-checked anonymous pointer.  If you
need to pass data to a driver, use something better designed.  A
device tree fragment would work, or provide some kind of query api.
platform_data is definitely the wrong approach.''

I'm super happy if he mastered his distress and suddenly -- no doubt 
completely asynchronously to this thread -- decided to interoperate with 
platform_data as equals.  If that is indeed what has happened.

> The USB layer is not architecture specific, so when we add hacks
> to it for dealing with nondiscoverable hardware properties, we
> should use methods that are accepted everywhere, which platform
> data is not.

EVERY struct device has a platform_data member.

In the very deepest sense, platform_data is already accepted EVERYWHERE 
including USB and MMC / SDIO devices.

It is not platform_data that has to make its case.

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

Powered by blists - more mailing lists