lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZYxgQn8L7ENkc0AJ@smile.fi.intel.com> Date: Wed, 27 Dec 2023 19:34:58 +0200 From: Andy Shevchenko <andriy.shevchenko@...el.com> To: Mark Hasemeyer <markhas@...omium.org> Cc: LKML <linux-kernel@...r.kernel.org>, AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Rob Herring <robh@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>, Sudeep Holla <sudeep.holla@....com>, Raul Rangel <rrangel@...omium.org>, Tzung-Bi Shih <tzungbi@...nel.org>, Benson Leung <bleung@...omium.org>, Bhanu Prakash Maiya <bhanumaiya@...omium.org>, Chen-Yu Tsai <wenst@...omium.org>, Guenter Roeck <groeck@...omium.org>, Lee Jones <lee@...nel.org>, Prashant Malani <pmalani@...omium.org>, Rob Barnes <robbarnes@...gle.com>, Stephen Boyd <swboyd@...omium.org>, chrome-platform@...ts.linux.dev Subject: Re: [PATCH v3 24/24] platform/chrome: cros_ec: Use PM subsystem to manage wakeirq On Tue, Dec 26, 2023 at 12:21:28PM -0700, Mark Hasemeyer wrote: > The cros ec driver is manually managing the wake IRQ by calling > enable_irq_wake()/disable_irq_wake() during suspend/resume. > > Modify the driver to use the power management subsystem to manage the > wakeirq. > > Rather than assuming that the IRQ is wake capable, use the underlying > firmware/device tree to determine whether or not to enable it as a wake > source. Some Chromebooks rely solely on the ec_sync pin to wake the AP > but do not specify the interrupt as wake capable in the ACPI _CRS. For > LPC/ACPI based systems a DMI quirk is introduced listing boards whose > firmware should not be trusted to provide correct wake capable values. > For device tree base systems, it is not an issue as the relevant device > tree entries have been updated and DTS is built from source for each > ChromeOS update. ... > acpi_status status; > struct cros_ec_device *ec_dev; > + struct resource irqres; struct resource irqres = {}; ? > u8 buf[2] = {}; > int irq, ret; ... > - irq = platform_get_irq_optional(pdev, 0); > - if (irq > 0) > + irq = platform_get_irq_resource_optional(pdev, 0, &irqres); > + if (irq > 0) { > ec_dev->irq = irq; > - else if (irq != -ENXIO) { > + if (should_force_irq_wake_capable()) > + ec_dev->irq_wake = true; > + else > + ec_dev->irq_wake = irqres.flags & IORESOURCE_IRQ_WAKECAPABLE; > + } else if (irq != -ENXIO) { > dev_err(dev, "couldn't retrieve IRQ number (%d)\n", irq); > return irq; > } Still I do not like ambiguity behind irq > 0 vs. irqres.start. For this, and if needed others, return plain error. Seems I gave the tag for the previous patch, consider that tag conditional (it seems I missed this). ... > u16 proto_version; > void *priv; > int irq; > + bool irq_wake; > u8 *din; > u8 *dout; > int din_size; > int dout_size; > - bool wake_enabled; > bool suspended; > int (*cmd_xfer)(struct cros_ec_device *ec, > struct cros_ec_command *msg); Have you run pahole on this (before and after)? -- With Best Regards, Andy Shevchenko
Powered by blists - more mailing lists