linux-kernel - Re: [PATCH] uio/pdrv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Mar 2011 10:34:19 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Michal Simek <monstr@...str.eu>
Cc:	Arnd Bergmann <arnd@...db.de>,
	John Williams <john.williams@...alogix.com>,
	Wolfram Sang <w.sang@...gutronix.de>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	hjk@...utronix.de, gregkh@...e.de
Subject: Re: [PATCH] uio/pdrv_genirq: Add OF support

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

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