[PATCH v2 1/2] pinctrl: renesas: Make sure the pin type is updated after setting the MUX

Prabhakar Mahadev Lad prabhakar.mahadev-lad.rj at bp.renesas.com
Sun Nov 15 18:01:16 CET 2020


Hi Marek,

Thank you for the review.

> -----Original Message-----
> From: Marek Vasut <marex at denx.de>
> Sent: 15 November 2020 13:18
> To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj at bp.renesas.com>; Simon Glass <sjg at chromium.org>;
> Masahiro Yamada <yamada.masahiro at socionext.com>; u-boot at lists.denx.de
> Cc: Adam Ford <aford173 at gmail.com>; Tom Rini <trini at konsulko.com>; Prabhakar
> <prabhakar.csengg at gmail.com>; Biju Das <biju.das.jz at bp.renesas.com>
> Subject: Re: [PATCH v2 1/2] pinctrl: renesas: Make sure the pin type is updated after setting the MUX
> 
> On 11/6/20 7:01 PM, Lad Prabhakar wrote:
> > By default on startup all the pin types are configured to
> > PINMUX_TYPE_NONE (in sh_pfc_map_pins()), when pin is set as GPIO the
> > pin type is updated to PINMUX_TYPE_GPIO. But the type is not updated
> > when the pin is set as a function in sh_pfc_pinctrl_pin_set() or
> > sh_pfc_pinctrl_group_set() calls (these calls only set the MUX if
> > the pin type is PINMUX_TYPE_NONE ie unused).
> >
> > So with the current implementation pin functionality could be overwritten
> > silently, for example if the same pin is added for SPI and serial.
> 
> Shouldn't the pinctrl core rather warn about such a collision and abort?
>
As mentioned in the commit message this does fix the pin functionality from being overwritten (ie it aborts). Ill post a v3 adding a warning message.

Cheers,
Prabhakar



More information about the U-Boot mailing list