On Wed, Jun 22, 2022 at 04:23:49PM +0200, Robert Marko wrote: > On Tue, 21 Jun 2022 at 23:43, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Tue, Jun 21, 2022 at 11:05:17PM +0200, Robert Marko wrote: > > > On Tue, 21 Jun 2022 at 22:32, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > > > On Tue, Jun 21, 2022 at 01:23:30PM +0200, Robert Marko wrote: > > > > > IPQ8074 has one Gen2 and one Gen3 port, currently the Gen2 port will > > > > > cause the system to hang as its using DBI registers in the .init > > > > > and those are only accesible after phy_power_on(). > ... > > Unless there's a reason *not* to move the DBI accesses for other > > variants, I think we should move them all to .post_init(). Otherwise > > it's just magic -- there's no indication in the code about why IPQ8074 > > needs to be different from all the rest. > > I am not sure how to do it properly, especially for the 2.1.0 IP that > IPQ8064 uses > and that is already filled with tweaks to get it properly working. > > As far as I can tell, the reason why it works for all of the others > is that they dont use a PHY driver at all (2.1.0 in IPQ8064 and > 2.4.0 in IPQ4019), 1.1.0 in APQ8084 appears to be unused completely > as its compatible is not used in any of the DTS-es. 2.3.2 in > MSM8996 and MSM8998 also use QMP, so I am not sure why these work. > ... > This patch applies to 5.19 as well, though I will send a v4 with the > updated description. Like, I said, I am not sure how to move DBI > accesses in other IP-s without breaking them. Why would they break? I don't see anything that indicates the DBI accesses are required to be before phy_power_on() or would fail after phy_power_on(). I agree there's always a risk of unintended breakage. It just doesn't seem very likely. Bjorn
