On Thu, Feb 29, 2024 at 11:25:48AM +0100, Johan Hovold wrote: > On Thu, Feb 29, 2024 at 03:38:53PM +0530, Manivannan Sadhasivam wrote: > > On Wed, Feb 28, 2024 at 04:08:43PM -0600, Bjorn Helgaas wrote: > > > On Fri, Feb 23, 2024 at 04:21:12PM +0100, Johan Hovold wrote: > > > > > Johan Hovold (12): > > > > dt-bindings: PCI: qcom: Allow 'required-opps' > > > > dt-bindings: PCI: qcom: Do not require 'msi-map-mask' > > > > dt-bindings: PCI: qcom: Allow 'aspm-no-l0s' > > > > PCI: qcom: Add support for disabling ASPM L0s in devicetree > > > > > > The ASPM patches fix a v6.7 regression, so it would be good to fix > > > that in v6.8. > > > > > > Mani, if you are OK with them, I can add them to for-linus for v6.8. > > > > > > What about the 'required-opps' and 'msi-map-mask' patches? If they're > > > important, I can merge them for v6.8, too, but it's late in the cycle > > > and it's not clear from the commit logs why they shouldn't wait for > > > v6.9. > > > > > > > I'm checking with Qcom HW team on the ASPM behavior. So please hold off the ASPM > > related patches until I get an answer. But 'required-opps' and 'msi-map-mask' > > patches can be applied for 6.9 (not strictly fixing anything in 6.8). > > As I mentioned, the 'required-opps' binding update is needed to fix the > missing OPP vote so blocking the binding patch would block merging the > DT fix which could otherwise go into 6.8. > I agree that the fix gets the priority. But some maintainers perfer to merge fix patches _only_ if they are fixing the issue introduced in the ongoing release. But if Bjorn has no issues in merging these for 6.8, then it is fine. > The 'msi-map-mask' is arguably a fix of the binding which should never > have had that property, but sure, it's strictly only needed for 6.9. > > And Bjorn A has already checked with the Qualcomm PCI team regarding > ASPM. It's also been two weeks since you said you were going to check > with your contacts. Is it really worth waiting more for an answer from > that part of the team? We can always amend the ASPM fixes later when/if > we learn more. > > Note that this is also a blocker for merging ITS support for 6.9. > I got it, but we cannot just merge the patches without finding the rootcause. I heard from Qcom that this AER error could also be due to PHY init sequence as spotted on some other platforms, so if that is the case then the DT property is not correct. Since this is not the hot target now (for Qcom), it takes time to check things. - Mani -- மணிவண்ணன் சதாசிவம்
