pinctrl: sh-pfc: r8a7796: Add group for AVB MDIO and MII pins

Submitted by Geert Uytterhoeven on April 20, 2017, 9:49 a.m.

Details

Message ID 1492681746-20005-1-git-send-email-geert+renesas@glider.be
State New
Headers show

Commit Message

Geert Uytterhoeven April 20, 2017, 9:49 a.m.
Group the AVB pins into similar groups as found in other sh-pfc drivers.
The pins can not be muxed between functions other than AVB, but their
drive strengths can be controlled.

The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio on
other SoCs.  In pfc-r8a7796 the avb_mdc group already existed and is in
use in DT. Therefore add the ADV_MDIO pin to the existing group instead
of renaming it.

Based on commit b25719eb938eb39a ("pinctrl: sh-pfc: r8a7795: Add group
for AVB MDIO and MII pins").

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
To be queued up in sh-pfc-for-v4.13.

 drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

Comments

Laurent Pinchart April 20, 2017, 10:02 a.m.
Hi Geert,

Thank you for the patch.

On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
> Group the AVB pins into similar groups as found in other sh-pfc drivers.
> The pins can not be muxed between functions other than AVB, but their
> drive strengths can be controlled.
> 
> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio on
> other SoCs.  In pfc-r8a7796 the avb_mdc group already existed and is in
> use in DT. Therefore add the ADV_MDIO pin to the existing group instead
> of renaming it.

This clearly shows that we need a few kernel releases to test PFC-related code 
and DT before we can commit to an ABI. How do you think we should handle this 
?

> Based on commit b25719eb938eb39a ("pinctrl: sh-pfc: r8a7795: Add group
> for AVB MDIO and MII pins").
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> To be queued up in sh-pfc-for-v4.13.
> 
>  drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 30 +++++++++++++++++++++++++++---
>  1 file changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c index
> b0362ae707e2e59a..b9c3d9d7ca75023f 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
> @@ -1605,11 +1605,33 @@ static const unsigned int avb_phy_int_mux[] = {
>  	AVB_PHY_INT_MARK,
>  };
>  static const unsigned int avb_mdc_pins[] = {
> -	/* AVB_MDC */
> -	RCAR_GP_PIN(2, 9),
> +	/* AVB_MDC, AVB_MDIO */
> +	RCAR_GP_PIN(2, 9), PIN_NUMBER('A', 9),
>  };
>  static const unsigned int avb_mdc_mux[] = {
> -	AVB_MDC_MARK,
> +	AVB_MDC_MARK, AVB_MDIO_MARK,
> +};
> +static const unsigned int avb_mii_pins[] = {
> +	/*
> +	 * AVB_TX_CTL, AVB_TXC, AVB_TD0,
> +	 * AVB_TD1, AVB_TD2, AVB_TD3,
> +	 * AVB_RX_CTL, AVB_RXC, AVB_RD0,
> +	 * AVB_RD1, AVB_RD2, AVB_RD3,
> +	 * AVB_TXCREFCLK
> +	 */
> +	PIN_NUMBER('A', 8), PIN_NUMBER('A', 19), PIN_NUMBER('A', 18),
> +	PIN_NUMBER('B', 18), PIN_NUMBER('A', 17), PIN_NUMBER('B', 17),
> +	PIN_NUMBER('A', 16), PIN_NUMBER('B', 19), PIN_NUMBER('A', 13),
> +	PIN_NUMBER('B', 13), PIN_NUMBER('A', 14), PIN_NUMBER('B', 14),
> +	PIN_NUMBER('A', 12),
> +
> +};
> +static const unsigned int avb_mii_mux[] = {
> +	AVB_TX_CTL_MARK, AVB_TXC_MARK, AVB_TD0_MARK,
> +	AVB_TD1_MARK, AVB_TD2_MARK, AVB_TD3_MARK,
> +	AVB_RX_CTL_MARK, AVB_RXC_MARK, AVB_RD0_MARK,
> +	AVB_RD1_MARK, AVB_RD2_MARK, AVB_RD3_MARK,
> +	AVB_TXCREFCLK_MARK,
>  };
>  static const unsigned int avb_avtp_pps_pins[] = {
>  	/* AVB_AVTP_PPS */
> @@ -3381,6 +3403,7 @@ static const struct sh_pfc_pin_group pinmux_groups[] =
> { SH_PFC_PIN_GROUP(avb_magic),
>  	SH_PFC_PIN_GROUP(avb_phy_int),
>  	SH_PFC_PIN_GROUP(avb_mdc),
> +	SH_PFC_PIN_GROUP(avb_mii),
>  	SH_PFC_PIN_GROUP(avb_avtp_pps),
>  	SH_PFC_PIN_GROUP(avb_avtp_match_a),
>  	SH_PFC_PIN_GROUP(avb_avtp_capture_a),
> @@ -3627,6 +3650,7 @@ static const char * const avb_groups[] = {
>  	"avb_magic",
>  	"avb_phy_int",
>  	"avb_mdc",
> +	"avb_mii",
>  	"avb_avtp_pps",
>  	"avb_avtp_match_a",
>  	"avb_avtp_capture_a",
Geert Uytterhoeven April 20, 2017, 10:11 a.m.
Hi Laurent,

On Thu, Apr 20, 2017 at 12:02 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
>> Group the AVB pins into similar groups as found in other sh-pfc drivers.
>> The pins can not be muxed between functions other than AVB, but their
>> drive strengths can be controlled.
>>
>> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio on
>> other SoCs.  In pfc-r8a7796 the avb_mdc group already existed and is in
>> use in DT. Therefore add the ADV_MDIO pin to the existing group instead
>> of renaming it.
>
> This clearly shows that we need a few kernel releases to test PFC-related code
> and DT before we can commit to an ABI. How do you think we should handle this
> ?

That's a difficult question ;-)

For now I'd like to treat R-Car M3-W the same as H3.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Laurent Pinchart April 20, 2017, 10:18 a.m.
Hi Geert,

On Thursday 20 Apr 2017 12:11:41 Geert Uytterhoeven wrote:
> On Thu, Apr 20, 2017 at 12:02 PM, Laurent Pinchart wrote:
> > On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
> >> Group the AVB pins into similar groups as found in other sh-pfc drivers.
> >> The pins can not be muxed between functions other than AVB, but their
> >> drive strengths can be controlled.
> >> 
> >> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio on
> >> other SoCs.  In pfc-r8a7796 the avb_mdc group already existed and is in
> >> use in DT. Therefore add the ADV_MDIO pin to the existing group instead
> >> of renaming it.
> > 
> > This clearly shows that we need a few kernel releases to test PFC-related
> > code and DT before we can commit to an ABI. How do you think we should
> > handle this ?
> 
> That's a difficult question ;-)
> 
> For now I'd like to treat R-Car M3-W the same as H3.

I still believe we should introduce some kind of unstable period for DT 
bindings, during which they will be merged in mainline but still subject to 
modification. It could just be a few kernel releases.
Geert Uytterhoeven April 20, 2017, 11:40 a.m.
Hi Laurent,

(this time reply to all)

On Thu, Apr 20, 2017 at 12:18 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 20 Apr 2017 12:11:41 Geert Uytterhoeven wrote:
>> On Thu, Apr 20, 2017 at 12:02 PM, Laurent Pinchart wrote:
>> > On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
>> >> Group the AVB pins into similar groups as found in other sh-pfc drivers.
>> >> The pins can not be muxed between functions other than AVB, but their
>> >> drive strengths can be controlled.
>> >>
>> >> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio on
>> >> other SoCs.  In pfc-r8a7796 the avb_mdc group already existed and is in
>> >> use in DT. Therefore add the ADV_MDIO pin to the existing group instead
>> >> of renaming it.
>> >
>> > This clearly shows that we need a few kernel releases to test PFC-related
>> > code and DT before we can commit to an ABI. How do you think we should
>> > handle this ?
>>
>> That's a difficult question ;-)
>>
>> For now I'd like to treat R-Car M3-W the same as H3.
>
> I still believe we should introduce some kind of unstable period for DT
> bindings, during which they will be merged in mainline but still subject to
> modification. It could just be a few kernel releases.

Like, from v4.4 (when avb_mdc was added for H3) until v4.12 (earliest
we can correct this)?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Laurent Pinchart April 20, 2017, 11:44 a.m.
Hi Geert,

On Thursday 20 Apr 2017 13:37:27 Geert Uytterhoeven wrote:
> On Thu, Apr 20, 2017 at 12:18 PM, Laurent Pinchart wrote:
> > On Thursday 20 Apr 2017 12:11:41 Geert Uytterhoeven wrote:
> >> On Thu, Apr 20, 2017 at 12:02 PM, Laurent Pinchart wrote:
> >>> On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
> >>>> Group the AVB pins into similar groups as found in other sh-pfc
> >>>> drivers. The pins can not be muxed between functions other than AVB,
> >>>> but their drive strengths can be controlled.
> >>>> 
> >>>> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio
> >>>> on other SoCs. In pfc-r8a7796 the avb_mdc group already existed and is
> >>>> in use in DT. Therefore add the ADV_MDIO pin to the existing group
> >>>> instead of renaming it.
> >>> 
> >>> This clearly shows that we need a few kernel releases to test
> >>> PFC-related code and DT before we can commit to an ABI. How do you
> >>> think we should handle this ?
> >> 
> >> That's a difficult question 
> >> 
> >> For now I'd like to treat R-Car M3-W the same as H3.
> > 
> > I still believe we should introduce some kind of unstable period for DT
> > bindings, during which they will be merged in mainline but still subject
> > to modification. It could just be a few kernel releases.
> 
> Like, from v4.4 (when avb_mdc was added for H3) until v4.12 (earliest
> we can correct this)?

Sorry, I misread you, I thought that H3 named the group mdio (you might want 
to clarify this in the commit message). I was referring to when M3 PFC support 
was introduced, which was v4.10, so that's just two releases. We obviously 
can't rename mdc to mdio on H3 if we want to keep backward compatibility.
Geert Uytterhoeven April 20, 2017, 11:47 a.m.
Hi Laurent,

On Thu, Apr 20, 2017 at 1:44 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 20 Apr 2017 13:37:27 Geert Uytterhoeven wrote:
>> On Thu, Apr 20, 2017 at 12:18 PM, Laurent Pinchart wrote:
>> > On Thursday 20 Apr 2017 12:11:41 Geert Uytterhoeven wrote:
>> >> On Thu, Apr 20, 2017 at 12:02 PM, Laurent Pinchart wrote:
>> >>> On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
>> >>>> Group the AVB pins into similar groups as found in other sh-pfc
>> >>>> drivers. The pins can not be muxed between functions other than AVB,
>> >>>> but their drive strengths can be controlled.
>> >>>>
>> >>>> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio
>> >>>> on other SoCs. In pfc-r8a7796 the avb_mdc group already existed and is
>> >>>> in use in DT. Therefore add the ADV_MDIO pin to the existing group
>> >>>> instead of renaming it.
>> >>>
>> >>> This clearly shows that we need a few kernel releases to test
>> >>> PFC-related code and DT before we can commit to an ABI. How do you
>> >>> think we should handle this ?
>> >>
>> >> That's a difficult question
>> >>
>> >> For now I'd like to treat R-Car M3-W the same as H3.
>> >
>> > I still believe we should introduce some kind of unstable period for DT
>> > bindings, during which they will be merged in mainline but still subject
>> > to modification. It could just be a few kernel releases.
>>
>> Like, from v4.4 (when avb_mdc was added for H3) until v4.12 (earliest
>> we can correct this)?
>
> Sorry, I misread you, I thought that H3 named the group mdio (you might want
> to clarify this in the commit message). I was referring to when M3 PFC support

Sorry, this was a bit unclear (I reused the description from the H3 patch).
This was actually referring to R-Car Gen2. Will fix.

> was introduced, which was v4.10, so that's just two releases. We obviously
> can't rename mdc to mdio on H3 if we want to keep backward compatibility.

And because of pin-compatibility and board sharing of H3 and M3-W, I
want both to use identical group naming.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Niklas Söderlund May 2, 2017, 2:33 p.m.
Hi Geert and Laurent,

On 2017-04-20 13:47:19 +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
> 
> On Thu, Apr 20, 2017 at 1:44 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Thursday 20 Apr 2017 13:37:27 Geert Uytterhoeven wrote:
> >> On Thu, Apr 20, 2017 at 12:18 PM, Laurent Pinchart wrote:
> >> > On Thursday 20 Apr 2017 12:11:41 Geert Uytterhoeven wrote:
> >> >> On Thu, Apr 20, 2017 at 12:02 PM, Laurent Pinchart wrote:
> >> >>> On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
> >> >>>> Group the AVB pins into similar groups as found in other 
> >> >>>> sh-pfc
> >> >>>> drivers. The pins can not be muxed between functions other than AVB,
> >> >>>> but their drive strengths can be controlled.
> >> >>>>
> >> >>>> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio
> >> >>>> on other SoCs. In pfc-r8a7796 the avb_mdc group already existed and is
> >> >>>> in use in DT. Therefore add the ADV_MDIO pin to the existing group
> >> >>>> instead of renaming it.
> >> >>>
> >> >>> This clearly shows that we need a few kernel releases to test
> >> >>> PFC-related code and DT before we can commit to an ABI. How do you
> >> >>> think we should handle this ?
> >> >>
> >> >> That's a difficult question
> >> >>
> >> >> For now I'd like to treat R-Car M3-W the same as H3.
> >> >
> >> > I still believe we should introduce some kind of unstable period for DT
> >> > bindings, during which they will be merged in mainline but still subject
> >> > to modification. It could just be a few kernel releases.
> >>
> >> Like, from v4.4 (when avb_mdc was added for H3) until v4.12 (earliest
> >> we can correct this)?
> >
> > Sorry, I misread you, I thought that H3 named the group mdio (you might want
> > to clarify this in the commit message). I was referring to when M3 PFC support
> 
> Sorry, this was a bit unclear (I reused the description from the H3 patch).
> This was actually referring to R-Car Gen2. Will fix.
> 
> > was introduced, which was v4.10, so that's just two releases. We obviously
> > can't rename mdc to mdio on H3 if we want to keep backward compatibility.
> 
> And because of pin-compatibility and board sharing of H3 and M3-W, I
> want both to use identical group naming.

I also think it's a benefit if the group names are identical on H3 and 
M3-W. And I think it is unfortunate that the name do not match Gen2 
naming.

When adding the pins to r8a7795 I thought of instead adding AVB_MDIO to 
the group avb_mdc add a new group with the Gen2 naming (avb_mdio) and 
add both AVB_MDC and AVB_MDIO to this group but still also keep the 
group avb_mdc. If I had done that it would be compatible with Gen2 
naming and backward compatible with old H3 DT. Maybe I was wrong of not 
doing it like this and perhaps that solution should be revisited? That 
is keep avb_mdc as is on H3 for backward compatibility but add avb_mdio to 
both H3 and M3-W and update H3 DT to use avb_mdio.

In any case I reviewed the pins as it is identical to how it's done on 
H3. So if you choose to move forward with this approach feel free to 
add:

Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

> 
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Geert Uytterhoeven May 11, 2017, 8:49 a.m.
On Tue, May 2, 2017 at 4:33 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> On 2017-04-20 13:47:19 +0200, Geert Uytterhoeven wrote:
>> On Thu, Apr 20, 2017 at 1:44 PM, Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>> > On Thursday 20 Apr 2017 13:37:27 Geert Uytterhoeven wrote:
>> >> On Thu, Apr 20, 2017 at 12:18 PM, Laurent Pinchart wrote:
>> >> > On Thursday 20 Apr 2017 12:11:41 Geert Uytterhoeven wrote:
>> >> >> On Thu, Apr 20, 2017 at 12:02 PM, Laurent Pinchart wrote:
>> >> >>> On Thursday 20 Apr 2017 11:49:06 Geert Uytterhoeven wrote:
>> >> >>>> Group the AVB pins into similar groups as found in other
>> >> >>>> sh-pfc
>> >> >>>> drivers. The pins can not be muxed between functions other than AVB,
>> >> >>>> but their drive strengths can be controlled.
>> >> >>>>
>> >> >>>> The group avb_mdc containing ADV_MDC and ADV_MDIO is called avb_mdio
>> >> >>>> on other SoCs. In pfc-r8a7796 the avb_mdc group already existed and is
>> >> >>>> in use in DT. Therefore add the ADV_MDIO pin to the existing group
>> >> >>>> instead of renaming it.
>> >> >>>
>> >> >>> This clearly shows that we need a few kernel releases to test
>> >> >>> PFC-related code and DT before we can commit to an ABI. How do you
>> >> >>> think we should handle this ?
>> >> >>
>> >> >> That's a difficult question
>> >> >>
>> >> >> For now I'd like to treat R-Car M3-W the same as H3.
>> >> >
>> >> > I still believe we should introduce some kind of unstable period for DT
>> >> > bindings, during which they will be merged in mainline but still subject
>> >> > to modification. It could just be a few kernel releases.
>> >>
>> >> Like, from v4.4 (when avb_mdc was added for H3) until v4.12 (earliest
>> >> we can correct this)?
>> >
>> > Sorry, I misread you, I thought that H3 named the group mdio (you might want
>> > to clarify this in the commit message). I was referring to when M3 PFC support
>>
>> Sorry, this was a bit unclear (I reused the description from the H3 patch).
>> This was actually referring to R-Car Gen2. Will fix.
>>
>> > was introduced, which was v4.10, so that's just two releases. We obviously
>> > can't rename mdc to mdio on H3 if we want to keep backward compatibility.
>>
>> And because of pin-compatibility and board sharing of H3 and M3-W, I
>> want both to use identical group naming.
>
> I also think it's a benefit if the group names are identical on H3 and
> M3-W. And I think it is unfortunate that the name do not match Gen2
> naming.
>
> When adding the pins to r8a7795 I thought of instead adding AVB_MDIO to
> the group avb_mdc add a new group with the Gen2 naming (avb_mdio) and
> add both AVB_MDC and AVB_MDIO to this group but still also keep the
> group avb_mdc. If I had done that it would be compatible with Gen2
> naming and backward compatible with old H3 DT. Maybe I was wrong of not
> doing it like this and perhaps that solution should be revisited? That
> is keep avb_mdc as is on H3 for backward compatibility but add avb_mdio to
> both H3 and M3-W and update H3 DT to use avb_mdio.

We can do that later... For now I like to move forward with M3-W like H3.

> In any case I reviewed the pins as it is identical to how it's done on
> H3. So if you choose to move forward with this approach feel free to
> add:
>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

Thanks, applied to sh-pfc-for-v4.13 with reference to R-Car Gen2 SoC
and Reviewed-by.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch hide | download patch | download mbox

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
index b0362ae707e2e59a..b9c3d9d7ca75023f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
@@ -1605,11 +1605,33 @@  static const unsigned int avb_phy_int_mux[] = {
 	AVB_PHY_INT_MARK,
 };
 static const unsigned int avb_mdc_pins[] = {
-	/* AVB_MDC */
-	RCAR_GP_PIN(2, 9),
+	/* AVB_MDC, AVB_MDIO */
+	RCAR_GP_PIN(2, 9), PIN_NUMBER('A', 9),
 };
 static const unsigned int avb_mdc_mux[] = {
-	AVB_MDC_MARK,
+	AVB_MDC_MARK, AVB_MDIO_MARK,
+};
+static const unsigned int avb_mii_pins[] = {
+	/*
+	 * AVB_TX_CTL, AVB_TXC, AVB_TD0,
+	 * AVB_TD1, AVB_TD2, AVB_TD3,
+	 * AVB_RX_CTL, AVB_RXC, AVB_RD0,
+	 * AVB_RD1, AVB_RD2, AVB_RD3,
+	 * AVB_TXCREFCLK
+	 */
+	PIN_NUMBER('A', 8), PIN_NUMBER('A', 19), PIN_NUMBER('A', 18),
+	PIN_NUMBER('B', 18), PIN_NUMBER('A', 17), PIN_NUMBER('B', 17),
+	PIN_NUMBER('A', 16), PIN_NUMBER('B', 19), PIN_NUMBER('A', 13),
+	PIN_NUMBER('B', 13), PIN_NUMBER('A', 14), PIN_NUMBER('B', 14),
+	PIN_NUMBER('A', 12),
+
+};
+static const unsigned int avb_mii_mux[] = {
+	AVB_TX_CTL_MARK, AVB_TXC_MARK, AVB_TD0_MARK,
+	AVB_TD1_MARK, AVB_TD2_MARK, AVB_TD3_MARK,
+	AVB_RX_CTL_MARK, AVB_RXC_MARK, AVB_RD0_MARK,
+	AVB_RD1_MARK, AVB_RD2_MARK, AVB_RD3_MARK,
+	AVB_TXCREFCLK_MARK,
 };
 static const unsigned int avb_avtp_pps_pins[] = {
 	/* AVB_AVTP_PPS */
@@ -3381,6 +3403,7 @@  static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(avb_magic),
 	SH_PFC_PIN_GROUP(avb_phy_int),
 	SH_PFC_PIN_GROUP(avb_mdc),
+	SH_PFC_PIN_GROUP(avb_mii),
 	SH_PFC_PIN_GROUP(avb_avtp_pps),
 	SH_PFC_PIN_GROUP(avb_avtp_match_a),
 	SH_PFC_PIN_GROUP(avb_avtp_capture_a),
@@ -3627,6 +3650,7 @@  static const char * const avb_groups[] = {
 	"avb_magic",
 	"avb_phy_int",
 	"avb_mdc",
+	"avb_mii",
 	"avb_avtp_pps",
 	"avb_avtp_match_a",
 	"avb_avtp_capture_a",