Re: [RFC PATCH 3/4] PLATFORM: Introduce async platform_data attach api

[Andy Green <andy@warmcat.com>]

On 03/13/2011 10:41 AM, Somebody in the thread at some point said:
> On Sunday, March 13, 2011, Greg KH wrote:
>> On Sat, Mar 12, 2011 at 10:32:27PM +0000, Andy Green wrote:
>>> This introduces a platform API so busses can allow platform_data to
>>> be attached to any struct device they create from probing in one step.
>>>
>>> The function checks through the async platform_data map if one was
>>> previously registered, and checks the device's device path for itself
>>> and its parents against the mapped device path names.
>>>
>>> If it sees a match, it attaches the associated platform_data and sets
>>> that map entry's device_path to NULL so no further time is spent trying
>>> to match it.
>>
>> This _really_ should just use the device tree stuff, that is what it is
>> for, please don't duplicate it here in a not-as-flexible way.
>
> I agree.
>
> @Andy: If it doesn't work for you for some reason, please let us know the
> usage case that is not covered (in detail).

The device tree stuff does not yet exist in a workable way, 
platform_data is established everywhere except USB bus.  Device tree 
brings in bootloader version as a dependency: this method doesn't.

Using platform / board definition files to define and configure the SoC 
and most or all of its onboard assets is a technique widely deployed in 
SoC board definition files.  The patch just very lightly extends 
platform_data to be workable with USB bus devices like it is the other 
buses, within the goal of being able to configure onboard assets at 
boot-time, so it's quite unremarkable from that POV.

However if you don't have that perspective on it, and think about it on 
a PC where it is not intended to be used, no doubt the patchset's 
approach is hard to understand as useful.

Device Tree will be a nice improvement in many ways when it is done, in 
this particular case though presumably it'll have to patch usbnet and 
smsc95xx in a similar way to offer similar configurability.

In the meanwhile, either Panda and Beagle will stay as they are for 
these misfeatures or specific userlands will have to be stunk up with 
/proc/cpuinfo-grepping board-specific ditro-by-distro quirk management.

Anyway, thanks for all the comments on this RFC.

-Andy