On Thu, Mar 31, 2011 at 03:51:32PM +0200, Michal Simek wrote:

Arnd Bergmann wrote:

quoted

On Thursday 31 March 2011, John Williams wrote:

quoted

On Thu, Mar 31, 2011 at 10:49 PM, Wolfram Sang [off-list ref] wrote:

quoted

On Thu, Mar 31, 2011 at 02:30:00PM +0200, Michal Simek wrote:

quoted

Support OF support. "generic-uio" compatible property is used.

And exactly this was the issue last time (when I tried). This is a
generic property, which is linux-specific and not describing HW. The
agreement back then was to we probably need to add compatible-entries at
runtime (something like new_id for USB). So the uio-of-driver could be
matched against any device. Otherwise, we would collect a lot of
potential entries like "vendor,special-card1". Although I wonder
meanwhile if it is really going to be that bad; we don't have so much
UIO-driver in tree as well. Maybe worth a try?

Maybe I misunderstand you, in my view it is the responsibility of
<vendor> to create their DTS files to indicate they want
<special-card1> to bind to generic-uio.

So, no great list of compat strings should grow in the driver, but
rather the user of the driver must make it happen.

Am I missing something?

We try to make the device tree on describe the present hardware,
but not relate to how it is used.

There are certainly cases where a specific piece of hardware can
be used either by a kernel-only driver or the UIO driver with a
user backend. I would argue that you should be able to use an
identical device tree for both cases, because the hardware is
the same. Chosing which driver to use can be either in the realm
of the kernel, or even user policy.

ok. What about to keep of_device_id empty?  Then there is compatible
property string and everybody can choose what wants.
OF is just a different driver initialization method but it is in the
same category which is supported right now which is initialization
through platform_device structure.

I'm not completely sure I understand what you're suggesting here.
Yes, of_device_id can be left unpopulated, but then you need to make
sure another method is available for binding the driver.

hmmmm....

You could see if the manual 'bind/unbind' platform_bus sysfs
attributes would do the job for you (see drivers/base/bus.c).  You'd
need some mechanism to force the generic-uio driver to accept the
device.

g.