Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[jacopo mondi]

Hi Tony,

On 06/02/2017 19:28, Tony Lindgren wrote:

* jacopo mondi  [170206 10:16]:

Currently there is no generic pinctrl and pinmux function to retrieve a
group or function by name, but only by their id (selector).
It would take 10minutes to add them, but I wonder if that's desirable or
there are other ways to do so I haven't found out yet.

Linus, Tony and gpio people: do you have opinions on this? I can add those
functions to core/pinmux in my next patch series if I get your ack here.


I would just get rid of the names and allow optionally configuring them
from the consumer. Just like we do for interrupts and GPIOs.



Mostly, I wonder why so far nobody had to remove function and groups and 
release their associated data when deleting a map. It makes me think 
this is not required or I didn't fully get dt_free_map() purpose :/
Or, put it in another way, I see lot of code releasing memory associated 
with PIN_MAP_TYPE_CONFIGS_GROUP map types (as map.data.configs.configs 
it's easy accessible), but none releasing data associated to 
PIN_MAP_TYPE_MUX_GROUP map types...


Thanks
   j



Regards,

Tony

Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Tony Lindgren]

* jacopo mondi  [170206 10:16]:
> Currently there is no generic pinctrl and pinmux function to retrieve a
> group or function by name, but only by their id (selector).
> It would take 10minutes to add them, but I wonder if that's desirable or
> there are other ways to do so I haven't found out yet.
> 
> Linus, Tony and gpio people: do you have opinions on this? I can add those
> functions to core/pinmux in my next patch series if I get your ack here.

I would just get rid of the names and allow optionally configuring them
from the consumer. Just like we do for interrupts and GPIOs.

Regards,

Tony

Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[jacopo mondi]

Hi Laurent,

On 01/02/2017 16:21, Laurent Pinchart wrote:

Hi Jacopo,


[snip]



+}
+
+/**
+ * rz_dt_node_to_map() - Parse device tree nodes and collect pins, groups
and
+ *  functions


I don't think we have groups and functions, do we ?



Sort of.. The hardware does not have that, but we create them from pin 
configuration sub-nodes, as the pinmux core API is sort of 
group/function centric (see the pinmux_ops.set_mux function prototype)


[snip]


+   mutex_lock(_pinctrl->mutex);


This seems weird. The pinctrl generic functions indeed state that the 
caller

must take care of locking, but there doesn't seem to be any lock protecting
races between .dt_node_to_map() calling the generic functions below, and 
the

generic .get_group_*() handlers.


+   ret = pinctrl_generic_add_group(pctldev, grpname, grpins, npins,

NULL);

+   if (ret) {
+   mutex_unlock(_pinctrl->mutex);
+   goto free_map;
+   }
+
+   ret = pinmux_generic_add_function(pctldev, grpname, fngrps,
+ 1, mux_modes);
+   if (ret) {
+   mutex_unlock(_pinctrl->mutex);
+   goto free_map;
+   }
+   mutex_unlock(_pinctrl->mutex);


radix trees are RCU protected structures, so no locking should be 
required when accessing them from different places, so I guess lock here 
is just to protect the num_groups and num_functions variables in core 
pin controller driver...


[snip]


+/**
+ * rz_dt_free_map()
+ */
+static void rz_dt_free_map(struct pinctrl_dev *pctldev,
+  struct pinctrl_map *map, unsigned int num_maps)
+{
+   struct rz_pinctrl_dev *rz_pinctrl = pinctrl_dev_get_drvdata(pctldev);
+
+   devm_kfree(rz_pinctrl->dev, map);


Shouldn't you also free the other allocated pieces of memory (fngrps,
mux_modes and grpins) ?



That's an interesting one. If I have to free all data associated with 
that map (and I assume so) I shall be able to retrieve groups and 
functions that map represents and delete them and


Currently there is no generic pinctrl and pinmux function to retrieve a 
group or function by name, but only by their id (selector).
It would take 10minutes to add them, but I wonder if that's desirable or 
there are other ways to do so I haven't found out yet.


Linus, Tony and gpio people: do you have opinions on this? I can add 
those functions to core/pinmux in my next patch series if I get your ack 
here.


