On Wed, Mar 06, 2024 at 03:08:57PM +0530, Manivannan Sadhasivam wrote: > On Wed, Mar 06, 2024 at 10:12:31AM +0100, Johan Hovold wrote: > > On Wed, Mar 06, 2024 at 10:48:30AM +0200, Dmitry Baryshkov wrote: > > > On Wed, 6 Mar 2024 at 10:39, Manivannan Sadhasivam > > > <manivannan.sadhasivam@xxxxxxxxxx> wrote: > > > > On Wed, Mar 06, 2024 at 08:20:16AM +0100, Johan Hovold wrote: > > > > > Ok, thanks for confirming. But then the devicetree property is not the > > > > > right way to handle this, and we should disable L0s based on the > > > > > compatible string instead. > > > > > > Hmm. I checked further and got the info that there is no change in the IP, but > > > > the PHY sequence is not tuned correctly for L0s (as I suspected earlier). So > > > > there will be AERs when L0s is enabled on any controller instance. And there > > > > will be no updated PHY sequence in the future also for this chipset. > > > > > > Why? If it is a bug in the PHY driver, it should be fixed there > > > instead of adding workarounds. > > > > ASPM L0s is currently broken on these platforms and, as far as I > > understand, both under Windows and Linux. Since Qualcomm hasn't been > > able to come up with the necessary PHY init sequences for these > > platforms yet, I doubt they will suddenly appear in the near future. > > > > So we need to disable L0s for now. If an updated PHY init sequence later > > appears, we can always enable it again. > > It could be the same case for all 'non-mobile' chipsets (automotive, compute, > modem). So instead of using the compatible, please add a flag and set that for > all non-mobile SoCs. Like the ones starting with SAxxx, SCxxx, SDxxx. I've already updated the series and was just about to post it. Disabling for further platforms would also require matching on the compatible string and we can easily do that in a follow-up patch once we have some confirmation that it is needed. Johan
