From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Gwendal Grignou <gwendal@chromium.org>
Cc: bleung@chromium.org, chrome-platform@lists.linux.dev,
dustin@howett.net, ben@jubnut.com
Subject: Re: [PATCH v2 2/2] platform/chrome: cros_ec_lpc: Add Support for direct EC register memory access
Date: Tue, 7 Jan 2025 03:40:16 +0000 [thread overview]
Message-ID: <Z3yiIGWEO4mOOMNP@google.com> (raw)
In-Reply-To: <20250106185232.1635556-3-gwendal@chromium.org>
On Mon, Jan 06, 2025 at 10:52:32AM -0800, Gwendal Grignou wrote:
> Add support to access EC memory region HOST command and ACPI memory
> region directly.
>
> The memory region comes from the CRS ACPI resource descriptor.
>
> Able to communicate with the EC:
> ```
> ectool version
> ...
> Build info: brtk-0.0.0-df0ad93+ 2024-12-13 19:25:55 elmo@396-a1a
> ```
Asked in v1 too: why the build info for `ectool` is important? Or is it
just an example for communicating with EC?
> Coreboot must exposed the memory region:
> ```
> cat /proc/iomem | grep GOOG0004
> fe0b0000-fe0bffff : GOOG0004:00
> ```
Asked in v1 too: `grep GOOG0004 /proc/iomem` does the same thing and should
be more concise. It's fine if you'd like to keep it.
> Can observe the commands flowing between AP and EC.
Could you provide some more context? Couldn't we see the trace without the
patch? I guess these (includes above) is just a test scenario.
If I understand the whole series correctly, it tries to support some Realtek
EC which needs to read the memory region info from ACPI instead of the
well-known ones. If so, the commit message should provide some more context
about the new way for probing.
> @@ -498,29 +555,52 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
[...]
> + if (adev) {
> + /*
> + * Retrieve the resource information in the CRS register, if available.
> + */
> + status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
> + cros_ec_lpc_resources, ec_lpc);
> + if (ACPI_FAILURE(status)) {
> + dev_err(dev, "failed to get resources\n");
> + return -ENODEV;
> + }
> + if (ec_lpc->mem32.address_length) {
> + ec_lpc->base = devm_ioremap(dev,
> + ec_lpc->mem32.address,
> + ec_lpc->mem32.address_length);
> + if (IS_ERR(ec_lpc->base))
> + return -EINVAL;
Just realized that ioremap*() doesn't return ERR but NULL. It should use
`!ec_lpc->base`.
next prev parent reply other threads:[~2025-01-07 3:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 18:52 [PATCH v2 0/2] Add support for IO memory mapped EC Gwendal Grignou
2025-01-06 18:52 ` [PATCH v2 1/2] platform/chrome: cros_ec_lpc: Merge lpc_driver_ops into ec private structure Gwendal Grignou
2025-01-06 18:52 ` [PATCH v2 2/2] platform/chrome: cros_ec_lpc: Add Support for direct EC register memory access Gwendal Grignou
2025-01-07 3:40 ` Tzung-Bi Shih [this message]
2025-01-07 17:58 ` Gwendal Grignou
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=Z3yiIGWEO4mOOMNP@google.com \
--to=tzungbi@kernel.org \
--cc=ben@jubnut.com \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=dustin@howett.net \
--cc=gwendal@chromium.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 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.