Thanks
   j

Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Wednesday 25 Jan 2017 19:09:43 Jacopo Mondi wrote:
> Add core module for per-pin Renesas RZ series pin controller.
> The core module allows SoC driver to register their pins and SoC
> specific operations and interfaces with pinctrl and pinmux core on their
> behalf.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/pinctrl/Kconfig |   1 +
>  drivers/pinctrl/Makefile|   1 +
>  drivers/pinctrl/rz-pfc/Kconfig  |  18 ++
>  drivers/pinctrl/rz-pfc/Makefile |   1 +
>  drivers/pinctrl/rz-pfc/pinctrl-rz.c | 447 
>  drivers/pinctrl/rz-pfc/pinctrl-rz.h | 114 +
>  6 files changed, 582 insertions(+)
>  create mode 100644 drivers/pinctrl/rz-pfc/Kconfig
>  create mode 100644 drivers/pinctrl/rz-pfc/Makefile
>  create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rz.c
>  create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rz.h

As Chris pointed out, s/rz-pfc/renesas/ would be a good idea. This code isn't 
specific to RZ chips (even if it's only used by them at the moment), so the rz 
prefix and suffix should probably replaced with something else (in file names 
and in the code too).

[snip]

> diff --git a/drivers/pinctrl/rz-pfc/Kconfig b/drivers/pinctrl/rz-pfc/Kconfig
> new file mode 100644
> index 000..3714c10
> --- /dev/null
> +++ b/drivers/pinctrl/rz-pfc/Kconfig
> @@ -0,0 +1,18 @@
> +#
> +# Renesas RZ pinctrl drivers
> +#
> +
> +if ARCH_RENESAS
> +
> +config PINCTRL_RZ_PINCTRL

You can add a

depends on ARCH_RENESAS

to replace the above if. It should actually be

depends on ARCH_RENESAS || COMPILE_TEST

to extend compile-test coverage. An even better option could be to drop the 
depends line completely, and replace def_bool with bool. That way the option 
will only be enabled if explicitly selected by another option (as done in 
patch 2/5).

> + select PINMUX
> + select PINCONF
> + select GPIOLIB
> + select GENERIC_PINCONF
> + select GENERIC_PINMUX_FUNCTIONS
> + select GENERIC_PINCTRL_GROUPS
> + def_bool y

Won't this enable the driver by default on all platforms, while only RZ needs 
it ? It's also customary to have the bool/tristate line as the very first line 
in the config option.

> + help
> +   This enables pin control drivers for Renesas RZ platforms
> +
> +endif

[snip]

> diff --git a/drivers/pinctrl/rz-pfc/pinctrl-rz.c
> b/drivers/pinctrl/rz-pfc/pinctrl-rz.c new file mode 100644
> index 000..3efbf03
> --- /dev/null
> +++ b/drivers/pinctrl/rz-pfc/pinctrl-rz.c
> @@ -0,0 +1,447 @@
> +/*
> + * Pinctrl support for Renesas RZ Series
> + *
> + * Copyright (C) 2017 Jacopo Mondi
> + * Copyright (C) 2017 Renesas Electronics Corporation
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +

No need for a blank line here.

> +#include 
> +#include 
> +#include 
> +

Or here.

> +#include 
> +#include 
> +#include 
> +
> +#include "../core.h"
> +#include "../devicetree.h"
> +#include "../pinmux.h"
> +
> +#include "pinctrl-rz.h"
> +
> +#define DRIVER_NAME  "rz-pinctrl"
> +#define RZ_PIN_ARGS_COUNT3
> +
> +/**
> + * rz_pinctrl_pos_to_index() - Retrieve the index of pin at position
> [bank:pin]
> + *
> + * This can be improved, as it walks all the pins reported by the SoC
> driver
> + *
> + * @return: pin number between [0 - npins]; -1 if not found
> + */
> +static int rz_pinctrl_pos_to_index(struct rz_pinctrl_dev *rz_pinctrl,
> +unsigned int bank, unsigned int pin)
> +{
> + struct rz_pinctrl_info *info;
> + struct rz_pin_desc *rz_pin;
> + int i, npins;

i and npins are never negative, you can make them unsigned int. One variable 
declaration per line is also preferred.

> +
> + info = rz_pinctrl->info;

You can move this to the variable declaration line.

> + npins = info->npins;
> + for (i = 0; i < npins; ++i) {

You can drop the npins variable and use info->npins directly.

> + rz_pin = >pins[i];
> +
> + /*
> +  * return the pin index in the array, not the pin number,
> +  * so that we can access it easily when muxing group's pins

Please start sentences with a capital letter and end them with a period.

> +  */
> + if (rz_pin->bank == bank && rz_pin->pin == pin)
> + return i;
> + }
> +
> + return -1;

How about -EINVAL ? -1 is -EPERM, which would not be an appropriate error code 
if you end up leaking it to upper layers.

> +}
> +
> +/* 
> + * pinctrl operations
> + */
> +static void rz_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file
> *s,
> + 

Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Laurent Pinchart]

