Re: RFC: Platform data for onboard USB assets

From: Andy Green
Date: Fri Mar 18 2011 - 19:04:23 EST

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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at