mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


      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®