From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Dustin Howett <dustin@howett.net>
Cc: Benson Leung <bleung@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
chrome-platform@lists.linux.dev, Kieran Levin <ktl@frame.work>,
Mario Limonciello <Mario.Limonciello@amd.com>
Subject: Re: [PATCH v1 0/4] cros_ec: add support for newer versions of the Framework Laptop
Date: Mon, 27 Nov 2023 11:30:46 +0800 [thread overview]
Message-ID: <ZWQNZtcg2qTSc5ze@google.com> (raw)
In-Reply-To: <CA+BfgNL7OeqbXPGf=hk=XrTWoe0_Wv0pi95YgWw5SJjzs8EXeQ@mail.gmail.com>
On Sun, Nov 26, 2023 at 01:22:23PM -0600, Dustin Howett wrote:
> On Wed, Oct 11, 2023 at 12:29 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >
> > On Thu, Oct 05, 2023 at 11:06:57AM -0500, Dustin L. Howett wrote:
> > I don't understand the description about 0x8FF. From patches in the series,
> > it looks like 0x8FF is unused if CROS_EC_LPC_QUIRK_SHORT_HOSTCMD_RESERVATION.
>
> You're right, this is unclear.
>
> The ACPI node for [...]EC0 only claims to use 0x800 to 0x8FE -
> *however*, the EC does use 0x8FF!
> The bug is only in the ACPI table.
> The quirk is used so that devm_request_region doesn't fail
> because it would try to reserve up to 0x8FF.
I am not familiar to ACPI, so this may be a dumb question: if the bug is in
the ACPI table, is it possible to correct the table to claim to use 0x800
to 0x8FF?
> I have been considering a different form for this quirk.
> Right now, it means "do not reserve 0x8ff, but continue to USE 0x8ff".
> Perhaps "ignore devm_request_region failures" is a better quirk? It
> felt too broad.
Either way is suboptimal to me.
next prev parent reply other threads:[~2023-11-27 3:30 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 16:06 [PATCH v1 0/4] cros_ec: add support for newer versions of the Framework Laptop Dustin L. Howett
2023-10-05 16:06 ` [PATCH v1 1/4] cros_ec_lpc: introduce cros_ec_lpc, a priv struct for the lpc device Dustin L. Howett
2023-10-11 5:29 ` Tzung-Bi Shih
2023-10-05 16:07 ` [PATCH v1 2/4] cros_ec_lpc: pass driver_data from DMI down to the device Dustin L. Howett
2023-10-11 5:29 ` Tzung-Bi Shih
2023-10-05 16:07 ` [PATCH v1 3/4] cros_ec_lpc: add a quirks system, and propagate quirks from DMI Dustin L. Howett
2023-10-11 5:30 ` Tzung-Bi Shih
2023-11-16 23:17 ` Thomas Weißschuh
2023-10-05 16:07 ` [PATCH v1 4/4] cros_ec_lpc: add quirks for the Framework Laptop Dustin L. Howett
2023-10-05 18:45 ` Mario Limonciello
2023-10-11 5:30 ` Tzung-Bi Shih
2023-10-11 5:29 ` [PATCH v1 0/4] cros_ec: add support for newer versions of " Tzung-Bi Shih
2023-11-26 19:22 ` Dustin Howett
2023-11-27 3:30 ` Tzung-Bi Shih [this message]
2023-11-26 19:24 ` [PATCH v2 0/4] platform/chrome: cros_ec_lpc: add support for AMD Framework Laptops Dustin L. Howett
2023-11-26 19:24 ` [PATCH v2 1/4] platform/chrome: cros_ec_lpc: introduce a priv struct for the lpc device Dustin L. Howett
2023-11-26 19:24 ` [PATCH v2 2/4] platform/chrome: cros_ec_lpc: pass driver_data from DMI to the device Dustin L. Howett
2023-11-26 19:24 ` [PATCH v2 3/4] platform/chrome: cros_ec_lpc: add a "quirks" system Dustin L. Howett
2023-11-27 3:30 ` Tzung-Bi Shih
2023-11-26 19:24 ` [PATCH v2 4/4] platform/chrome: cros_ec_lpc: add quirks for the Framework Laptop (AMD) Dustin L. Howett
2023-12-23 11:33 ` [PATCH v2 0/4] platform/chrome: cros_ec_lpc: add support for AMD Framework Laptops Thomas Weißschuh
2024-04-03 0:47 ` [PATCH v3 " Dustin L. Howett
2024-04-03 0:47 ` [PATCH v3 1/4] platform/chrome: cros_ec_lpc: introduce a priv struct for the lpc device Dustin L. Howett
2024-04-03 0:47 ` [PATCH v3 2/4] platform/chrome: cros_ec_lpc: pass driver_data from DMI to the device Dustin L. Howett
2024-04-03 0:47 ` [PATCH v3 3/4] platform/chrome: cros_ec_lpc: add a "quirks" system Dustin L. Howett
2024-04-03 0:47 ` [PATCH v3 4/4] platform/chrome: cros_ec_lpc: add quirks for the Framework Laptop (AMD) Dustin L. Howett
2024-04-04 18:53 ` [PATCH v3 0/4] platform/chrome: cros_ec_lpc: add support for AMD Framework Laptops Thomas Weißschuh
2024-04-04 18:59 ` Dustin Howett
2024-04-04 19:57 ` Thomas Weißschuh
2024-04-05 1:02 ` Dustin Howett
2024-04-06 18:48 ` Mario Limonciello
2024-04-06 19:23 ` Mario Limonciello
2024-04-08 9:30 ` patchwork-bot+chrome-platform
2024-04-08 9:30 ` patchwork-bot+chrome-platform
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=ZWQNZtcg2qTSc5ze@google.com \
--to=tzungbi@kernel.org \
--cc=Mario.Limonciello@amd.com \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=dustin@howett.net \
--cc=groeck@chromium.org \
--cc=ktl@frame.work \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.