All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, devicetree-discuss@ozlabs.org,
	"Hans J. Koch" <hjk@linutronix.de>,
	Magnus Damm <magnus.damm@gmail.com>,
	linuxppc-dev@ozlabs.org, Greg KH <gregkh@suse.de>
Subject: Re: [PATCH 2/2] uio: add an of_genirq driver
Date: Tue, 16 Jun 2009 06:46:47 -0600	[thread overview]
Message-ID: <fa686aa40906160546q73765b66h204334e3ca081de0@mail.gmail.com> (raw)
In-Reply-To: <20090616090435.GA21321@pengutronix.de>

On Tue, Jun 16, 2009 at 3:04 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
>
>> > diff --git a/Documentation/powerpc/dts-bindings/uio-generic.txt b/Documentation/powerpc/dts-bindings/uio-generic.txt
>> > new file mode 100644
>> > index 0000000..8ad9861
>> > --- /dev/null
>> > +++ b/Documentation/powerpc/dts-bindings/uio-generic.txt
>> > @@ -0,0 +1,16 @@
>> > +UIO for custom devices
>> > +
>> > +A device which will be mapped using the UIO subsystem.
>> > +
>> > +Properties:
>> > + - compatible : should contain the specific model used, followed by
>> > +                "generic-uio".
>> > + - reg : address range(s) of the device (up to MAX_UIO_MAPS)
>> > + - interrupts : interrupt of the device
>> > +
>> > +Example:
>> > +        c64fpga@0 {
>> > +                compatible = "ptx,c64fpga001", "generic-uio";
>> > +                reg = <0x0 0x10000>;
>> > +                interrupts = <0 0 3>;
>> > +        };
>>
>> Hmmm, I'm not happy about this.  The device tree describes the
>> hardware, not the way Linux uses the hardware.  UIO definitely falls
>> into the category of Linux implementation detail.
>
> Yes, I am aware of that. I just started with the mechanisms which are available
> today and hoped we could find some compatible-value which will suit all needs.

Trouble is a value that suits all needs today probably won't a year
from now.  :-)

>> This should be approached from the other way around.  Either the
>> generic-uio of_platform driver should contain an explicit list of
>> devices to be handled by UIO,
>
> Well, that could lead to a quite huge match_table over time.
>
>> or the OF infrastructure should be modified to allow things like force
>> binding of_devices to of_drivers at runtime.
>
> That is an interesting idea. I could imagine something like a 'new_compatible"
> entry in the sysfs-section of the driver similar to 'new_id' for PCI. After
> writing a new compatible-string into it, matching will triggered again with the
> new entry added. That could (should?) also be placed at the of-core-level. Or
> did you have something else in mind?

Yeah, that sounds appropriate.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: devicetree-discuss@ozlabs.org, "Hans J. Koch" <hjk@linutronix.de>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Greg KH <gregkh@suse.de>
Subject: Re: [PATCH 2/2] uio: add an of_genirq driver
Date: Tue, 16 Jun 2009 06:46:47 -0600	[thread overview]
Message-ID: <fa686aa40906160546q73765b66h204334e3ca081de0@mail.gmail.com> (raw)
In-Reply-To: <20090616090435.GA21321@pengutronix.de>

On Tue, Jun 16, 2009 at 3:04 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
>
>> > diff --git a/Documentation/powerpc/dts-bindings/uio-generic.txt b/Docu=
mentation/powerpc/dts-bindings/uio-generic.txt
>> > new file mode 100644
>> > index 0000000..8ad9861
>> > --- /dev/null
>> > +++ b/Documentation/powerpc/dts-bindings/uio-generic.txt
>> > @@ -0,0 +1,16 @@
>> > +UIO for custom devices
>> > +
>> > +A device which will be mapped using the UIO subsystem.
>> > +
>> > +Properties:
>> > + - compatible : should contain the specific model used, followed by
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"generic-uio".
>> > + - reg : address range(s) of the device (up to MAX_UIO_MAPS)
>> > + - interrupts : interrupt of the device
>> > +
>> > +Example:
>> > + =A0 =A0 =A0 =A0c64fpga@0 {
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "ptx,c64fpga001", "gen=
eric-uio";
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x0 0x10000>;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <0 0 3>;
>> > + =A0 =A0 =A0 =A0};
>>
>> Hmmm, I'm not happy about this. =A0The device tree describes the
>> hardware, not the way Linux uses the hardware. =A0UIO definitely falls
>> into the category of Linux implementation detail.
>
> Yes, I am aware of that. I just started with the mechanisms which are ava=
ilable
> today and hoped we could find some compatible-value which will suit all n=
eeds.

Trouble is a value that suits all needs today probably won't a year
from now.  :-)

