linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linus Walleij <linus.walleij@linaro.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH] pinctrl: sh-pfc: r8a7791: grand I2C rename
Date: Mon, 3 Apr 2017 06:14:10 -0400	[thread overview]
Message-ID: <20170403101409.GD31988@verge.net.au> (raw)
In-Reply-To: <CAMuHMdXa+y9mJsMD9v4o9AOxyp__2LZmqpAR7=4PG3x_7pSQDw@mail.gmail.com>

On Fri, Mar 31, 2017 at 01:01:04PM +0200, Geert Uytterhoeven wrote:
> Hi Sergei,
> 
> On Thu, Mar 30, 2017 at 6:53 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > The R8A7791 PFC driver  was apparently based on the preliminary revisions
> > of  the  user's manual, which called all the I2C signals {SCL|SDA}<n> and
> > MOD_SEL register fields SEL_IIC<n> without making a difference between two
> > types of the I2C controllers used. The recent manual calls the signals
> > {I2C|IIC}<n>_{SCL|SDA> and the MOD_SEL fields SEL_{I2C|IIC}<n> finally
> > making this difference. Follow the suit, also renaming the I2C{7|8} pin
> > arrays and groups/functions (luckily, they haven't been used so far).
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> Thanks for your patch!
> 
> >  drivers/pinctrl/sh-pfc/pfc-r8a7791.c |  521 +++++++++++++++++------------------
> >  1 file changed, 264 insertions(+), 257 deletions(-)
> >
> > Index: linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
> > ===================================================================
> > --- linux-pinctrl.orig/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
> > +++ linux-pinctrl/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
> > @@ -119,22 +119,22 @@ enum {
> >         /* IPSR0 */
> >         FN_D0, FN_D1, FN_D2, FN_D3, FN_D4, FN_D5, FN_D6, FN_D7, FN_D8,
> >         FN_D9, FN_D10, FN_D11, FN_D12, FN_D13, FN_D14, FN_D15,
> > -       FN_A0, FN_ATAWR0_N_C, FN_MSIOF0_SCK_B, FN_SCL0_C, FN_PWM2_B,
> > +       FN_A0, FN_ATAWR0_N_C, FN_MSIOF0_SCK_B, FN_I2C0_SCL_C, FN_PWM2_B,
> 
> While I have no issue with renaming internal definitions...
> 
> > @@ -4507,12 +4514,12 @@ static const struct sh_pfc_pin_group pin
> >         SH_PFC_PIN_GROUP(i2c4),
> >         SH_PFC_PIN_GROUP(i2c4_b),
> >         SH_PFC_PIN_GROUP(i2c4_c),
> > -       SH_PFC_PIN_GROUP(i2c7),
> > -       SH_PFC_PIN_GROUP(i2c7_b),
> > -       SH_PFC_PIN_GROUP(i2c7_c),
> > -       SH_PFC_PIN_GROUP(i2c8),
> > -       SH_PFC_PIN_GROUP(i2c8_b),
> > -       SH_PFC_PIN_GROUP(i2c8_c),
> > +       SH_PFC_PIN_GROUP(iic0),
> > +       SH_PFC_PIN_GROUP(iic0_b),
> > +       SH_PFC_PIN_GROUP(iic0_c),
> > +       SH_PFC_PIN_GROUP(iic1),
> > +       SH_PFC_PIN_GROUP(iic1_b),
> > +       SH_PFC_PIN_GROUP(iic1_c),
> 
> I do object against renaming the user-visible names, like pin groups...
> 
> > @@ -5298,8 +5305,8 @@ static const struct sh_pfc_function pinm
> >         SH_PFC_FUNCTION(i2c2),
> >         SH_PFC_FUNCTION(i2c3),
> >         SH_PFC_FUNCTION(i2c4),
> > -       SH_PFC_FUNCTION(i2c7),
> > -       SH_PFC_FUNCTION(i2c8),
> > +       SH_PFC_FUNCTION(iic0),
> > +       SH_PFC_FUNCTION(iic1),
> 
> ... and pin functions. Technically, they are part of the DT bindings,
> and thus are not allowed to change.
> 
> IMHO either the user-visible names should be left alone, or the new names
> should be added as alternatives, next to the existing names.
> 
> What do other people think?

I think that any user-visible changes need to have a very strong reason.

  parent reply	other threads:[~2017-04-03 10:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 16:53 [PATCH] pinctrl: sh-pfc: r8a7791: grand I2C rename Sergei Shtylyov
2017-03-31 11:01 ` Geert Uytterhoeven
2017-04-03  7:30   ` Geert Uytterhoeven
2017-04-03 10:14   ` Simon Horman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-04-07 20:02 Sergei Shtylyov
2017-04-07 20:10 ` Sergei Shtylyov
2017-04-19  9:49 ` Geert Uytterhoeven

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=20170403101409.GD31988@verge.net.au \
    --to=horms@verge.net.au \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    /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).