From: Ferry Toth <firstname.lastname@example.org>
To: "Rafael J. Wysocki" <email@example.com>
Cc: "Rafael J. Wysocki" <firstname.lastname@example.org>,
Linux PCI <email@example.com>,
Linux ACPI <firstname.lastname@example.org>,
Bjorn Helgaas <email@example.com>,
Andy Shevchenko <firstname.lastname@example.org>,
Mika Westerberg <email@example.com>
Subject: Re: [PATCH v2 2/7] PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI
Date: Fri, 24 Sep 2021 16:52:21 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Op 24-09-2021 om 14:02 schreef Rafael J. Wysocki:
> On Thu, Sep 23, 2021 at 10:32 PM Ferry Toth <email@example.com> wrote:
>> Op 23-09-2021 om 15:51 schreef Ferry Toth:
>>> Repost (with formatting removed, sorry for the noise)
>>> Op 23-09-2021 om 13:30 schreef Rafael J. Wysocki:
>>>> On Wed, Sep 22, 2021 at 11:31 PM Ferry Toth<firstname.lastname@example.org> wrote:
>>>>> Op 20-09-2021 om 21:17 schreef Rafael J. Wysocki:
>>>>>> From: Rafael J. Wysocki<email@example.com>
>>>>>> Using struct pci_platform_pm_ops for ACPI adds unnecessary
>>>>>> indirection to the interactions between the PCI core and ACPI PM,
>>>>>> which is also subject to retpolines.
>>>>>> Moreover, it is not particularly clear from the current code that,
>>>>>> as far as PCI PM is concerned, "platform" really means just ACPI
>>>>>> except for the special casess when Intel MID PCI PM is used or when
>>>>>> ACPI support is disabled (through the kernel config or command line,
>>>>>> or because there are no usable ACPI tables on the system).
>>>>>> To address the above, rework the PCI PM code to invoke ACPI PM
>>>>>> functions directly as needed and drop the acpi_pci_platform_pm
>>>>>> object that is not necessary any more.
>>>>>> Accordingly, update some of the ACPI PM functions in question to do
>>>>>> extra checks in case the ACPI support is disabled (which previously
>>>>>> was taken care of by avoiding to set the pci_platform_ops pointer
>>>>>> in those cases).
>>>>>> Signed-off-by: Rafael J. Wysocki<firstname.lastname@example.org>
>>>>>> v1 -> v2:
>>>>>> * Rebase on top of the new [1/7] and move dropping struct
>>>>>> pci_platform_pm_ops to a separate patch.
>>>>> I wanted to test this series on 5.15-rc2 but this patch 2/7 doesn't
>>>>> apply (after 1/7 applied). Should I apply this on another tree?
>>>> This is on top of
>>>> which is not yet in any tree.
>>>> Sorry for the confusion.
>>> No problem at all. If I can I will try to report back tonight. Else,
>>> will be delayed 2 due to a short break.
>> With those 3 extra patches followed by 7 from this series it builds. But
>> on boot I get:
>> dwc3 dwc3.0.auto: this is not a DesignWare USB3 DRD Core
>> Then after this it reboots. Nothing in the logs. Nothing else on
>> console, I guess something goes wrong early.
> It appears so.
> Can you please try just the 3 extra patches this series is on top of?
> The problem is more likely to be located in one of them.
Yes, I hope to be able to that this evening.
next prev parent reply other threads:[~2021-09-24 14:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 18:52 [PATCH v2 0/7] PCI: ACPI: Get rid of struct pci_platform_pm_ops and clean up code Rafael J. Wysocki
2021-09-20 19:16 ` [PATCH v2 1/7] PCI: PM: Do not use pci_platform_pm_ops for Intel MID PM Rafael J. Wysocki
2021-09-20 19:17 ` [PATCH v2 2/7] PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI Rafael J. Wysocki
2021-09-22 21:30 ` Ferry Toth
2021-09-23 11:30 ` Rafael J. Wysocki
[not found] ` <email@example.com>
2021-09-23 13:35 ` Rafael J. Wysocki
2021-09-23 13:51 ` Ferry Toth
2021-09-23 20:32 ` Ferry Toth
2021-09-24 12:02 ` Rafael J. Wysocki
2021-09-24 14:52 ` Ferry Toth [this message]
2021-09-24 21:17 ` Ferry Toth
2021-09-27 13:46 ` Rafael J. Wysocki
2021-09-29 19:08 ` Nathan Chancellor
2021-09-29 19:13 ` Rafael J. Wysocki
2021-09-29 19:13 ` Rafael J. Wysocki
2021-09-20 19:17 ` [PATCH v2 3/7] PCI: PM: Drop struct pci_platform_pm_ops Rafael J. Wysocki
2021-09-20 19:17 ` [PATCH v2 4/7] PCI: PM: Rearrange pci_target_state() Rafael J. Wysocki
2021-09-20 19:17 ` [PATCH v2 5/7] PCI: PM: Make pci_choose_state() call pci_target_state() Rafael J. Wysocki
2021-09-20 19:17 ` [PATCH v2 6/7] PCI: PM: Do not call platform_pci_power_manageable() unnecessarily Rafael J. Wysocki
2021-09-20 19:17 ` [PATCH v2 7/7] PCI: PM: Simplify acpi_pci_power_manageable() Rafael J. Wysocki
2021-09-28 23:28 ` [PATCH v2 0/7] PCI: ACPI: Get rid of struct pci_platform_pm_ops and clean up code Bjorn Helgaas
2021-09-29 12:00 ` Rafael J. Wysocki
2021-09-29 15:07 ` Bjorn Helgaas
2021-09-29 17:14 ` Ferry Toth
2021-09-29 18:05 ` [PATCH v3 0/3] PCI: PM: Simplify and unify some helper functions Rafael J. Wysocki
2021-09-29 18:09 ` [PATCH v3 1/3] PCI: PM: Rearrange pci_target_state() Rafael J. Wysocki
2021-09-29 18:11 ` [PATCH v3 2/3] PCI: PM: Make pci_choose_state() call pci_target_state() Rafael J. Wysocki
2021-09-29 18:15 ` [PATCH v3 3/3] PCI: PM: Do not call platform_pci_power_manageable() unnecessarily Rafael J. Wysocki
2021-10-03 20:14 ` [PATCH v3 0/3] PCI: PM: Simplify and unify some helper functions Ferry Toth
2021-10-05 11:03 ` Rafael J. Wysocki
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.