mbox series

[0/2] pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5

Message ID 1540836824-4636-1-git-send-email-jacopo+renesas@jmondi.org
Headers show
Series pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5 | expand

Message

Jacopo Mondi Oct. 29, 2018, 6:13 p.m. UTC 
Hello,
   this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.

On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
could appear on different sets of pins, usually the 'a' and 'b' one.

With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:

VIN_DATA_PIN_GROUP(vin4_data_a, 8)

which results in the group being named as "vin4_data_a_8" which is
un-consistent with the canonical group names (eg. "vin4_data8_a").

This series adds a macro that allows to specify the group 'version' along with
the pin and mux numbers in patch [1/1]. I haven't been able to find a better
term than 'version' as 'group' was already taken. Suggestions welcome.

As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
wired, I made sure the macro creates correct names and fields not only by
compile testing it, but with a small C program [1] that replicates the VIN data
layout defined in the PFC module and access fields (and has helped me testing
more easily the preprocessor stringification/concatenation process).

Final note: Simon, you took the E3 patches in your tree, and I expect them to
land on v4.20-rc1. They use the old macros, are follow up patches ok?)

Thanks
   j

[1] https://paste.debian.net/1049603/

Jacopo Mondi (2):
  pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER
  pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions

 drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++++++++++++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/sh_pfc.h       |  20 ++-
 2 files changed, 269 insertions(+), 5 deletions(-)

--
2.7.4

Comments

Geert Uytterhoeven Nov. 5, 2018, 5:19 p.m. UTC | #1 
Hi Jacopo,

On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>    this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
>
> On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> could appear on different sets of pins, usually the 'a' and 'b' one.
>
> With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
>
> VIN_DATA_PIN_GROUP(vin4_data_a, 8)
>
> which results in the group being named as "vin4_data_a_8" which is
> un-consistent with the canonical group names (eg. "vin4_data8_a").
>
> This series adds a macro that allows to specify the group 'version' along with
> the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> term than 'version' as 'group' was already taken. Suggestions welcome.

Yeah, the datasheet also calls these groups :-(
A possible alternative is to use "variant"?

Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
macro varargs, and passing the "variant" as the (optional) third parameter?
That way existing users work as a before, while you can also write e.g.

    VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),

> As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> wired, I made sure the macro creates correct names and fields not only by
> compile testing it, but with a small C program [1] that replicates the VIN data
> layout defined in the PFC module and access fields (and has helped me testing
> more easily the preprocessor stringification/concatenation process).
>
> Final note: Simon, you took the E3 patches in your tree, and I expect them to
> land on v4.20-rc1. They use the old macros, are follow up patches ok?)

Which patches are using these macro names, and are in v4.20-rc1?

BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
have broken groups names on r8a7792, r8a7795, and r8a7796.
Fortunately we have no known users of them, so they can be fixed.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
Jacopo Mondi Nov. 6, 2018, 9:07 a.m. UTC | #2 
Hi Geert,

On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> >    this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> >
> > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > could appear on different sets of pins, usually the 'a' and 'b' one.
> >
> > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> >
> > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> >
> > which results in the group being named as "vin4_data_a_8" which is
> > un-consistent with the canonical group names (eg. "vin4_data8_a").
> >
> > This series adds a macro that allows to specify the group 'version' along with
> > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > term than 'version' as 'group' was already taken. Suggestions welcome.
>
> Yeah, the datasheet also calls these groups :-(
> A possible alternative is to use "variant"?
>
> Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> macro varargs, and passing the "variant" as the (optional) third parameter?
> That way existing users work as a before, while you can also write e.g.
>
>     VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),

Indeed.

Would something along the following lines fly for you?

#define VIN_DATA_PIN_GROUP(n, s, ...)					\
	{								\
		.name = #n#s#__VA_ARGS__,				\
		.pins = n##__VA_ARGS__##_pins.data##s,			\
		.mux = n##__VA_ARGS__##_mux.data##s,			\
		.nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s),	\
	}

It can be used as:
VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
VIN_DATA_PIN_GROUP(vin5_data, 8),

With your ack on this, I'll send v2.

