mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tzung-Bi Shih <tzungbi@google.com>
To: Dustin Howett <dustin@howett.net>
Cc: linux-kernel@vger.kernel.org, Benson Leung <bleung@chromium.org>,
	Guenter Roeck <groeck@chromium.org>
Subject: Re: [PATCH 2/2] platform/chrome: reserve only the I/O ports required for the MEC EC
Date: Wed, 26 Jan 2022 14:24:10 +0800	[thread overview]
Message-ID: <YfDpCqffa+5Zypg4@google.com> (raw)
In-Reply-To: <CA+BfgNKRNXVxLhQ2mAxiq-c3ipkFPdYoZee6myO8djmXWnfrYg@mail.gmail.com>

On Tue, Jan 25, 2022 at 09:15:45AM -0600, Dustin Howett wrote:
> On Mon, Jan 24, 2022 at 10:17 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
> >
> >
> > The original code:
> > - devm_request_region(dev, EC_LPC_ADDR_MEMMAP, ...) and then
> > - cros_ec_lpc_ops.read(EC_LPC_ADDR_MEMMAP + EC_MEMMAP_ID, ...).
> >
> > After the patch:
> > - devm_request_region(dev, EC_HOST_CMD_REGION0, ...) and then
> > - cros_ec_lpc_ops.read(EC_LPC_ADDR_MEMMAP + EC_MEMMAP_ID, ...).
> >
> > Does it work if it reads out of request_region range?
> >
> >
> > The 2 request_region are now guarded by the first "if (buf[0] != 'E' || buf[1] != 'C')".  That is, only non-MEC will request the 2 regions.
> >
> > Doesn't other MECs (e.g. non-Framework Laptop) need the 2 regions?
> 
> So, in both cases this should be legal. Here's why:
> 
> The MEC protocol multiplexes memory-mapped reads through the same 8
> I/O ports (0x800 - 0x807)
> as it does host commands. It works by adjusting the base address,
> EC_LPC_ADDR_MEMMAP (0x900),
> to 0x100 before it initiates a standard MEC LPC xfer.
> See cros_ec_lpc_mec_read_bytes line ~101 (as of 881007522c8fcc3785).
> 
> Therefore, the adjusted flow in the patch is:
> 
> 0. Default cros_ec_lpc_ops to the MEC version of read/xfer [unchanged in patch]
> 1. Request 0x800 - 0x807 (MEC region)
> 2. read() using the MEC read function (using only the above ports)
> 3. if it succeeds, great! we have a MEC EC.
> --- if it failed ---
> 4. Map the non-MEC port range 0x900 - 0x9FF for memory-mapped reads
> 5. read() using the NON-MEC read function (using ports 0x900 - 0x9FF)
> 6. if it succeeds, map the remaining host command ports 0x808 - 0x8FF
> 
> In short, only non-MEC needs the 0x900 - 0x9FF mapping for "mapped
> memory". Therefore we can defer the
> port allocation until after we've failed to read mapped memory the MEC way. :)
> 
> Based on my understanding of the MEC protocol, non-Framework Laptop
> MECs hold this invariant true as well.
> They should only need ports 0x800 - 0x807.

Thanks for the detail explanation.  After reading cros_ec_lpc_mec_read_bytes() carefully, I guess I got it.

The patch actually fixes 2 issues:
1. The original code accesses the 8 IO ports (i.e. 0x800 - 0x807) via cros_ec_lpc_mec_read_bytes(EC_LPC_ADDR_MEMMAP + EC_MEMMAP_ID, ...) without requesting the region in advance.

2. MEC variants only need to request the 8 IO ports.  However, the rest of ports (i.e. 0x808 - 0x9ff) are for non-MECs.

> Want me to send a v2 with updated commit messages?

Yes, that would be helpful.

  reply	other threads:[~2022-01-26  6:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05  3:12 [PATCH 0/2] platform/chrome: Add support for the Framework Laptop Dustin L. Howett
2022-01-05  3:12 ` [PATCH 1/2] platform/chrome: cros-ec: detect " Dustin L. Howett
2022-01-25  3:41   ` Tzung-Bi Shih
2022-01-25  4:16     ` Tzung-Bi Shih
2022-01-05  3:12 ` [PATCH 2/2] platform/chrome: reserve only the I/O ports required for the MEC EC Dustin L. Howett
2022-01-25  3:42   ` Tzung-Bi Shih
2022-01-25  4:17     ` Tzung-Bi Shih
2022-01-25 15:15       ` Dustin Howett
2022-01-26  6:24         ` Tzung-Bi Shih [this message]
2022-01-24 20:51 ` [PATCH 0/2] platform/chrome: Add support for the Framework Laptop Benson Leung
2022-01-25  1:12   ` Tzung-Bi Shih
2022-01-25 16:52     ` Guenter Roeck
2022-01-25 17:38       ` Benson Leung

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=YfDpCqffa+5Zypg4@google.com \
    --to=tzungbi@google.com \
    --cc=bleung@chromium.org \
    --cc=dustin@howett.net \
    --cc=groeck@chromium.org \
    --cc=linux-kernel@vger.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

Powered by JetHome