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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
