Lukas Wunner writes:
> Hence inclusion of Linux-specific headers isn't appropriate in
> drivers/acpi/acpica
linux/drivers/acpi/acpica/utobject.c includes <linux/kmemleak.h>, unlike
the upstream. Maybe that's an error that should be corrected, or maybe
the structure that you're suggesting is too limiting and there isn't a
real problem with Linux maintaining appropriate acpica patches.
Of course, I'm happy to discuss what's best (and I was already asking,
e.g., whether prioritizing DMI information over command-line options is
the Linux convention). Some notes on the patch design:
* The starting point is that extraction of sleep types from the DSDT
is already nicely isolated inside acpi_get_sleep_type_data() in
acpica. This function is called from several places, so overriding
the sleep types inside this function is better than reviewing what
all the callers do.
* This doesn't mean that the same file has to handle triggering the
override. For example, my current acpi_force_s3_init() could be
replaced with acpi_force_s3(type) that simply does force_s3 = type,
and then the DMI detection and force_s3_setup() could move to
drivers/acpi/sleep.c as you're suggesting.
* Structurally, the DMI detection has to be before any calls to
acpi_get_sleep_type_data(). The earliest call I see is from
acpi_sleep_init() via acpi_sleep_suspend_setup(), which is called
after acpi_sleep_dmi_check(), so hooking into
acpi_sleep_dmi_check() seems as safe as my current patch calling my
acpi_force_s3_init() before acpi_sleep_init().
It'd be nice to get some feedback on the details here. I'm also happy if
someone who understands the intended acpi/acpica sleep structure simply
adapts the patch; it's only a few lines of code.
> and that may be the reason why the patch was ignored on their mailing
> list.
If patches for the acpica component of Linux shouldn't be sent to
devel@xxxxxxxxxx then linux/MAINTAINERS should be corrected to omit
devel@xxxxxxxxxx and list only linux-acpi@xxxxxxxxxxxxxxx. Note that
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
says "at least one mailing list", and I had no reason to think that I
should send to all of the lists; devel@xxxxxxxxxx sounded more specific
so I chose that.
---Dan
Attachment:
signature.asc
Description: PGP signature