Thanks
  j
>
> > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > wired, I made sure the macro creates correct names and fields not only by
> > compile testing it, but with a small C program [1] that replicates the VIN data
> > layout defined in the PFC module and access fields (and has helped me testing
> > more easily the preprocessor stringification/concatenation process).
> >
> > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
>
> Which patches are using these macro names, and are in v4.20-rc1?
>
> BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> have broken groups names on r8a7792, r8a7795, and r8a7796.
> Fortunately we have no known users of them, so they can be fixed.
>

On v4.20-rc1 the grep returns none for me :/
git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/

Thanks
   j

> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
Geert Uytterhoeven Nov. 6, 2018, 9:24 a.m. UTC | #3 
Hi Jacopo,

On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <jacopo@jmondi.org> wrote:
> On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > >    this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > >
> > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > >
> > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > >
> > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > >
> > > which results in the group being named as "vin4_data_a_8" which is
> > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > >
> > > This series adds a macro that allows to specify the group 'version' along with
> > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > term than 'version' as 'group' was already taken. Suggestions welcome.
> >
> > Yeah, the datasheet also calls these groups :-(
> > A possible alternative is to use "variant"?
> >
> > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > macro varargs, and passing the "variant" as the (optional) third parameter?
> > That way existing users work as a before, while you can also write e.g.
> >
> >     VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
>
> Indeed.
>
> Would something along the following lines fly for you?
>
> #define VIN_DATA_PIN_GROUP(n, s, ...)                                   \
>         {                                                               \
>                 .name = #n#s#__VA_ARGS__,                               \
>                 .pins = n##__VA_ARGS__##_pins.data##s,                  \
>                 .mux = n##__VA_ARGS__##_mux.data##s,                    \
>                 .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s),   \
>         }
>
> It can be used as:
> VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> VIN_DATA_PIN_GROUP(vin5_data, 8),
>
> With your ack on this, I'll send v2.

Thank you, that is exactly what I had in mind.

> > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > wired, I made sure the macro creates correct names and fields not only by
> > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > layout defined in the PFC module and access fields (and has helped me testing
> > > more easily the preprocessor stringification/concatenation process).
> > >
> > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> >
> > Which patches are using these macro names, and are in v4.20-rc1?
> >
> > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > Fortunately we have no known users of them, so they can be fixed.
> >
>
> On v4.20-rc1 the grep returns none for me :/
> git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/

I grepped the .o files, to make sure it would see the final strings, which
obviously works in the build tree only ;-)

For the source tree, please try:

    git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1

Gr{oetje,eeting}s,

                        Geert
Jacopo Mondi Nov. 6, 2018, 9:31 a.m. UTC | #4 
Hi Geert,

On Tue, Nov 06, 2018 at 10:24:30AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <jacopo@jmondi.org> wrote:
> > On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > > >    this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > > >
> > > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > > >
> > > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > > >
> > > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > > >
> > > > which results in the group being named as "vin4_data_a_8" which is
> > > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > > >
> > > > This series adds a macro that allows to specify the group 'version' along with
> > > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > > term than 'version' as 'group' was already taken. Suggestions welcome.
> > >
> > > Yeah, the datasheet also calls these groups :-(
> > > A possible alternative is to use "variant"?
> > >
> > > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > > macro varargs, and passing the "variant" as the (optional) third parameter?
> > > That way existing users work as a before, while you can also write e.g.
> > >
> > >     VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> >
> > Indeed.
> >
> > Would something along the following lines fly for you?
> >
> > #define VIN_DATA_PIN_GROUP(n, s, ...)                                   \
> >         {                                                               \
> >                 .name = #n#s#__VA_ARGS__,                               \
> >                 .pins = n##__VA_ARGS__##_pins.data##s,                  \
> >                 .mux = n##__VA_ARGS__##_mux.data##s,                    \
> >                 .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s),   \
> >         }
> >
> > It can be used as:
> > VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> > VIN_DATA_PIN_GROUP(vin5_data, 8),
> >
> > With your ack on this, I'll send v2.
>
> Thank you, that is exactly what I had in mind.
>
> > > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > > wired, I made sure the macro creates correct names and fields not only by
> > > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > > layout defined in the PFC module and access fields (and has helped me testing
> > > > more easily the preprocessor stringification/concatenation process).
> > > >
> > > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> > >
> > > Which patches are using these macro names, and are in v4.20-rc1?
> > >
> > > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > > Fortunately we have no known users of them, so they can be fixed.
> > >
> >
> > On v4.20-rc1 the grep returns none for me :/
> > git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
>
> I grepped the .o files, to make sure it would see the final strings, which
> obviously works in the build tree only ;-)

