Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[RFC] drivercore: Add of_match_table to the common device drivers

105 views
Skip to first unread message

Grant Likely

unread,
Mar 7, 2010, 2:00:02 AM3/7/10
to
OF-style matching can be available to any device, on any type of bus.
This patch allows any driver to provide an OF match table when CONFIG_OF
is enabled so that drivers can be bound against devices described in
the device tree.

Signed-off-by: Grant Likely <grant....@secretlab.ca>
---

Hi Greg and Kay,

Here is a potentially even more controversial RFC patch, the relevant
chunk being the addition of an of-style match table to struct device_driver
when CONFIG_OF is set. The idea being that OF style device binding is
applicable on any bus, regardless of the bus type. Each bus' probe could
be trivially extended to allow for an OF-style probe match.

I've used a #ifdef in this version, but it doesn't have to be conditional
if that would make for cleaner code. Either way, none of the core code
would need to have and #ifdef bits.

As with the previous patch, I want to get feedback before I proceed too
far down this path.

Thanks,
g.


drivers/macintosh/macio_asic.c | 5 ++---
drivers/of/of_bus.c | 7 ++++---
include/linux/device.h | 4 ++++
3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index 67fe13f..a5806ab 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -40,8 +40,7 @@ static struct macio_chip *macio_on_hold;
static int macio_bus_match(struct device *dev, struct device_driver *drv)
{
struct macio_dev * macio_dev = to_macio_device(dev);
- struct macio_driver * macio_drv = to_macio_driver(drv);
- const struct of_device_id * matches = macio_drv->match_table;
+ const struct of_device_id * matches = drv->match_table;

if (!matches)
return 0;
@@ -84,7 +83,7 @@ static int macio_device_probe(struct device *dev)

macio_dev_get(macio_dev);

- match = of_match_device(drv->match_table, &macio_dev->ofdev);
+ match = of_match_device(drv->driver.match_table, &macio_dev->ofdev);
if (match)
error = drv->probe(macio_dev, match);
if (error)
diff --git a/drivers/of/of_bus.c b/drivers/of/of_bus.c
index d58ade1..9fd7f7d 100644
--- a/drivers/of/of_bus.c
+++ b/drivers/of/of_bus.c
@@ -22,8 +22,7 @@ extern struct device_attribute of_platform_device_attrs[];
static int of_platform_bus_match(struct device *dev, struct device_driver *drv)
{
struct of_device *of_dev = to_of_device(dev);
- struct of_platform_driver *of_drv = to_of_platform_driver(drv);
- const struct of_device_id *matches = of_drv->match_table;
+ const struct of_device_id *matches = drv->of_match_table;

if (!matches)
return 0;
@@ -46,7 +45,7 @@ static int of_platform_device_probe(struct device *dev)

of_dev_get(of_dev);

- match = of_match_device(drv->match_table, of_dev);
+ match = of_match_device(drv->driver.of_match_table, of_dev);
if (match)
error = drv->probe(of_dev, match);
if (error)
@@ -391,6 +390,8 @@ int of_register_driver(struct of_platform_driver *drv, struct bus_type *bus)
drv->driver.name = drv->name;
if (!drv->driver.owner)
drv->driver.owner = drv->owner;
+ if (!drv->driver.of_match_table)
+ drv->driver.of_match_table = drv->match_table;
drv->driver.bus = bus;

/* register with core */
diff --git a/include/linux/device.h b/include/linux/device.h
index c9b199a..0f998f5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -129,6 +129,10 @@ struct device_driver {

bool suppress_bind_attrs; /* disables bind/unbind via sysfs */

+#if defined(CONFIG_OF)
+ const struct of_device_id *of_match_table;
+#endif
+
int (*probe) (struct device *dev);
int (*remove) (struct device *dev);
void (*shutdown) (struct device *dev);

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

Stephen Rothwell

unread,
Mar 7, 2010, 2:10:01 AM3/7/10
to
Hi Grant,

Just a quick note:

On Sat, 06 Mar 2010 23:47:00 -0700 Grant Likely <grant....@secretlab.ca> wrote:
>
> diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
> index 67fe13f..a5806ab 100644
> --- a/drivers/macintosh/macio_asic.c
> +++ b/drivers/macintosh/macio_asic.c
> @@ -40,8 +40,7 @@ static struct macio_chip *macio_on_hold;
> static int macio_bus_match(struct device *dev, struct device_driver *drv)
> {
> struct macio_dev * macio_dev = to_macio_device(dev);
> - struct macio_driver * macio_drv = to_macio_driver(drv);
> - const struct of_device_id * matches = macio_drv->match_table;
> + const struct of_device_id * matches = drv->match_table;

^^^^^^^^^^^
of_match_table

--
Cheers,
Stephen Rothwell s...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Grant Likely

unread,
Mar 7, 2010, 2:30:02 AM3/7/10
to
On Sun, Mar 7, 2010 at 12:07 AM, Stephen Rothwell <s...@canb.auug.org.au> wrote:
> Hi Grant,
>
> Just a quick note:
>
> On Sat, 06 Mar 2010 23:47:00 -0700 Grant Likely <grant....@secretlab.ca> wrote:
>>
>> diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
>> index 67fe13f..a5806ab 100644
>> --- a/drivers/macintosh/macio_asic.c
>> +++ b/drivers/macintosh/macio_asic.c
>> @@ -40,8 +40,7 @@ static struct macio_chip � � �*macio_on_hold;
>> �static int macio_bus_match(struct device *dev, struct device_driver *drv)
>> �{
>> � � � struct macio_dev * macio_dev = to_macio_device(dev);
>> - � � struct macio_driver * macio_drv = to_macio_driver(drv);
>> - � � const struct of_device_id * matches = macio_drv->match_table;
>> + � � const struct of_device_id * matches = drv->match_table;
> � � � � � � � � � � � � � � � � � � � � � � � � � ^^^^^^^^^^^
> of_match_table

Heh. Oops. I fixed that in my local directory when compile testing,
but neglected to refresh the patch.

Thanks,
g.

Greg KH

unread,
Mar 7, 2010, 1:10:02 PM3/7/10
to
On Sat, Mar 06, 2010 at 11:47:00PM -0700, Grant Likely wrote:
> OF-style matching can be available to any device, on any type of bus.
> This patch allows any driver to provide an OF match table when CONFIG_OF
> is enabled so that drivers can be bound against devices described in
> the device tree.
>
> Signed-off-by: Grant Likely <grant....@secretlab.ca>
> ---
>
> Hi Greg and Kay,
>
> Here is a potentially even more controversial RFC patch, the relevant
> chunk being the addition of an of-style match table to struct device_driver
> when CONFIG_OF is set. The idea being that OF style device binding is
> applicable on any bus, regardless of the bus type. Each bus' probe could
> be trivially extended to allow for an OF-style probe match.
>
> I've used a #ifdef in this version, but it doesn't have to be conditional
> if that would make for cleaner code. Either way, none of the core code
> would need to have and #ifdef bits.
>
> As with the previous patch, I want to get feedback before I proceed too
> far down this path.

I have no objection to this patch at all, it looks good to me.

Perhaps, in the future, you might be able to move the OF driver/device
binding into the driver core itself to make it easier in the end. But
for now, feel free to add:
Acked-by: Greg Kroah-Hartman <gre...@suse.de>
and send it off through your tree.

thanks,

greg k-h

Grant Likely

unread,
Mar 7, 2010, 3:40:02 PM3/7/10
to

Thanks Greg.

Yes, I seem to be moving in that direction. The OF api's are turning
out to be quite complementary to the rest of the driver model. If
CONFIG_OF is enabled, then a whole bunch of routines become available
to drivers for fetching data as an alternative to pdata. If not, then
the OF apis become empty inline stubs that return invalid or error
codes. The nice thing is that the apis all work the same, regardless
of the underlying bus interface, so it is usable by more than just the
platform & of_platform busses.

I've got a metric truckload of patches to post that go in this
direction, but I'm waiting until after the merge window so I don't add
to the normal bedlam. :-)

Cheers,
g.

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

0 new messages