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.
next prev parent 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: linkBe 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.