From: Tan Siewert <tan@siewert.io>
To: Andrew Jeffery <andrew@codeconstruct.com.au>,
Linus Walleij <linus.walleij@linaro.org>,
Joel Stanley <joel@jms.id.au>,
linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pinctrl: aspeed: Log error if SCU protection is active
Date: Fri, 13 Jun 2025 13:32:50 +0200 [thread overview]
Message-ID: <5e748017-460c-4ff6-a86f-81cf4580684d@siewert.io> (raw)
In-Reply-To: <2cfe3813b7e330ba43f20a882c0c5035751fc7f0.camel@codeconstruct.com.au>
On 13.06.25 08:01, Andrew Jeffery wrote:
> On Thu, 2025-06-12 at 17:18 +0200, Tan Siewert wrote:
>> ASPEED pinctrl and other drivers accessing SCU registers rely on the
>> bootloader to unlock the SCU before handing over to the kernel.
>>
>> However, some userspace scripts may re-enable SCU protection via
>> /dev/mem,
>>
>
> Hmm, if this was caused by poking /dev/mem, then I'm not sure I'm in
> favour of it. The source of your problem wasn't apparent to me in our
> off-list discussion.
This was only an example of what I've already seen on GA firmware, but
it could also be done by some custom out-of-tree driver.
> "Don't do that" :/
I agree on that ^^
>> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
>> index 774f8d05142f..81680c032b3c 100644
>> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
>> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
>> @@ -28,6 +28,8 @@
>> #define SIG_EXPR_LIST_DECL_SINGLE SIG_EXPR_LIST_DECL_SESG
>> #define SIG_EXPR_LIST_DECL_DUAL SIG_EXPR_LIST_DECL_DESG
>>
>> +#define SCU_UNLOCKED_VALUE 0x00000001
>
> Bit of a nit-pick but I'm not sure this is worthwhile, or that the
> leading zeros are necessary. I'd be tempted just to use the constant
> '1' directly inline ...
This was more of a convenience to make it obvious that the "unlocked"
value is meant here (as per the datasheet). The leading zeros are
unnecessary, yes.
>> +
>> /*
>> * The "Multi-function Pins Mapping and Control" table in the SoC datasheet
>> * references registers by the device/offset mnemonic. The register macros
>> @@ -36,6 +38,7 @@
>> * reference registers beyond those dedicated to pinmux, such as the system
>> * reset control and MAC clock configuration registers.
>> */
>> +#define SCU00 0x00 /* Protection Key Register */
>> #define SCU2C 0x2C /* Misc. Control Register */
>> #define SCU3C 0x3C /* System Reset Control/Status Register */
>> #define SCU48 0x48 /* MAC Interface Clock Delay Setting */
>> @@ -2582,6 +2585,24 @@ static int aspeed_g4_sig_expr_set(struct aspeed_pinmux_data *ctx,
>> if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
>> continue;
>>
>> + /*
>> + * The SCU should be unlocked, with SCU00 returning 0x01.
>> + * However, it may have been locked, e.g. by a
>> + * userspace script using /dev/mem.
>> + */
>> + u32 value;
>> +
>> + ret = regmap_read(ctx->maps[desc->ip], SCU00, &value);
>> +
>> + if (ret < 0)
>> + return ret;
>> +
>> + if (value != SCU_UNLOCKED_VALUE) {
>
> ... i.e. `if (value != 1)` here
>
>> + dev_err(ctx->dev,
>> + "SCU protection is active, cannot continue\n");
>> + return -EPERM;
>> + }
>> +
>
> Doing this test for each value in the signal expression seems a bit
> excessive.
Ack
> I was suggesting we only print the warning if we detect the writes
> failed to stick (this is checked towards the end of e.g.
> aspeed_g4_sig_expr_set())
Ayy, thanks for pointing this out! I overlooked the
`aspeed_sig_expr_eval` check at the end which definitely suits this case.
Cheers,
Tan
prev parent reply other threads:[~2025-06-13 11:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 15:18 Tan Siewert
2025-06-13 6:01 ` Andrew Jeffery
2025-06-13 11:32 ` Tan Siewert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e748017-460c-4ff6-a86f-81cf4580684d@siewert.io \
--to=tan@siewert.io \
--cc=andrew@codeconstruct.com.au \
--cc=joel@jms.id.au \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®