[PATCH] pinctrl: aspeed: Allow changing hardware strap defaults

[PATCH] pinctrl: aspeed: Allow changing hardware strap defaults

[Zev Weiss]

Previously we've generally assumed that the defaults in the hardware
strapping register are in fact appropriate for the system and thus
have avoided making any changes to its contents (with the exception of
the bits controlling the GPIO passthrough feature).

Unfortunately, on some platforms corrections from software are
required as the hardware strapping is simply incorrect for the system
(such as the SPI1 interface being configured for passthrough mode when
master mode is in fact the only useful configuration for it).  We thus
remove the checks preventing changes to the strap register so that the
pinctrl subsystem can be used for such corrections.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 21 ---------------------
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 21 ---------------------
 drivers/pinctrl/aspeed/pinmux-aspeed.h     |  3 ---
 3 files changed, 45 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index bfed0e274643..7ecfe3e4280e 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -2556,27 +2556,6 @@ static int aspeed_g4_sig_expr_set(struct aspeed_pinmux_data *ctx,
 		if (!ctx->maps[desc->ip])
 			return -ENODEV;
 
-		/*
-		 * Strap registers are configured in hardware or by early-boot
-		 * firmware. Treat them as read-only despite that we can write
-		 * them. This may mean that certain functions cannot be
-		 * deconfigured and is the reason we re-evaluate after writing
-		 * all descriptor bits.
-		 *
-		 * Port D and port E GPIO loopback modes are the only exception
-		 * as those are commonly used with front-panel buttons to allow
-		 * normal operation of the host when the BMC is powered off or
-		 * fails to boot. Once the BMC has booted, the loopback mode
-		 * must be disabled for the BMC to control host power-on and
-		 * reset.
-		 */
-		if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1 &&
-		    !(desc->mask & (BIT(21) | BIT(22))))
-			continue;
-
-		if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
-			continue;
-
 		ret = regmap_update_bits(ctx->maps[desc->ip], desc->reg,
 					 desc->mask, val);
 
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 4c0d26606b6c..3e57e76c2eb7 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -2735,27 +2735,6 @@ static int aspeed_g5_sig_expr_set(struct aspeed_pinmux_data *ctx,
 			return PTR_ERR(map);
 		}
 
-		/*
-		 * Strap registers are configured in hardware or by early-boot
-		 * firmware. Treat them as read-only despite that we can write
-		 * them. This may mean that certain functions cannot be
-		 * deconfigured and is the reason we re-evaluate after writing
-		 * all descriptor bits.
-		 *
-		 * Port D and port E GPIO loopback modes are the only exception
-		 * as those are commonly used with front-panel buttons to allow
-		 * normal operation of the host when the BMC is powered off or
-		 * fails to boot. Once the BMC has booted, the loopback mode
-		 * must be disabled for the BMC to control host power-on and
-		 * reset.
-		 */
-		if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1 &&
-		    !(desc->mask & (BIT(21) | BIT(22))))
-			continue;
-
-		if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
-			continue;
-
 		/* On AST2500, Set bits in SCU70 are cleared from SCU7C */
 		if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1) {
 			u32 value = ~val & desc->mask;
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index aaa78a613196..e9068acd5879 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h
@@ -16,9 +16,6 @@
  * bits. Some difficulty arises as the pin's function bit masks for each
  * priority level are frequently not the same (i.e. cannot just flip a bit to
  * change from a high to low priority signal), or even in the same register.
- * Further, not all signals can be unmuxed, as some expressions depend on
- * values in the hardware strapping register (which may be treated as
- * read-only).
  *
  * SoC Multi-function Pin Expression Examples
  * ------------------------------------------
-- 
2.42.0

Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults

[Andrew Jeffery]

On Wed, 2023-10-04 at 00:16 -0700, Zev Weiss wrote:
> Previously we've generally assumed that the defaults in the hardware
> strapping register are in fact appropriate for the system and thus
> have avoided making any changes to its contents (with the exception of
> the bits controlling the GPIO passthrough feature).
> 
> Unfortunately, on some platforms corrections from software are
> required as the hardware strapping is simply incorrect for the system
> (such as the SPI1 interface being configured for passthrough mode when
> master mode is in fact the only useful configuration for it).  We thus
> remove the checks preventing changes to the strap register so that the
> pinctrl subsystem can be used for such corrections.

So the strapping for the SPI1 configuration seems to be prone to
(copy/paste?) mistakes. Is there evidence that motivates dropping all
the protection instead of poking a hole for SPI1 like we did for the
passthrough GPIOs?

I'm still a little attached to the policy that software should be
beholden to the strapping, and to try to mitigate software mistakes
given the smattering of bits required to drive the Aspeed pinmux.

Andrew

Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults

[Zev Weiss]

On Wed, Oct 04, 2023 at 06:17:50PM PDT, Andrew Jeffery wrote:
>On Wed, 2023-10-04 at 00:16 -0700, Zev Weiss wrote:
>> Previously we've generally assumed that the defaults in the hardware
>> strapping register are in fact appropriate for the system and thus
>> have avoided making any changes to its contents (with the exception of
>> the bits controlling the GPIO passthrough feature).
>>
>> Unfortunately, on some platforms corrections from software are
>> required as the hardware strapping is simply incorrect for the system
>> (such as the SPI1 interface being configured for passthrough mode when
>> master mode is in fact the only useful configuration for it).  We thus
>> remove the checks preventing changes to the strap register so that the
>> pinctrl subsystem can be used for such corrections.
>
>So the strapping for the SPI1 configuration seems to be prone to
>(copy/paste?) mistakes. Is there evidence that motivates dropping all
>the protection instead of poking a hole for SPI1 like we did for the
>passthrough GPIOs?
>
>I'm still a little attached to the policy that software should be
>beholden to the strapping, and to try to mitigate software mistakes
>given the smattering of bits required to drive the Aspeed pinmux.
>

I have no idea what else might be lurking out there so I took a broader 
(perhaps overly heavy-handed) approach, but the SPI1 mode bits are the 
only ones I've personally encountered being strapped wrong, so sure, I'd 
be fine with just extending the "hole-punch" a bit to add those bits.  
I'll send a v2 doing that shortly.


Thanks,
Zev