Hi Chris,

On Tuesday 31 Jan 2017 13:48:57 Chris Brandt wrote:
> On  Tuesday, January 31, 2017, Jacopo Mondi wrote:
> >> Since one of the benefits of using devm_kzalloc is that if the probe
> >> fails and returns an error, all the memory associated with that device
> >> will automatically get freed, you 'might' not need this code to free
> >> memory.
> >> 
> >> I say might because I'm not sure if returning an error here will kill
> >> the driver or not. But, might be interesting to look into.
> > 
> > No, returning an error here would not kill the driver BUT if
> > dt_node_to_map fails, dt_free_map is called immediately later [1]
> > 
> > So here we maybe should not use device managed memory as it does not bring
> > anything, do not free *map as it is freed later in dt_free_map, but
> > release fngrps mux_modes and grpins, as we lose reference to them outside
> > the scope of this function.
> > 
> > Do you agree?
> 
> Like you said, there is no benefit one way of the other.
> 
> But, doing a grep of the pinctrl directory, devm_kzalloc is used more by
> the other drivers than kzalloc, so maybe we just stick with devm_kzalloc
> 
>(baah goes the sheep)

Given that the devm_*() functions incur an overhead, let's use kzalloc/kfree 
directly.

-- 
Regards,

Laurent Pinchart

RE: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Chris Brandt]

Hi Jacopo,

On  Tuesday, January 31, 2017, Jacopo Mondi wrote:
> > Since one of the benefits of using devm_kzalloc is that if the probe
> > fails and returns an error, all the memory associated with that device
> > will automatically get freed, you 'might' not need this code to free
> > memory.
> >
> > I say might because I'm not sure if returning an error here will kill
> > the driver or not. But, might be interesting to look into.
> >
> 
> No, returning an error here would not kill the driver BUT if
> dt_node_to_map fails, dt_free_map is called immediately later [1]
> 
> So here we maybe should not use device managed memory as it does not bring
> anything, do not free *map as it is freed later in dt_free_map, but
> release fngrps mux_modes and grpins, as we lose reference to them outside
> the scope of this function.
> 
> Do you agree?

Like you said, there is no benefit one way of the other.

But, doing a grep of the pinctrl directory, devm_kzalloc is used more by
the other drivers than kzalloc, so maybe we just stick with devm_kzalloc

   (baah goes the sheep)


Chris



