From: Brian Norris <briannorris@chromium.org>
To: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: bleung@chromium.org, groeck@chromium.org,
chrome-platform@lists.linux.dev, guillaume.tucker@collabora.com,
denys.f@collabora.com, ricardo.canuelo@collabora.com,
usama.anjum@collabora.com
Subject: Re: [PATCH] platform/chrome: chromeos_acpi: print hex string for ACPI_TYPE_BUFFER
Date: Tue, 1 Aug 2023 14:53:31 -0700 [thread overview]
Message-ID: <ZMl+2+mr7AiIx7e1@google.com> (raw)
In-Reply-To: <ZMh82LaanrHh+33t@google.com>
On Tue, Aug 01, 2023 at 11:32:40AM +0800, Tzung-Bi Shih wrote:
> On Wed, Jul 26, 2023 at 03:31:27PM +0800, Tzung-Bi Shih wrote:
> > `element->buffer.pointer` should be binary blob. `%s` doesn't work perfect
> > for them.
> >
> > Print hex string for ACPI_TYPE_BUFFER.
> >
> > Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
>
> Curious about does this patch make sense to folks on the mailing list?
Since you asked.... (sorry if the questions are dumb; I'm not extremely
familiar with this one)
Are there any ABI concerns here? As in, did this perhaps work for some
use cases that will be broken now by this change in format? If not, it
would be nice to note your thought process on that. [1]
Also, is it possible to use some standard formatting, like
hex_dump_to_buffer()?
Or, would it make more sense to make these into binary attributes
(struct bin_attribute)?
NB: the docs (Documentation/ABI/testing/sysfs-driver-chromeos-acpi)
suggest that some attributes (like VDAT) are indeed binary, and so we
should probably maintain or fix that.
Brian
[1] My guess: no real user space actually uses this driver yet, since
ChromiumOS still has its own downstream variant on its active kernels?
next prev parent reply other threads:[~2023-08-01 21:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 7:31 [PATCH] platform/chrome: chromeos_acpi: print hex string for ACPI_TYPE_BUFFER Tzung-Bi Shih
2023-08-01 3:32 ` Tzung-Bi Shih
2023-08-01 21:53 ` Brian Norris [this message]
2023-08-02 10:06 ` Tzung-Bi Shih
2023-08-02 18:59 ` Brian Norris
2023-08-03 1:18 ` Tzung-Bi Shih
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=ZMl+2+mr7AiIx7e1@google.com \
--to=briannorris@chromium.org \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=denys.f@collabora.com \
--cc=groeck@chromium.org \
--cc=guillaume.tucker@collabora.com \
--cc=ricardo.canuelo@collabora.com \
--cc=tzungbi@kernel.org \
--cc=usama.anjum@collabora.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