Re: RFC: Platform data for onboard USB assets

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Sorry Ben, but you are the one who sounds like a priest here, having 
> invoked the "religious" qualifier twice in a row in this thread.

Time to burn a few books then :-)

> I think that Andy is asking absurdly good questions which are backed by 
> candid logic and reasoning.  If anything, his arguments are purely 
> technical and extremely practical. And so far all he's got for answers 
> was rather subjective, emotionally charged and even dogmatic.

I think the technical aspects have been essentially answered. The
important part of the thread is what the "right" approach to identifying
the on-board device (vs. an equivalent device being hot-plugged), and I
think we all agreed this has to be the physical port "path" (in case
there's hubs or switches on the way).

The device-tree and whatever other udev based solutions using physical
path are both "transports" in a sense for that same information and so
in the grand scheme of thing equivalent.

The argument boils down to should we encourage adding an additional
in-kernel platform_data based hooks for dynamically probed busses such
as USB as well ? or go for a udev based solution for the time being
which would probably work as well in practice and focus on getting the
device-tree based solution for the long term instead.

> With regards to DT on ARM I'm rather "softly" convinced this is a good 
> thing.  However seeing a persisting lack of truly technical answers to 
> Andy's questions is rather disturbing, and makes me wish for much more 
> than the current hype around DT which appears to fall flat when 
> challenged.

I don't think any technical answer is missing. Dynamic platform data is
possible and in fact the platform could do it today using bus notifiers
and "hooking up" the platform data on the fly if needed I suppose.

Does it make sense however to add platform data for generic probed
devices ? I don't think so.

For some reason Andy doesn't seem to consider the lack of type
information as a problem, Grant and I do, I don't know where we can go
from there, it's a very technical argument and I don't feel like I need
to teach people on this list what are the drawbacks on relying on void *
pointers to structures attached to devices like that that -will- go
wrong.

I simply believe that this is the wrong solution for the problem. I
would very much prefer having a way for the driver to retrieve "platform
attributes".

This is essentially what the name/value properties of the device-tree
provide, but it could be abstracted in a way that doesn't require the
device-tree and allows drivers to be unchanged whether the thing is
backed with a DT or by platform callbacks as long as there's a minimum
amount of thought given to naming the property reasonably.

For some reason I didn't find Andy answers conductive to a reasonable
discussion and indeed I admit I probably switched to dismiss/troll mode
a bit too quickly, so let's the heat go down a bit here and see if we
can find a common ground.

If you guys can agree on my above proposal, we could maybe come up with
some "get_device_attribute(dev, name)" kind of interface, that would
then boild down to platform calls or device-tree transparently (or arch
calls optionally populated by generic device-tree based helpers
etc....).

This would be much better I believe that having those random structures
hooked up to void * pointers floating around and also generally more
flexible vs. platforms that provide or don't provide some of this
information (platforms might provide a subset etc...)

> There is one hard fact that no one can ignore: DT support on ARM still 
> has a long way to go before it is truly usable.  The world just can't 
> stop turning until this is ready.

Right but more efforts could be put into making that happen :-)

Cheers
Ben.

> 
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/