openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Zev Weiss <zev@bewilderbeest.net>
To: Ryan Chen <ryan_chen@aspeedtech.com>
Cc: Andrew Jeffery <andrew@aj.id.au>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	Joel Stanley <joel@jms.id.au>,
	Ian Woloschin <ian.woloschin@akamai.com>
Subject: Re: [PATCH u-boot v2019.04-aspeed-openbmc v2] aspeed: add CONFIG_ASPEED_ENABLE_BACKDOORS
Date: Mon, 18 Apr 2022 17:59:30 -0700	[thread overview]
Message-ID: <Yl4JcpZNvPQWcL3C@hatter.bewilderbeest.net> (raw)
In-Reply-To: <TY2PR06MB33910DF8FDDE1072646911B4F2EE9@TY2PR06MB3391.apcprd06.prod.outlook.com>

On Fri, Apr 15, 2022 at 01:11:09AM PDT, Ryan Chen wrote:
>Hello,
>	Thanks your response.
>	And yes, I prefer apply patch without any config to disable it.
>
>Ryan
>

After thinking about this a bit more, I remembered that Ian Woloschin 
(CCed) had mentioned at some point that the systems he works with do in 
fact use the AST2500's built-in Super-IO, and hence would presumably be 
broken by a patch that unconditionally disabled that.  And in contrast, 
the ASRock boards I've been working with require the AST2500 Super-IO to 
be disabled for the host to boot properly, so it seems like we'll need  
*some* minimal amount of configurability to support at least those two 
classes of systems (i.e. a Kconfig boolean that determines whether the 
Super-IO should be enabled or disabled).

I don't know offhand what the interactions between SCU70[20], HICRB[6], 
and HICR5[10] are though, and I don't have any hardware that actually 
uses the AST2500 Super-IO to test with.  Would leaving SCU70[20]=0 to 
enable the Super-IO while leaving HICRB[6]=1 and HICR5[10]=0 work for 
systems like Ian's to enable the Super-IO while keeping everything else 
locked down as much as possible?


Zev


  reply	other threads:[~2022-04-19  1:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 22:40 [PATCH u-boot v2019.04-aspeed-openbmc v2] aspeed: add CONFIG_ASPEED_ENABLE_BACKDOORS Zev Weiss
2022-04-15  3:21 ` Ryan Chen
2022-04-15  8:03   ` Zev Weiss
2022-04-15  8:11     ` Ryan Chen
2022-04-19  0:59       ` Zev Weiss [this message]
2022-04-19  2:32         ` Ryan Chen
2022-04-19 11:10           ` Woloschin, Ian

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=Yl4JcpZNvPQWcL3C@hatter.bewilderbeest.net \
    --to=zev@bewilderbeest.net \
    --cc=andrew@aj.id.au \
    --cc=ian.woloschin@akamai.com \
    --cc=joel@jms.id.au \
    --cc=openbmc@lists.ozlabs.org \
    --cc=ryan_chen@aspeedtech.com \
    /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;
as well as URLs for NNTP newsgroup(s).