Ah yes, stupid me.

>
> For the source tree, please try:
>
>     git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1

Argh, there are quite a few of them, but fortunately no users so far.

Is it ok fixing them in v2 of this series with follow-up patches, or
would you like a single patch that introduces the variadic macro and
replaces all the occurrences in the per-SoC PFC modules in one go?

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
Geert Uytterhoeven Nov. 7, 2018, 8:39 a.m. UTC | #5 
Hi Jacopo,

(sorry, seems I prepared a reply, but forgot to press "Send")

On Tue, Nov 6, 2018 at 10:31 AM jacopo mondi <jacopo@jmondi.org> wrote:
> On Tue, Nov 06, 2018 at 10:24:30AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <jacopo@jmondi.org> wrote:
> > > On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > > > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > > > >    this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > > > >
> > > > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > > > >
> > > > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > > > >
> > > > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > > > >
> > > > > which results in the group being named as "vin4_data_a_8" which is
> > > > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > > > >
> > > > > This series adds a macro that allows to specify the group 'version' along with
> > > > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > > > term than 'version' as 'group' was already taken. Suggestions welcome.
> > > >
> > > > Yeah, the datasheet also calls these groups :-(
> > > > A possible alternative is to use "variant"?
> > > >
> > > > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > > > macro varargs, and passing the "variant" as the (optional) third parameter?
> > > > That way existing users work as a before, while you can also write e.g.
> > > >
> > > >     VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> > >
> > > Indeed.
> > >
> > > Would something along the following lines fly for you?
> > >
> > > #define VIN_DATA_PIN_GROUP(n, s, ...)                                   \
> > >         {                                                               \
> > >                 .name = #n#s#__VA_ARGS__,                               \
> > >                 .pins = n##__VA_ARGS__##_pins.data##s,                  \
> > >                 .mux = n##__VA_ARGS__##_mux.data##s,                    \
> > >                 .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s),   \
> > >         }
> > >
> > > It can be used as:
> > > VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> > > VIN_DATA_PIN_GROUP(vin5_data, 8),
> > >
> > > With your ack on this, I'll send v2.
> >
> > Thank you, that is exactly what I had in mind.
> >
> > > > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > > > wired, I made sure the macro creates correct names and fields not only by
> > > > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > > > layout defined in the PFC module and access fields (and has helped me testing
> > > > > more easily the preprocessor stringification/concatenation process).
> > > > >
> > > > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> > > >
> > > > Which patches are using these macro names, and are in v4.20-rc1?
> > > >
> > > > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > > > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > > > Fortunately we have no known users of them, so they can be fixed.
> > > >
> > >
> > > On v4.20-rc1 the grep returns none for me :/
> > > git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
> >
> > I grepped the .o files, to make sure it would see the final strings, which
> > obviously works in the build tree only ;-)
>
> Ah yes, stupid me.
>
> >
> > For the source tree, please try:
> >
> >     git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
>
> Argh, there are quite a few of them, but fortunately no users so far.
>
> Is it ok fixing them in v2 of this series with follow-up patches, or
> would you like a single patch that introduces the variadic macro and
> replaces all the occurrences in the per-SoC PFC modules in one go?

