From: Greg KH <gregkh@linuxfoundation.org>
To: Julius Werner <jwerner@chromium.org>
Cc: Jack Rosenthal <jrosenth@chromium.org>,
LKML <linux-kernel@vger.kernel.org>,
chrome-platform@lists.linux.dev,
Stephen Boyd <swboyd@chromium.org>,
Tzung-Bi Shih <tzungbi@kernel.org>,
Guenter Roeck <groeck@chromium.org>
Subject: Re: [PATCH v12] firmware: google: Implement cbmem in sysfs driver
Date: Wed, 5 Oct 2022 08:25:25 +0200 [thread overview]
Message-ID: <Yz0jVbfDOITZfE9M@kroah.com> (raw)
In-Reply-To: <CAODwPW-7Y_CbCch+Y5unH3yJD1T=3epYvqja6w_CB-23C9x9sw@mail.gmail.com>
On Tue, Oct 04, 2022 at 06:10:01PM -0700, Julius Werner wrote:
> > > Then how does the kernel know what to print out? Why not add such a
> > > reference somewhere?
> >
> > The kernel really doesn't need to know the list of possible ids: it
> > simply reads what coreboot gives it from the coreboot tables and proxies
> > that on up to sysfs nodes.
> >
> > In an earlier version of this patch
> > (https://lore.kernel.org/chrome-platform/CAODwPW-JzXXsEANaS+6n695YqriAQ0j0LXm31R2u1OP3MhX9Uw@mail.gmail.com/T/#u),
> > I actually had this list so that the directory names were human-readable
> > instead of using the 32-bit CBMEM id, but Julius didn't like it citing
> > that we'd have to keep the kernel tree and the coreboot tree in sync.
> >
> > I'm fine with either solution ... just want to make all parties happy
> > here =)
>
> There is quite a long list of possible IDs (79 at the current count),
> many of them are just coreboot-internal implementation details for
> specific platforms that are really not interesting to the running OS
> after we're done booting, and new ones get added all the time. I don't
> think there's any practical value in trying to maintain a
> corresponding list in the kernel, it would just be unnecessary bloat
> and a maintenance nightmare to keep in sync.
>
> This whole driver is supposed to be a thin bridge between coreboot and
> coreboot-specific userspace tools. Those tools will know about the
> specific meaning of individual IDs and the data format of their
> contents, and they are much easier to keep updated and in sync with
> new coreboot releases than the kernel itself. So the whole goal of the
> design is to leave all those details to the userspace tools and have
> the kernel involved as little as possible, just passing the raw
> information through without being involved in its interpretation.
If the kernel is reporting a value, that value needs to be documented
somewhere. If the kernel is acting on that value, it needs to know what
those values are.
In this specific instance it seems that the kernel knows a subset of the
values, and some random userspace tool knows all of them? Think about
what you would want to see here if you knew nothing about this at all.
thanks,
greg k-h
next prev parent reply other threads:[~2022-10-05 6:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 0:38 [PATCH v12] firmware: google: Implement cbmem in sysfs driver Jack Rosenthal
2022-10-04 8:51 ` Greg KH
2022-10-04 16:56 ` Jack Rosenthal
2022-10-04 17:26 ` Greg KH
2022-10-04 22:56 ` Jack Rosenthal
2022-10-05 1:10 ` Julius Werner
2022-10-05 6:25 ` Greg KH [this message]
2022-10-05 23:26 ` Julius Werner
2022-10-06 6:33 ` Greg KH
2022-10-13 21:25 ` Jack Rosenthal
2022-10-14 7:24 ` Greg KH
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=Yz0jVbfDOITZfE9M@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=chrome-platform@lists.linux.dev \
--cc=groeck@chromium.org \
--cc=jrosenth@chromium.org \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swboyd@chromium.org \
--cc=tzungbi@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