From: Mark Brown <broonie@kernel.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Cheng-yi Chiang <cychiang@chromium.org>,
Guenter Roeck <linux@roeck-us.net>,
Tzung-Bi Shih <tzungbi@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ALSA development <alsa-devel@alsa-project.org>,
Hung-Te Lin <hungte@chromium.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sean Paul <seanpaul@chromium.org>,
Dylan Reid <dgreid@chromium.org>,
Tzung-Bi Shih <tzungbi@chromium.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Subject: Re: [PATCH] firmware: vpd: Add an interface to read VPD value
Date: Wed, 9 Oct 2019 14:37:09 +0100 [thread overview]
Message-ID: <20191009133709.GB3929@sirena.co.uk> (raw)
In-Reply-To: <5d9ca7e4.1c69fb81.7f8fa.3f7d@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Tue, Oct 08, 2019 at 08:14:43AM -0700, Stephen Boyd wrote:
> Quoting Cheng-yi Chiang (2019-10-07 11:50:31)
> > IMO the nvmem approach would create more complexity to support this
> > simple usage. Plus, the underlying assumption of accessing data with
> > offset in a buffer does not fit well with the already parsed VPD
> > values in a list of vpd_attrib_info. But if you strongly feel that
> > this is a better approach I can work toward this.
> I'm not sure how an ACPI system like this would work because my exposure
> to ACPI is extremely limited. I would expect there to be some sort of
> firmware property indicating that an nvmem should be used and it's
> provided by VPD or for firmware to parse VPD itself and put the
> information into the ACPI table for this device.
I fear this is optimistic. It's fairly idiomatic for ACPI for stuff
like this to be keyed off DMI information rather than integrated with
anything, basically once you get out of the bits that are explictly
standardized you're into board file territory. There is the _DSD stuff
for using DT properties in ACPI but it's had limited use AFAICT.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-09 13:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 7:16 Cheng-Yi Chiang
2019-10-07 8:03 ` Tzung-Bi Shih
2019-10-07 8:52 ` Cheng-yi Chiang
2019-10-07 12:27 ` Guenter Roeck
2019-10-07 13:58 ` Cheng-yi Chiang
2019-10-07 15:35 ` Stephen Boyd
2019-10-07 18:50 ` Cheng-yi Chiang
2019-10-08 15:14 ` Stephen Boyd
2019-10-09 13:37 ` Mark Brown [this message]
2019-10-09 14:05 ` Srinivas Kandagatla
2019-10-14 3:21 ` Cheng-yi Chiang
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=20191009133709.GB3929@sirena.co.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=cychiang@chromium.org \
--cc=dgreid@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=hungte@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=seanpaul@chromium.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=swboyd@chromium.org \
--cc=tzungbi@chromium.org \
--cc=tzungbi@google.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
all inboxes | Powered by JetHome®