>> This should be approached from the other way around. =A0Either the
>> generic-uio of_platform driver should contain an explicit list of
>> devices to be handled by UIO,
>
> Well, that could lead to a quite huge match_table over time.
>
>> or the OF infrastructure should be modified to allow things like force
>> binding of_devices to of_drivers at runtime.
>
> That is an interesting idea. I could imagine something like a 'new_compat=
ible"
> entry in the sysfs-section of the driver similar to 'new_id' for PCI. Aft=
er
> writing a new compatible-string into it, matching will triggered again wi=
th the
> new entry added. That could (should?) also be placed at the of-core-level=
. Or
> did you have something else in mind?

Yeah, that sounds appropriate.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2009-06-16 12:47 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12  0:04 [PATCH 0/2] add OF wrapper for uio-pdrv-genirq Wolfram Sang
2009-06-12  0:04 ` [PATCH 1/2] uio/pdrv_genirq: Refactor probe routine to expose a generic part Wolfram Sang
2009-06-12  0:04   ` Wolfram Sang
2009-06-12  0:04   ` Wolfram Sang
2009-06-14 12:15   ` Hans J. Koch
2009-06-14 12:15     ` Hans J. Koch
2009-06-12  0:04 ` [PATCH 2/2] uio: add an of_genirq driver Wolfram Sang
2009-06-12  0:04   ` Wolfram Sang
2009-06-12  0:04   ` Wolfram Sang
2009-06-14 12:21   ` Hans J. Koch
2009-06-14 12:21     ` Hans J. Koch
2009-06-14 17:14     ` Wolfram Sang
2009-06-14 17:14       ` Wolfram Sang
2009-06-14 17:14       ` Wolfram Sang
2009-06-14 18:33       ` Hans J. Koch
2009-06-14 18:33         ` Hans J. Koch
2009-06-14 18:33         ` Hans J. Koch
2009-06-14 19:05         ` Wolfram Sang
2009-06-14 19:05           ` Wolfram Sang
2009-06-14 19:05           ` Wolfram Sang
2009-06-14 19:23           ` Hans J. Koch
2009-06-14 19:23             ` Hans J. Koch
2009-06-14 19:23             ` Hans J. Koch
2009-06-14 19:36             ` Wolfgang Grandegger
2009-06-14 19:36               ` Wolfgang Grandegger
2009-06-14 19:36               ` Wolfgang Grandegger
2009-06-14 20:34               ` Hans J. Koch
2009-06-14 20:34                 ` Hans J. Koch
2009-06-14 20:34                 ` Hans J. Koch
2009-06-14 22:00                 ` Wolfram Sang
2009-06-14 22:00                   ` Wolfram Sang
2009-06-14 22:00                   ` Wolfram Sang
2009-06-14 23:01                   ` Hans J. Koch
2009-06-14 23:01                     ` Hans J. Koch
2009-06-14 23:01                     ` Hans J. Koch
2009-06-14 23:46                     ` Wolfram Sang
2009-06-14 23:46                       ` Wolfram Sang
2009-06-14 23:46                       ` Wolfram Sang
2009-06-14 23:50                       ` Hans J. Koch
2009-06-14 23:50                         ` Hans J. Koch
2009-06-14 23:50                         ` Hans J. Koch
2009-06-14 19:27           ` Greg KH
2009-06-14 19:27             ` Greg KH
2009-06-14 21:46             ` Wolfram Sang
2009-06-14 21:46               ` Wolfram Sang
2009-06-14 21:46               ` Wolfram Sang
2009-06-14 23:12     ` Alan Cox
2009-06-14 23:12       ` Alan Cox
2009-06-14 23:12       ` Alan Cox
2009-06-14 23:45       ` Hans J. Koch
2009-06-14 23:45         ` Hans J. Koch
2009-06-14 23:45         ` Hans J. Koch
2009-06-15  8:44         ` Alan Cox
2009-06-15  8:44           ` Alan Cox
2009-06-15  8:44           ` Alan Cox
2009-06-15  9:45       ` Benjamin Herrenschmidt
2009-06-15  9:45         ` Benjamin Herrenschmidt
2009-06-15  9:45         ` Benjamin Herrenschmidt
2009-06-14 14:40   ` Grant Likely
2009-06-14 14:40     ` Grant Likely
2009-06-14 14:40     ` Grant Likely
2009-06-16  9:04     ` Wolfram Sang
2009-06-16  9:04       ` Wolfram Sang
2009-06-16  9:04       ` Wolfram Sang
2009-06-16 12:46       ` Grant Likely [this message]
2009-06-16 12:46         ` Grant Likely

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=fa686aa40906160546q73765b66h204334e3ca081de0@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=gregkh@suse.de \
    --cc=hjk@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=magnus.damm@gmail.com \
    --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.