Message-ID: <AANLkTi=Vy4Cu9rf7SpOFL1umN37bJgXhq9jEQpUrqjgw@mail.gmail.com>
Date:	Fri, 18 Mar 2011 15:28:14 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	andy.green@...aro.org
Cc:	Andy Green <andy@...mcat.com>, Arnd Bergmann <arnd@...db.de>,
	Greg KH <greg@...ah.com>, 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 Fri, Mar 18, 2011 at 11:52 AM, Andy Green <andy@...mcat.com> wrote:
> On 03/18/2011 03:00 PM, Somebody in the thread at some point said:
>
> Hi -
>
>>> You changed your first opinion about tagging "dynamically probed
>>> devices" with what is effectively platform_data, cool.
>>
>> I still don't like the idea of attaching platform_data to more
>> devices, when we try to move people away from that in other
>> parts of the kernel, because of the known deficiencies.
>
> Whatever way you look at it, data delivered into the driver by Device Tree
> is fundamentally the same action as delivering data into the driver by
> platform_data.  Yes, you query by named element with device context, but you
> end up with the same answer as if you dereference a platform_data member.
>  There are no "known deficiencies" to platform_data for this action either,
> at least, not known to me, I don't think lack of typechecking on the pointer
> itself is an issue given the accuracy it can be targeted to a
> soldered-on-the-board device.

Apologies if we got a little carried away on the device tree side
topic; it is something that needs to be investigated regardless and
that unfortunately ended up co-opting this thread.  You're right that
on ARM device tree is optional and a solution is required for
!CONFIG_OF.

However, at issue here is that platform_data sucks hard, and
asynchronous platform data sucks harder.  I think I can go out on a
limb and say that platform_data is viewed with distaste by more people
than just Arnd and me.  It sucks because it is an anonymous pointer
with absolutely zero chance of verifying that the driver has the right
thing when it comes out the other end at the driver.  This means the
very real possibility of dereferencing the wrong structure and the
kernel oopsing or worse.

For current {platform,i2c,spi} device users, there is at least some
level of protection in that the specific driver and the specific pdata
is specified at exactly the same time in the same place in the source
code.  If a driver changes the pdata structure it expects, then it is
easy to find all the users (at least for all in-tree users), but it
still sucks.  gcc cannot tell us when it is wrong, and the kernel
cannot validate it at runtime.  One reason the DT has been preferred
over platform_data in this discussion is because it does *not* carry
the risk of dereferencing the wrong structure.

Asynchronously attached pdata sucks harder because the selected driver
is completely dissociated from the pdata type.  Not even the i2c and
spi board info structures have this issue.  At least the board info
structures have the driver and the pdata settings co-located.

I certainly have no intention of trying to migrate
{platform,i2c,spi}_device away from platform_data, but I will actively
nack any attempt to bring it into other subsystems.  There are better
ways.  Device tree is one option, but I will accept other approaches.
Using domain specific api, such as to retrieve the correct MAC address
is one idea that's been raised.  Regardless, the ability to validate
the data passed to the driver, either at compile or runtime, is a hard
requirement in my mind.

>> Passing a MAC address in a device tree property is a
>> well-established method that is used on many drivers, and
>> is portable across operating systems and architectures.
>
> If you're talking about Device Tree, that itself is not at all "well
> established" let alone servicing drivers from it.  Like I say I don't want
> to seem like I am down on it, but it is very new indeed let's face it and
> few drivers are using it for functional configuration information compared
> to vast numbers using platform_data.
>
> =====> 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.
>
> I guess the grand plan is to eliminate platform_data by overwhelming it with
> Device Tree refactoring.  But each driver has to be tested and each board
> definition file changed... that is a huge, huge undertaking that will not
> happen in any kind of medium and perhaps not long term either.

Nope, not the plan.

> At least we agree there's no point to target pluggable devices with either
> solution, in which case platform_data and Device Tree provide the same end
> result, plus or minus extra query API.

Right, if it is detectable it has no business being described
anywhere, whether it be platform_data, a dt node, or something else.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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