Re: [PATCH v2 0/7] ACPI: acpi_device_override_status() changes

[Adrian Hunter <adrian.hunter@intel.com>]

On 23/11/2021 13:13, Ulf Hansson wrote:
> On Mon, 22 Nov 2021 at 18:05, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi Rafael,
>>
>> As requested here is a v2 of my series previously titled:
>> "ACPI: scan: Skip turning off some unused objects during scan"
>>
>> Which was a regression fix series for the commit c10383e8ddf4
>> ("ACPI: scan: Release PM resources blocked by unused objects")
>> change, but that has been reverted now. So as requested here is
>> a v2 changing the wording of various commit messages since these
>> changes are still useful to have regardless.
>>
>> Patch 1/7 is a v2/resend of the "ACPI / x86: Drop PWM2 device on
>> Lenovo Yoga Book from always present table" patch. You requested
>> changing the commit message of this one a bit to make it sound
>> less like a regression fix (which it is not). But you already
>> have the previous version of this patch in your bleeding-edge
>> branch, with a "Cc: 5.1+ <stable@vger.kernel.org> # 5.1+"
>> added ?  So depending on which version you want you can either
>> skip this patch when applying this series, or replace it with
>> the version from this series.
>>
>> Patches 2-4 are the main changes to make the always_present
>> quirk handling more flexible, changing it into a status_override
>> mechanism + adding a quirk for the GPD win and pocket to fix
>> an issue with those in a more elegant matter then the current
>> kludge in the sdhci-acpi code.
>>
>> Patch 5 is an unrelated patch which touches the override-status
>> quirk table, so it needed to be rebased and I decided to add it
>> to this series to make it clear that its v2 needs to be applied
>> on top of the other ACPI changes from this series.
>>
>> Patches 6+7 cleanup the sdhci-acpi code, removing the now no
>> longer needed ugly kludge for the GPD win/pocket. These can
>> be merged independently from patches 1-5, through the mmc
>> tree, as long as they get send to Linus during the same
>> kernel cycle as the ACPI bits.
> 
> This sounds like the mmc changes are really not that independent after
> all. What about bisectability?
> 
> An option is to funnel the sdhci patches together with the ACPI
> patches through Rafael's tree. You have my ack for this, but let's
> wait for Adrian's ack too.

Looks OK to me.

Acked-by: Adrian Hunter <adrian.hunter@intel.com>