lkml.org 
[lkml]   [2011]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Platform data for onboard USB assets
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


\
 
 \ /
  Last update: 2011-03-23 05:23    [W:0.238 / U:1.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site