Re: RFC: Platform data for onboard USB assets

[Nicolas Pitre <nicolas.pitre@linaro.org>]

On Wed, 23 Mar 2011, Benjamin Herrenschmidt wrote:

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

Yes, no one appears to disagree there.

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

The udev solution has its set of drawbacks.  Using udev is perfect for 
arbitrary user policies.  But here we're talking about a particular 
device which happens to be soldered on a particular board, and adding 
that knowledge to udev which is a separately maintained piece of 
software from the kernel is rather redundant while the kernel already 
knows perfectly well on which hardware it is running.  And as Andy 
pointed out, the kernel's job is to abstract hardware peculiarities, not 
to force them to user space.

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

... or even perform the needed intra-kernel API call to do the desired 
change to the registered device if possible, such as overriding the 
random MAC that the driver creates.

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

Generally speaking, this wouldn't make sense.  but this is a case where 
a generically probed device happens to be used in a very specific 
hardware design with its own quirks.  in that very particular case then 
it certainly makes some sense.

But if a standard notifier callback can be invoked once the device has 
been probed and before udev is invoked, and if that notifier callback 
can modify the defaults that were set by the generic drivers, then I 
don't think there would be a need for any additional infrastructure that 
only a very few oddball devices would use anyway.

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

Still, as Andy said, the void pointer is quickly converted to a fully 
typed structure, and then it is rather hard to have a driver working if 
the platform data structure is mismatched between the driver and the 
actual device registration.  So, while this is true that there is a 
possibility for misuse, in practice this is rather unlikely to go very 
far without being noticed, and therefore this argument alone is rather 
weak in support of a significant world order change.

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

No dispute there.  But some of us also would prefer a more pragmatic 
solution in the mean time, given DT is not there yet.

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

I don't think Andy is rejecting any alternatives, given it is practical 
in the short term.  That unfortunately pretty much rules out DT for the 
time being.

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

I wholeheartedly agree with that idea.  One thing that bothers me about DT 
is its tendency to show up deep into the guts of kernel code all over 
the place.  If a generic abstraction can be put in place, such as this 
get_device_attribute() example, then it is far more convenient to use 
DT, or _eventually_ use DT, or even _not_ use it in some cases but 
something else, without battling over the actual interface.

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

Agreed.

> > 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 :-)

Indeed.  But that would be a discussion for another thread.


Nicolas