On Fri, Mar 30, 2012 at 05:53:35PM +0900, Magnus Damm wrote:
> On Fri, Mar 30, 2012 at 5:47 PM, Paul Mundt <lethal@xxxxxxxxxxxx> wrote:
> > On Fri, Mar 30, 2012 at 05:44:02PM +0900, Magnus Damm wrote:
> >> +static const struct of_device_id sh_mobile_i2c_dt_ids[] __devinitconst = {
> >> + ? ? { .compatible = "renesas,rmobile-iic", },
> >> + ? ? {},
> >> +};
> >> +MODULE_DEVICE_TABLE(of, sh_mobile_i2c_dt_ids);
> >> +
> > Given that this block predates R-Mobile, using the rmobile naming here is
> > pretty dubious. I suppose you can have it as an alias, though.
>
> Sure, but creating new code based an old naming conventions seem rather
> odd too.
>
Devices should be named what they are, not what the marketing people tell
you they should be. Retroactively attempting to label parts that pre-date
rmobile as being rmobile-related is non-sensical. The driver itself
you'll note is not called i2c-rmobile for precisely this reason.
Furthermore, there are also ARM-based SH-Mobile parts that pre-date the
R-Mobile line that also use this driver, so it's hardly an architecture
issue.
> Of course, if you think it is cramping your SH device tree style then
> we can easily add a "renesas-shmobile-iic" entry as well.
>
I obviously don't mind if you wish to use the rmobile naming convention
going forward, as the new parts have obviously dropped with the shmobile
naming convention, and it's likely you'll even be able to infer different
capabilities between rmobile vs shmobile. That's not sufficient cause to
prefer one over the other though, so you're still going to have to keep
things balanced. Simply having two aliases seems to me to be the easiest
solution.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
