lkml.org 
[lkml]   [2011]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Platform data for onboard USB assets
On 03/18/2011 09:28 PM, Somebody in the thread at some point said:

Hi -

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

I appreciate your candour.

> However, at issue here is that platform_data sucks hard, and
> asynchronous platform data sucks harder. I think I can go out on a

Personally, I spend a lot of my life trying to back up assertions with
provable statements and logic.

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

... and if there is no problem with indeterminism for targeting that
pointer, what you are saying is just blather.

In fact the normal use for platform_data is to be pointed to by the very
same struct that defines the device in board definition file. There is
NO chance of any dropped ball if the author of the board definition file
had it right: none. And again, any error here is deterministic, so you
are talking about a case where the board definition file author screwed
it up and didn't bother to test: it is always wrong. Okay; it is true
that if the author writes crap and doesn't test it the result is not
good. Same goes for Device Tree.

So this claim against platform_data is worthless.

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

Hm. I am not sure how many times I used the phrase "hardwired", or
"wired on the board" or similar, but I think it must add up by now.
This leads to determinism.

> 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

Correct me if I am wrong, but if you deploy logic to lead to NAKing
stuff that seems wrong to you, it makes you a valuable member of the
community. If you cannot actually explain what the problem is
coherently -- perhaps especially when it touches upon stuff in conflict
with your personal hobby-horse -- then you should carefully consider if
a NAK is appropriate or if you lose credibility by making such threats
not backed up by logic, but - it seems to me - emotion.

I do not mind if I am fairly NAKed. That has happened in the past and I
made good efforts to understand what I missed and and learn.

What I find so difficult in this thread is the very poor argumentation
deployed against my proposal. You are actually reduced to arguing by
authority, "because I am in a position to NAK you, I will, until you
give up" is your approach. I just have contempt for it, Grant.

It tells me you do not actually have faith in your own position, or you
would be explaining my stupidity in clear terms "even I could understand".

I already have good reasons to continue and do the SDIO implementation:
your opinion is not a factor, so NAK away how you feel you need to so
you feel better.

> ways. Device tree is one option, but I will accept other approaches.

That's good, because I have patches for my approach, I hope you will
give them the consideration they deserve.

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

And in the (usual SoC) case where there is no indeterminism and the data
is always as intended? Your point is again worthless.

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

So sad that you, head Device Tree dude, don't seem to understand there
is a class of information not available at the CPU; not available at the
IP unit, but which must be passed in externally, eg, OMAP I2C bus width
mapping.

-Andy


\
 
 \ /
  Last update: 2011-03-19 00:07    [W:0.158 / U:7.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site