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 |
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".
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
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.