linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-i2c@vger.kernel.org, arnd@arndb.de,
	linux-sh@vger.kernel.org, w.sang@pengutronix.de, rjw@sisk.pl,
	ben-linux@fluff.org, khali@linux-fr.org
Subject: Re: [PATCH] i2c: i2c-sh_mobile device tree support
Date: Fri, 30 Mar 2012 18:03:41 +0900	[thread overview]
Message-ID: <20120330090341.GG26543@linux-sh.org> (raw)
In-Reply-To: <CANqRtoTERUznk7xYr5qHMP4X5cVbvUw9vLZ5X-6YFkmVf69m4Q@mail.gmail.com>

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@linux-sh.org> 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.

  reply	other threads:[~2012-03-30  9:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30  8:44 [PATCH] i2c: i2c-sh_mobile device tree support Magnus Damm
2012-03-30  8:47 ` Paul Mundt
     [not found]   ` <20120330084744.GF26543-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org>
2012-03-30  8:53     ` Magnus Damm
2012-03-30  9:03       ` Paul Mundt [this message]
2012-04-18 14:08         ` Wolfram Sang
     [not found]           ` <20120418140839.GD19220-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-04-19  1:41             ` Paul Mundt
2012-04-19  7:33 ` Wolfram Sang

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=20120330090341.GG26543@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=arnd@arndb.de \
    --cc=ben-linux@fluff.org \
    --cc=khali@linux-fr.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=rjw@sisk.pl \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).