Re: [PATCH] uio/pdrv_genirq: Add OF support

[Grant Likely <grant.likely@secretlab.ca>]

On Thu, Mar 31, 2011 at 03:51:32PM +0200, Michal Simek wrote:
> Arnd Bergmann wrote:
> >On Thursday 31 March 2011, John Williams wrote:
> >>On Thu, Mar 31, 2011 at 10:49 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> >>>On Thu, Mar 31, 2011 at 02:30:00PM +0200, Michal Simek wrote:
> >>>>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.