[v2,1/6] pinctrl-aspeed-g5: Never set SCU90[6]

If a pin depending on bit 6 in SCU90 is requested for GPIO, the export
will succeed but changes to the GPIO's value will not be accepted by the
hardware. This is because the pinmux driver has misconfigured the SCU by
writing 1 to the reserved bit.

The description of SCU90[6] from the datasheet is 'Reserved, must keep
at value ”0”'. The fix is to switch pinmux from the bit-flipping macro
to explicitly configuring the .enable and .disable values to zero.

The patch has been tested on an AST2500 EVB.

Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Reported-by: Uma Yadlapati <yadlapat@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---

This patch should be applied for 4.9.

 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> If a pin depending on bit 6 in SCU90 is requested for GPIO, the export
> will succeed but changes to the GPIO's value will not be accepted by the
> hardware. This is because the pinmux driver has misconfigured the SCU by
> writing 1 to the reserved bit.
>
> The description of SCU90[6] from the datasheet is 'Reserved, must keep
> at value ”0”'. The fix is to switch pinmux from the bit-flipping macro
> to explicitly configuring the .enable and .disable values to zero.
>
> The patch has been tested on an AST2500 EVB.
>
> Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
> Reported-by: Uma Yadlapati <yadlapat@us.ibm.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

Reviewed-by: Joel Stanley <joel@jms.id.au>

And tested-by.

> This patch should be applied for 4.9.

In the future I think we should send fixes separately from the rest of
the series, so it's clear to Linus where we expect patches to end up.

Perhaps Linus can share his preference with us?

Cheers,

Joel


>  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index c8c72e8259d3..87b46390b695 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> @@ -26,7 +26,7 @@
>
>  #define ASPEED_G5_NR_PINS 228
>
> -#define COND1          SIG_DESC_BIT(SCU90, 6, 0)
> +#define COND1          { SCU90, BIT(6), 0, 0 }
>  #define COND2          { SCU94, GENMASK(1, 0), 0, 0 }
>
>  #define B14 0
> --
> 2.7.4
>
--
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

On Wed, Nov 2, 2016 at 3:37 PM, Andrew Jeffery <andrew@aj.id.au> wrote:

> If a pin depending on bit 6 in SCU90 is requested for GPIO, the export
> will succeed but changes to the GPIO's value will not be accepted by the
> hardware. This is because the pinmux driver has misconfigured the SCU by
> writing 1 to the reserved bit.
>
> The description of SCU90[6] from the datasheet is 'Reserved, must keep
> at value ”0”'. The fix is to switch pinmux from the bit-flipping macro
> to explicitly configuring the .enable and .disable values to zero.
>
> The patch has been tested on an AST2500 EVB.
>
> Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
> Reported-by: Uma Yadlapati <yadlapat@us.ibm.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
>
> This patch should be applied for 4.9.

Patch applied for fixes, adding Joel's review tag.

Yours,
Linus Walleij
--
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

On Thu, Nov 3, 2016 at 11:59 PM, Joel Stanley <joel@jms.id.au> wrote:

> In the future I think we should send fixes separately from the rest of
> the series, so it's clear to Linus where we expect patches to end up.
>
> Perhaps Linus can share his preference with us?

Just make it clear to me where the patch is headed, if it is
a fix or a new feature.

Also mixing stuff in big series is of course problematic because
all the CC:in on MFD patches and whatnot that I don't apply
makes the picture blurry, but sometimes it is anyways needed
for context so it is a soft requirement.

Yours,
Linus Walleij
--
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

On Mon, 2016-11-07 at 10:34 +0100, Linus Walleij wrote:
> > On Thu, Nov 3, 2016 at 11:59 PM, Joel Stanley <joel@jms.id.au> wrote:
> 
> > In the future I think we should send fixes separately from the rest of
> > the series, so it's clear to Linus where we expect patches to end up.
> > 
> > Perhaps Linus can share his preference with us?
> 
> Just make it clear to me where the patch is headed, if it is
> a fix or a new feature.
> 
> Also mixing stuff in big series is of course problematic because
> all the CC:in on MFD patches and whatnot that I don't apply
> makes the picture blurry, but sometimes it is anyways needed
> for context so it is a soft requirement.

Context was my concern here and I would otherwise have split the rest
of the patches along mfd/pinctrl boundaries. I felt the situation was
odd enough to warrant presenting the full picture.

Andrew

> 
> Yours,
> Linus Walleij