> -Original Message-
> From: jacopo mondi [mailto:jac...@jmondi.org]
> Sent: Tuesday, January 31, 2017 4:01 AM
> To: Chris Brandt <chris.bra...@renesas.com>; Jacopo Mondi
> <jacopo+rene...@jmondi.org>; laurent.pinch...@ideasonboard.com;
> geert+rene...@glider.be; linus.wall...@linaro.org
> Cc: linux-renesas-soc@vger.kernel.org; linux-g...@vger.kernel.org
> Subject: Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module
> 
> Hi Chris,
> 
> On 30/01/2017 20:19, Chris Brandt wrote:
> > Hi Jacopo,
> >
> > On Wednesday, January 25, 2017, Jacopo Mondi wrote:
> >> +
> >> +  return 0;
> >> +
> >> +free_map:
> >> +  devm_kfree(rz_pinctrl->dev, *map);
> >> +free_fngrps:
> >> +  devm_kfree(rz_pinctrl->dev, fngrps);
> >> +free_pins:
> >> +  devm_kfree(rz_pinctrl->dev, mux_modes);
> >> +  devm_kfree(rz_pinctrl->dev, grpins);
> >> +  return ret;
> >> +}
> >
> > Since one of the benefits of using devm_kzalloc is that if the probe
> > fails and returns an error, all the memory associated with that device
> > will automatically get freed, you 'might' not need this code to free
> > memory.
> >
> > I say might because I'm not sure if returning an error here will kill
> > the driver or not. But, might be interesting to look into.
> >
> 
> No, returning an error here would not kill the driver BUT if
> dt_node_to_map fails, dt_free_map is called immediately later [1]
> 
> So here we maybe should not use device managed memory as it does not bring
> anything, do not free *map as it is freed later in dt_free_map, but
> release fngrps mux_modes and grpins, as we lose reference to them outside
> the scope of this function.
> 
> Do you agree?
> 
> >
> 
> >> +#define RZ_PIN_NAME(bank, pin)
> >> \
> >> +  PIN_##bank##_##pin
> >> +
> >> +#define RZ_PIN_DESC(b, p) \
> >> +  { .number = RZ_PIN_NAME(b, p),  \
> >> +.name = __stringify(RZ_PIN_NAME(b, p)),   \
> >
> > The hardware manual uses the names "P1_0" for ports, so it might be
> > better to match that format for consistency.
> >
> >
> 
> Noted
> 
> Thanks
> j
> 
> 
> [1] http://lxr.free-electrons.com/source/drivers/pinctrl/devicetree.c#L236
> 

Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[jacopo mondi]

Hi Chris,

On 30/01/2017 20:19, Chris Brandt wrote:

Hi Jacopo,

On Wednesday, January 25, 2017, Jacopo Mondi wrote:

+
+   return 0;
+
+free_map:
+   devm_kfree(rz_pinctrl->dev, *map);
+free_fngrps:
+   devm_kfree(rz_pinctrl->dev, fngrps);
+free_pins:
+   devm_kfree(rz_pinctrl->dev, mux_modes);
+   devm_kfree(rz_pinctrl->dev, grpins);
+   return ret;
+}


Since one of the benefits of using devm_kzalloc is that if
the probe fails and returns an error, all the memory associated with
that device will automatically get freed, you 'might' not
need this code to free memory.

I say might because I'm not sure if returning an error here will
kill the driver or not. But, might be interesting to look into.



No, returning an error here would not kill the driver BUT if 
dt_node_to_map fails, dt_free_map is called immediately later [1]


So here we maybe should not use device managed memory as it does not 
bring anything, do not free *map as it is freed later in dt_free_map, 
but release fngrps mux_modes and grpins, as we lose reference to them 
outside the scope of this function.


Do you agree?






+#define RZ_PIN_NAME(bank, pin) \
+   PIN_##bank##_##pin
+
+#define RZ_PIN_DESC(b, p)  \
+   { .number = RZ_PIN_NAME(b, p),  \
+ .name = __stringify(RZ_PIN_NAME(b, p)),   \


The hardware manual uses the names "P1_0" for ports, so it might
be better to match that format for consistency.




Noted

Thanks
   j


[1] http://lxr.free-electrons.com/source/drivers/pinctrl/devicetree.c#L236

RE: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Chris Brandt]

Hi Jacopo,

On Wednesday, January 25, 2017, Jacopo Mondi wrote:
> +
> + return 0;
> +
> +free_map:
> + devm_kfree(rz_pinctrl->dev, *map);
> +free_fngrps:
> + devm_kfree(rz_pinctrl->dev, fngrps);
> +free_pins:
> + devm_kfree(rz_pinctrl->dev, mux_modes);
> + devm_kfree(rz_pinctrl->dev, grpins);
> + return ret;
> +}

Since one of the benefits of using devm_kzalloc is that if
the probe fails and returns an error, all the memory associated with
that device will automatically get freed, you 'might' not
need this code to free memory.

