mbox series

[v1,0/4] cros_ec: add support for newer versions of the Framework Laptop

Message ID 20231005160701.19987-1-dustin@howett.net (mailing list archive)
Headers show
Series cros_ec: add support for newer versions of the Framework Laptop | expand

Message

Dustin Howett Oct. 5, 2023, 4:06 p.m. UTC
This patch series adds support for newer models of the Framework Laptop (both
13" and 16").

Currently-shipping models of the Framework Laptop use a Microchip embedded
controller that conforms to the MEC EC protocol -- that is, data and host
command exchanges occur on I/O ports 0x800 to 0x807 (inclusive). Newer models
have switched to an NPCX embedded controller, which uses the original Chrome EC
"Linear" memory-mapped I/O model.

However, those devices move the MMIO region for EC memory from the original
Chrome EC port range of 0x900-0x9FF to 0xE00-0xEFF. In addition, the ACPI node
for the EC device on these laptops indicates an I/O resource spanning 0x800 to
0x8FE when in truth, the device supports communication all the way through
0x8FF. 

To address these differences without impacting cros_ec_lpcs' compatibility with
Chromebook/Chromebox devices, this patch series adds DMI-match-specific driver
data through which we can detect per-machine "quirks". Quirks indicate changes
in behavior from cros_ec_lpcs' expectation, such as remapping the memory MMIO
window and handling I/O reservation windows differently.

Dustin L. Howett (4):
  cros_ec_lpc: introduce lpc_driver_data, a priv struct for the lpc
    device
  cros_ec_lpc: pass driver_data from DMI down to the device
  cros_ec_lpc: add a quirks system, and propagate quirks from DMI
  cros_ec_lpc: add quirks for the Framework Laptop

 drivers/platform/chrome/cros_ec_lpc.c | 61 ++++++++++++++++++++++++---
 1 file changed, 55 insertions(+), 6 deletions(-)

Comments

Tzung-Bi Shih Oct. 11, 2023, 5:29 a.m. UTC | #1
On Thu, Oct 05, 2023 at 11:06:57AM -0500, Dustin L. Howett wrote:
> However, those devices move the MMIO region for EC memory from the original
> Chrome EC port range of 0x900-0x9FF to 0xE00-0xEFF. In addition, the ACPI node
> for the EC device on these laptops indicates an I/O resource spanning 0x800 to
> 0x8FE when in truth, the device supports communication all the way through
> 0x8FF. 

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.

> Dustin L. Howett (4):
>   cros_ec_lpc: introduce lpc_driver_data, a priv struct for the lpc
>     device
>   cros_ec_lpc: pass driver_data from DMI down to the device
>   cros_ec_lpc: add a quirks system, and propagate quirks from DMI
>   cros_ec_lpc: add quirks for the Framework Laptop

The series should prefix with "platform/chrome: cros_ec_lpc".
Dustin Howett Nov. 26, 2023, 7:22 p.m. UTC | #2
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.

Does that make it clearer? I have been struggling to reword this for a
while. Hah.
I tried to explain this better in the patch bodies.

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.

>
> > Dustin L. Howett (4):
> > [...]
>
> The series should prefix with "platform/chrome: cros_ec_lpc".

Fixed. Sending an updated patch series that addresses yours and other
folks' comments across the entire series.

Thanks for the review,
d
Tzung-Bi Shih Nov. 27, 2023, 3:30 a.m. UTC | #3
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.