linux-kernel - Re: [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aH4FRGIq0oCLMQqB@hovoldconsulting.com>
Date: Mon, 21 Jul 2025 11:15:48 +0200
From: Johan Hovold <johan@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Manivannan Sadhasivam <mani@...nel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
Subject: Re: [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp_update() to
 notifier callback

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@....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