From: Johan Hovold <johan@kernel.org>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@oss.qualcomm.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>
Subject: Re: [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp_update() to notifier callback
Date: Mon, 21 Jul 2025 11:15:48 +0200 [thread overview]
Message-ID: <aH4FRGIq0oCLMQqB@hovoldconsulting.com> (raw)
In-Reply-To: <e0553625-2864-4d9e-89ef-fab44fb18be4@oss.qualcomm.com>
On Wed, Jul 16, 2025 at 12:33:48PM +0200, Konrad Dybcio wrote:
> On 7/16/25 7:28 AM, Manivannan Sadhasivam wrote:
> > On Tue, Jul 15, 2025 at 12:45:36PM GMT, Konrad Dybcio wrote:
> >> On 7/15/25 12:36 PM, Manivannan Sadhasivam wrote:
> >>> On Tue, Jul 15, 2025 at 11:54:48AM GMT, Konrad Dybcio wrote:
> >>>> On 7/14/25 8:01 PM, Manivannan Sadhasivam wrote:
> >>>>> It allows us to group all the settings that need to be done when a PCI
> >>>>> device is attached to the bus in a single place.
> >>>>>
> >>>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >>>>> ---
>
> [...]
>
> >>> Let me think of other ways to call these two APIs during the device addition. If
> >>> there are no sane ways, I'll drop *this* patch.
> >>
> >> Would it be too naive to assume BUS_NOTIFY_ADD_DEVICE is a good fit?
> >
> > BUS_NOTIFY_ADD_DEVICE is not currently a good fit as ASPM link state
> > initialization happen after all the devices are enumerated for the slot. This is
> > something to be fixed in the PCI core and would allow us to use
> > BUS_NOTIFY_ADD_DEVICE.
> >
> > I talked to Bjorn H and we both agreed that this needs to be revisited. But I'm
> > just worrried that until this happens, we cannot upstream the ASPM fix and not
> > even backport it to 6.16/16.
> >
> > So maybe we need to resort to this patch as an interim fix if everyone agrees.
>
> I'm not opposed if there's going to be an improved solution next cycle.
> Having ASPM 99.9% of the time is much better than not having it at all
This has been broken since 6.15 (not 6.13 as the commit message of patch
1/2 suggests) so there's no rush to get it sorted in 6.16.
The current approach also works for everything but devices using pwrctrl
(read: anything but ath11k/ath12k).
It seems like adding an enable_device() callback can be used as minimal,
backportable fix for the ath11k/ath12k regression on Qualcomm platforms,
while working on something more general (e.g. also handling the OPPs) if
that turns out to be more invasive.
Johan
next prev parent reply other threads:[~2025-07-21 9:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 18:01 [PATCH 0/2] PCI: qcom: Switch to bus notifier for enabling ASPM of PCI devices Manivannan Sadhasivam
2025-07-14 18:01 ` [PATCH 1/2] " Manivannan Sadhasivam
2025-07-15 7:48 ` Johan Hovold
2025-07-15 9:11 ` Manivannan Sadhasivam
2025-07-15 9:33 ` Johan Hovold
2025-07-15 9:46 ` Konrad Dybcio
2025-07-15 10:27 ` Manivannan Sadhasivam
2025-07-15 12:31 ` Johan Hovold
2025-07-21 9:32 ` Johan Hovold
2025-07-21 10:56 ` Manivannan Sadhasivam
2025-07-21 12:49 ` Johan Hovold
2025-07-21 15:45 ` Manivannan Sadhasivam
2025-07-14 18:01 ` [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp_update() to notifier callback Manivannan Sadhasivam
2025-07-15 7:51 ` Johan Hovold
2025-07-15 9:13 ` Manivannan Sadhasivam
2025-07-15 9:54 ` Konrad Dybcio
2025-07-15 10:36 ` Manivannan Sadhasivam
2025-07-15 10:45 ` Konrad Dybcio
2025-07-16 5:28 ` Manivannan Sadhasivam
2025-07-16 10:33 ` Konrad Dybcio
2025-07-21 9:15 ` Johan Hovold [this message]
2025-07-16 4:54 ` Krishna Chaitanya Chundru
2025-07-16 6:46 ` Manivannan Sadhasivam
2025-07-16 6:53 ` Krishna Chaitanya Chundru
2025-07-16 7:18 ` Manivannan Sadhasivam
2025-07-21 9:02 ` Johan Hovold
2025-07-21 10:59 ` Manivannan Sadhasivam
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aH4FRGIq0oCLMQqB@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=bhelgaas@google.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.