I say might because I'm not sure if returning an error here will
kill the driver or not. But, might be interesting to look into.


> +#define RZ_PIN_NAME(bank, pin)   
> \
> + PIN_##bank##_##pin
> +
> +#define RZ_PIN_DESC(b, p)\
> + { .number = RZ_PIN_NAME(b, p),  \
> +   .name = __stringify(RZ_PIN_NAME(b, p)),   \

The hardware manual uses the names "P1_0" for ports, so it might
be better to match that format for consistency.


Chris

Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Jan 25, 2017 at 7:09 PM, Jacopo Mondi  wrote:
> Add core module for per-pin Renesas RZ series pin controller.
> The core module allows SoC driver to register their pins and SoC
> specific operations and interfaces with pinctrl and pinmux core on their
> behalf.
>
> Signed-off-by: Jacopo Mondi 

I believe nothing besides the DT property "renesas-rz,pins" and the value
of the RZ_PIN_ARGS_COUNT macro is really specific to Renesas or RZ(A)?
So this could become something really generic, and part of core pinctrl?

> --- /dev/null
> +++ b/drivers/pinctrl/rz-pfc/pinctrl-rz.c
> @@ -0,0 +1,447 @@

> +#define RZ_PIN_ARGS_COUNT  3

This should be a parameter in the SoC-specific subdriver.

> +/**
> + * rz_pinctrl_pos_to_index() - Retrieve the index of pin at position 
> [bank:pin]
> + *
> + * This can be improved, as it walks all the pins reported by the SoC driver
> + *
> + * @return: pin number between [0 - npins]; -1 if not found
> + */
> +static int rz_pinctrl_pos_to_index(struct rz_pinctrl_dev *rz_pinctrl,
> +  unsigned int bank, unsigned int pin)
> +{
> +   struct rz_pinctrl_info *info;
> +   struct rz_pin_desc *rz_pin;

const

> +   int i, npins;

unsigned int

> +/* 
> 
> + * pinctrl operations
> + */
> +static void rz_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,

const ... pctldev

> +   unsigned int pin)
> +{
> +   struct rz_pinctrl_dev *rz_pinctrl;
> +   struct rz_pinctrl_info *info;

const

> +static int rz_dt_node_to_map(struct pinctrl_dev *pctldev,
> +struct device_node *np_config,
> +struct pinctrl_map **map, unsigned int *num_maps)
> +{

> +   fngrps = devm_kzalloc(rz_pinctrl->dev, sizeof(*fngrps), GFP_KERNEL);
> +   if (unlikely(!fngrps)) {

Please don't use unlikely.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

RE: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Chris Brandt]

Hi Jacopo,

On Thursday, January 26, 2017, jacopo mondi wrote:
> > I think we should try to avoid the rz naming as much as possible since
> > this driver will hopefully be useful for other future Renesas devices
> > if they move to a similar pin-control type method. Maybe future "R-car"
> SoCs?
> > Or, maybe Renesas Marketing decides to come up with a new name for SoCs.
> >
> > Otherwise, you could end up with a directly like "mach-shmobile"
> > filled with a bunch of...well...not SH-Mobile parts.
> >
> > Maybe just
> >   drivers/pinctrl/renesas/pinctrl-renesas.c
> >
> 
> Wouldn't this be confusing, as most of renesas SoC are supported through
> drivers/pinctrl/sh-pfc instead?

It's already confusing that a bunch of ARM parts use a "sh" pin controller.

In reality, any Renesas device could be a peripheral mix of ex-Mitsubishi,
ex-Hitachi, ex-NEC or Renesas original. Or, some IP was licensed from a 3rd
party (ie, the SDHI/TMIO controller).
The only thing consistent is "Renesas".

> I agree on dropping the rz name, if more SoC will come and join the pin-
> based PFC realm...

I will suggest it for the next generation of SoCs, so we'll see what happens...

Thanks,
Chris

Re: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[jacopo mondi]

Hi Chris,

On 26/01/2017 03:58, Chris Brandt wrote:

Hi Jacopo,

On Wednesday, January 25, 2017, Jacopo Mondi wrote:

 drivers/pinctrl/Kconfig |   1 +
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/rz-pfc/Kconfig  |  18 ++
 drivers/pinctrl/rz-pfc/Makefile |   1 +
 drivers/pinctrl/rz-pfc/pinctrl-rz.c | 447

 drivers/pinctrl/rz-pfc/pinctrl-rz.h | 114 +
 6 files changed, 582 insertions(+)
 create mode 100644 drivers/pinctrl/rz-pfc/Kconfig  create mode 100644
drivers/pinctrl/rz-pfc/Makefile  create mode 100644 drivers/pinctrl/rz-
pfc/pinctrl-rz.c
 create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rz.h




I think we should try to avoid the rz naming as much as possible since
this driver will hopefully be useful for other future Renesas devices if
they move to a similar pin-control type method. Maybe future "R-car" SoCs?
Or, maybe Renesas Marketing decides to come up with a new name for SoCs.

Otherwise, you could end up with a directly like "mach-shmobile" filled
with a bunch of...well...not SH-Mobile parts.

Maybe just
  drivers/pinctrl/renesas/pinctrl-renesas.c



Wouldn't this be confusing, as most of renesas SoC are supported through 
drivers/pinctrl/sh-pfc instead?


I agree on dropping the rz name, if more SoC will come and join the 
pin-based PFC realm...


Thanks
   j






Chris

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Chris Brandt]

Hi Jacopo,

On Wednesday, January 25, 2017, Jacopo Mondi wrote:
>  drivers/pinctrl/Kconfig |   1 +
>  drivers/pinctrl/Makefile|   1 +
>  drivers/pinctrl/rz-pfc/Kconfig  |  18 ++
>  drivers/pinctrl/rz-pfc/Makefile |   1 +
>  drivers/pinctrl/rz-pfc/pinctrl-rz.c | 447
> 
>  drivers/pinctrl/rz-pfc/pinctrl-rz.h | 114 +
>  6 files changed, 582 insertions(+)
>  create mode 100644 drivers/pinctrl/rz-pfc/Kconfig  create mode 100644
> drivers/pinctrl/rz-pfc/Makefile  create mode 100644 drivers/pinctrl/rz-
> pfc/pinctrl-rz.c
>  create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rz.h



I think we should try to avoid the rz naming as much as possible since
this driver will hopefully be useful for other future Renesas devices if
they move to a similar pin-control type method. Maybe future "R-car" SoCs?
Or, maybe Renesas Marketing decides to come up with a new name for SoCs.

Otherwise, you could end up with a directly like "mach-shmobile" filled
with a bunch of...well...not SH-Mobile parts.

Maybe just
  drivers/pinctrl/renesas/pinctrl-renesas.c



Chris

[RFC 1/5] pinctrl: rz-pfc: Add Renesas RZ pinctrl core module

[Jacopo Mondi]

Add core module for per-pin Renesas RZ series pin controller.
The core module allows SoC driver to register their pins and SoC
specific operations and interfaces with pinctrl and pinmux core on their
behalf.

Signed-off-by: Jacopo Mondi 
---
 drivers/pinctrl/Kconfig |   1 +
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/rz-pfc/Kconfig  |  18 ++
 drivers/pinctrl/rz-pfc/Makefile |   1 +
 drivers/pinctrl/rz-pfc/pinctrl-rz.c | 447 
 drivers/pinctrl/rz-pfc/pinctrl-rz.h | 114 +
 6 files changed, 582 insertions(+)
 create mode 100644 drivers/pinctrl/rz-pfc/Kconfig
 create mode 100644 drivers/pinctrl/rz-pfc/Makefile
 create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rz.c
 create mode 100644 drivers/pinctrl/rz-pfc/pinctrl-rz.h

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af..6d72e58 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -294,6 +294,7 @@ source "drivers/pinctrl/mvebu/Kconfig"
 source "drivers/pinctrl/nomadik/Kconfig"
 source "drivers/pinctrl/pxa/Kconfig"
 source "drivers/pinctrl/qcom/Kconfig"
+source "drivers/pinctrl/rz-pfc/Kconfig"
 source "drivers/pinctrl/samsung/Kconfig"
 source "drivers/pinctrl/sh-pfc/Kconfig"
 source "drivers/pinctrl/spear/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f43..96e7ece 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_PINCTRL_MVEBU)   += mvebu/
 obj-y  += nomadik/
 obj-$(CONFIG_PINCTRL_PXA)  += pxa/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_PINCTRL_RZ_PINCTRL)   += rz-pfc/
 obj-$(CONFIG_PINCTRL_SAMSUNG)  += samsung/
 obj-$(CONFIG_PINCTRL_SH_PFC)   += sh-pfc/
 obj-$(CONFIG_PINCTRL_SPEAR)+= spear/
diff --git a/drivers/pinctrl/rz-pfc/Kconfig b/drivers/pinctrl/rz-pfc/Kconfig
new file mode 100644
index 000..3714c10
--- /dev/null
+++ b/drivers/pinctrl/rz-pfc/Kconfig
@@ -0,0 +1,18 @@
+#
+# Renesas RZ pinctrl drivers
+#
+
+if ARCH_RENESAS
+
+config PINCTRL_RZ_PINCTRL
+   select PINMUX
+   select PINCONF
+   select GPIOLIB
+   select GENERIC_PINCONF
+   select GENERIC_PINMUX_FUNCTIONS
+   select GENERIC_PINCTRL_GROUPS
+   def_bool y
+   help
+ This enables pin control drivers for Renesas RZ platforms
+
+endif
diff --git a/drivers/pinctrl/rz-pfc/Makefile b/drivers/pinctrl/rz-pfc/Makefile
new file mode 100644
index 000..cba8283
--- /dev/null
+++ b/drivers/pinctrl/rz-pfc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PINCTRL_RZ_PINCTRL)   += pinctrl-rz.o
diff --git a/drivers/pinctrl/rz-pfc/pinctrl-rz.c 
b/drivers/pinctrl/rz-pfc/pinctrl-rz.c
new file mode 100644
index 000..3efbf03
--- /dev/null
+++ b/drivers/pinctrl/rz-pfc/pinctrl-rz.c
@@ -0,0 +1,447 @@
+/*
+ * Pinctrl support for Renesas RZ Series
+ *
+ * Copyright (C) 2017 Jacopo Mondi
+ * Copyright (C) 2017 Renesas Electronics Corporation
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "../core.h"
+#include "../devicetree.h"
+#include "../pinmux.h"
+
+#include "pinctrl-rz.h"
+
+#define DRIVER_NAME"rz-pinctrl"
+#define RZ_PIN_ARGS_COUNT  3
+
+/**
+ * rz_pinctrl_pos_to_index() - Retrieve the index of pin at position [bank:pin]
+ *
+ * This can be improved, as it walks all the pins reported by the SoC driver
+ *
+ * @return: pin number between [0 - npins]; -1 if not found
+ */
+static int rz_pinctrl_pos_to_index(struct rz_pinctrl_dev *rz_pinctrl,
+  unsigned int bank, unsigned int pin)
+{
+   struct rz_pinctrl_info *info;
+   struct rz_pin_desc *rz_pin;
+   int i, npins;
+
+   info = rz_pinctrl->info;
+   npins = info->npins;
+   for (i = 0; i < npins; ++i) {
+   rz_pin = >pins[i];
+
+   /*
+* return the pin index in the array, not the pin number,
+* so that we can access it easily when muxing group's pins
+*/
+   if (rz_pin->bank == bank && rz_pin->pin == pin)
+   return i;
+   }
+
+   return -1;
+}
+
+/* 
+ * pinctrl operations
+ */
+static void rz_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
+   unsigned int pin)
+{
+   struct rz_pinctrl_dev *rz_pinctrl;
+   struct rz_pinctrl_info *info;
+
+   rz_pinctrl = pinctrl_dev_get_drvdata(pctldev);
+   info = rz_pinctrl->info;
+
+   seq_printf(s, "%s %s\n", info->pins[pin].name, DRIVER_NAME);
+}
+
+/**
+ * rz_dt_node_to_map() - Parse device tree nodes