All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: John Williams <john.williams@petalogix.com>,
	Wolfram Sang <w.sang@pengutronix.de>,
	devicetree-discuss@lists.ozlabs.org, grant.likely@secretlab.ca,
	linux-kernel@vger.kernel.org, hjk@linutronix.de, gregkh@suse.de
Subject: Re: [PATCH] uio/pdrv_genirq: Add OF support
Date: Thu, 31 Mar 2011 15:51:32 +0200	[thread overview]
Message-ID: <4D9486E4.9030006@monstr.eu> (raw)
In-Reply-To: <201103311525.52396.arnd@arndb.de>

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.

Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

  reply	other threads:[~2011-03-31 13:51 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-31 12:29 UIO OF support Michal Simek
2011-03-31 12:29 ` Michal Simek
2011-03-31 12:30 ` [PATCH] uio/pdrv_genirq: Add " Michal Simek
2011-03-31 12:30   ` Michal Simek
2011-03-31 12:49   ` Wolfram Sang
2011-03-31 12:49     ` Wolfram Sang
     [not found]     ` <20110331124925.GA2202-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2011-03-31 13:10       ` John Williams
2011-03-31 13:23         ` Wolfram Sang
2011-03-31 13:23           ` Wolfram Sang
2011-03-31 13:37           ` Michal Simek
2011-03-31 13:37             ` Michal Simek
2011-03-31 13:47           ` John Williams
2011-03-31 13:47             ` John Williams
2011-03-31 16:25             ` Grant Likely
2011-03-31 16:25               ` Grant Likely
2011-03-31 13:11     ` John Williams
2011-03-31 13:11       ` John Williams
2011-03-31 13:25       ` Arnd Bergmann
2011-03-31 13:25         ` Arnd Bergmann
2011-03-31 13:51         ` Michal Simek [this message]
2011-03-31 16:34           ` Grant Likely
2011-03-31 13:28     ` Michal Simek
2011-03-31 17:03       ` Hans J. Koch
2011-03-31 17:57         ` Michal Simek
2011-03-31 19:23           ` Hans J. Koch
2011-03-31 19:48             ` Grant Likely
2011-03-31 20:30               ` Hans J. Koch
2011-04-02 10:35                 ` Wolfram Sang
2011-04-02 10:35                   ` Wolfram Sang
2011-04-04 17:04                   ` Hans J. Koch
2011-04-04 17:04                     ` Hans J. Koch
2011-04-04 17:31                     ` Wolfram Sang
2011-04-04 17:31                       ` Wolfram Sang
2011-04-04 18:24                       ` Hans J. Koch
2011-04-04 18:24                         ` Hans J. Koch
2011-04-05  6:25                         ` Michal Simek
2011-04-05  6:25                           ` Michal Simek
2011-04-05 11:50                           ` Hans J. Koch
2011-04-05 11:50                             ` Hans J. Koch
2011-03-31 16:43   ` Grant Likely
2011-03-31 16:43     ` Grant Likely
2011-03-31 17:54     ` Michal Simek
2011-03-31 17:54       ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9486E4.9030006@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=arnd@arndb.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@suse.de \
    --cc=hjk@linutronix.de \
    --cc=john.williams@petalogix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=w.sang@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.