On Mon, Dec 10, 2007 at 08:38:46AM +1100, Benjamin Herrenschmidt wrote:
>
> > +static struct i2c_device_id rs5c372_id[] = {
> > + {"rtc-rs5c372", rtc_rs5c372a},
> > + {"rs5c372a", rtc_rs5c372a},
> > + {"rs5c372b", rtc_rs5c372b},
> > + {"rv5c386", rtc_rv5c386},
> > + {"rv5c387a", rtc_rv5c387a},
> > + DT_NAME({"ricoh,rs5c372a", rtc_rs5c372a},)
> > + DT_NAME({"ricoh,rs5c372b", rtc_rs5c372b},)
> > + DT_NAME({"ricoh,rv5c386", rtc_rv5c386},)
> > + DT_NAME({"ricoh,rv5c387a", rtc_rv5c387a},)
> > + {},
> >
> > But what's the point in making these names specific to device trees?
> > They are perfectly valid names for the devices that could be used from
> > any platform.
>
> The more I think about it, the more I tend to agree that tagging isn't
> necessary and you are right. We should just match the name against the
> "compatible" property of the OF nodes (which mean we need to support
> multiple matches though since "compatible" is a list of strings).
>
> Now, I have a question about your example: Why do you have both
> "rs5c372a" and "ricoh,rs5c372a" ?
>
> I would argue that we should keep only the later...
I think existing platforms register with the simpler name, so they would
need to be changed. Having both shouldn't do harm though, we tend to
sometimes do the same with of_platform drivers for legacy reasons.
Unless someone adds a ridicously simple match name (by mistake or
whatever), it shouldn't be a problem. And if someone does it to some
dts/firmware, then we'll just need to add device tree fixups to set the
"vendor,product" string instead, yet again similar to how we have to do
sometimes with other drivers/devices.
-Olof
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