Given the r8a7795 and r8a7796 issues were introduced in v4.17:

    a5c2949ff7bd9e04 ("pinctrl: sh-pfc: r8a7796: Deduplicate VIN4 pin
definitions")
    9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
definitions")

while the r8a7792 issue date back to v4.9:

    7dd74bb1f058786e ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")

I think separate patches are easier for backporting.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
Jacopo Mondi Nov. 7, 2018, 9:35 a.m. UTC | #6 
Hi Geert,

On Wed, Nov 07, 2018 at 09:39:35AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> (sorry, seems I prepared a reply, but forgot to press "Send")
>
> On Tue, Nov 6, 2018 at 10:31 AM jacopo mondi <jacopo@jmondi.org> wrote:
> > On Tue, Nov 06, 2018 at 10:24:30AM +0100, Geert Uytterhoeven wrote:
> > > On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <jacopo@jmondi.org> wrote:
> > > > On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > > > > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > > > > >    this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > > > > >
> > > > > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > > > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > > > > >
> > > > > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > > > > >
> > > > > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > > > > >
> > > > > > which results in the group being named as "vin4_data_a_8" which is
> > > > > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > > > > >
> > > > > > This series adds a macro that allows to specify the group 'version' along with
> > > > > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > > > > term than 'version' as 'group' was already taken. Suggestions welcome.
> > > > >
> > > > > Yeah, the datasheet also calls these groups :-(
> > > > > A possible alternative is to use "variant"?
> > > > >
> > > > > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > > > > macro varargs, and passing the "variant" as the (optional) third parameter?
> > > > > That way existing users work as a before, while you can also write e.g.
> > > > >
> > > > >     VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> > > >
> > > > Indeed.
> > > >
> > > > Would something along the following lines fly for you?
> > > >
> > > > #define VIN_DATA_PIN_GROUP(n, s, ...)                                   \
> > > >         {                                                               \
> > > >                 .name = #n#s#__VA_ARGS__,                               \
> > > >                 .pins = n##__VA_ARGS__##_pins.data##s,                  \
> > > >                 .mux = n##__VA_ARGS__##_mux.data##s,                    \
> > > >                 .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s),   \
> > > >         }
> > > >
> > > > It can be used as:
> > > > VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> > > > VIN_DATA_PIN_GROUP(vin5_data, 8),
> > > >
> > > > With your ack on this, I'll send v2.
> > >
> > > Thank you, that is exactly what I had in mind.
> > >
> > > > > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > > > > wired, I made sure the macro creates correct names and fields not only by
> > > > > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > > > > layout defined in the PFC module and access fields (and has helped me testing
> > > > > > more easily the preprocessor stringification/concatenation process).
> > > > > >
> > > > > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > > > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> > > > >
> > > > > Which patches are using these macro names, and are in v4.20-rc1?
> > > > >
> > > > > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > > > > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > > > > Fortunately we have no known users of them, so they can be fixed.
> > > > >
> > > >
> > > > On v4.20-rc1 the grep returns none for me :/
> > > > git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
> > >
> > > I grepped the .o files, to make sure it would see the final strings, which
> > > obviously works in the build tree only ;-)
> >
> > Ah yes, stupid me.
> >
> > >
> > > For the source tree, please try:
> > >
> > >     git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
> >
> > Argh, there are quite a few of them, but fortunately no users so far.
> >
> > Is it ok fixing them in v2 of this series with follow-up patches, or
> > would you like a single patch that introduces the variadic macro and
> > replaces all the occurrences in the per-SoC PFC modules in one go?
>
> Given the r8a7795 and r8a7796 issues were introduced in v4.17:
>
>     a5c2949ff7bd9e04 ("pinctrl: sh-pfc: r8a7796: Deduplicate VIN4 pin
> definitions")
>     9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
> definitions")
>
> while the r8a7792 issue date back to v4.9:
>
>     7dd74bb1f058786e ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
>
> I think separate patches are easier for backporting.

Fine, I've sent yesterday:
"[PATCH v4 0/4] sh-pfc: Variadic VIN_DATA_PIN_GROUP macro + updates"
which includes: "pinctrl: sh-pfc: Fix VIN versioned groups name" that
changes all users of VIN_DATA_PIN_GROUP in one go.

I'll split that and re-send.

Before resending, if there are comments on:
"pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions" and
"pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions"

which are included in that very same series, I'll like to address
them before sending v5 out.

Thanks
   j

>
> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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