From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Joel Stanley <joel@jms.id.au>
Cc: Arnd Bergmann <arnd@arndb.de>, Andrew Jeffery <andrew@aj.id.au>,
"Rafael J . Wysocki" <rafael@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org
Subject: Re: [PATCH 0/2] firmware: Add boot information to sysfs
Date: Tue, 1 Feb 2022 09:42:50 +0100 [thread overview]
Message-ID: <YfjyiuWBeJeHCg7q@kroah.com> (raw)
In-Reply-To: <20220201050501.182961-1-joel@jms.id.au>
On Tue, Feb 01, 2022 at 03:34:59PM +1030, Joel Stanley wrote:
> This is the second iteration of this idea. The first used socinfo
> custom attribute groups, but Arnd suggested we make this something
> standardised under /sys/firmware instead:
>
> http://lore.kernel.org/all/CAK8P3a3MRf0aGt1drkgsuZyBbeoy+S7Ha18SBM01q+3f33oL+Q@mail.gmail.com
>
> Some ARM systems have a firmware that provides a hardware root of
> trust. It's useful for the system to know how this root of trust has
> been configured, so provide a standardised interface that expose this
> information to userspace.
>
> This is implemented as a sysfs attribute group registration to be called
> at boot, with the properties described in the ABI document.
>
> Alternatively we could put the properties in the driver core, and have
> platforms register callbacks for each supported property. This would
> make it harder to insert non-standard properties, with the trade off of
> more code to selectively show supported properties.
It is trivial to selectively show properties in sysfs, the is_visible()
callback is there for this very reason.
So yes, this should be in the driver core so that we do not have random
platform values and fields that have no relation to each other at all.
For example, you could provide these fields for UEFI today, right? That
would be a good proof if this really can work for multiple systems or
not.
thanks,
greg k-h
prev parent reply other threads:[~2022-02-01 8:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 5:04 [PATCH 0/2] firmware: Add boot information to sysfs Joel Stanley
2022-02-01 5:05 ` [PATCH 1/2] firmware: Add boot information sysfs Joel Stanley
2022-02-01 5:05 ` [PATCH 2/2] ARM: aspeed: Add secure boot controller support Joel Stanley
2022-02-01 8:41 ` Greg Kroah-Hartman
2022-02-03 11:39 ` Joel Stanley
2022-02-01 8:42 ` Greg Kroah-Hartman [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=YfjyiuWBeJeHCg7q@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andrew@aj.id.au \
--cc=arnd@arndb.de \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.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