[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220622202643.GA1387264@bhelgaas>
Date: Wed, 22 Jun 2022 15:26:43 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Robert Marko <robimarko@...il.com>
Cc: Stanimir Varbanov <svarbanov@...sol.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
lpieralisi@...nel.org, Rob Herring <robh@...nel.org>, kw@...ux.com,
Bjorn Helgaas <bhelgaas@...gle.com>, p.zabel@...gutronix.de,
jingoohan1@...il.com, linux-pci@...r.kernel.org,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
johan+linaro@...nel.org
Subject: Re: [PATCH v2] PCI: qcom: fix IPQ8074 Gen2 support
On Wed, Jun 22, 2022 at 04:23:49PM +0200, Robert Marko wrote:
> On Tue, 21 Jun 2022 at 23:43, Bjorn Helgaas <helgaas@...nel.org> 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@...nel.org> 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
Powered by blists - more mailing lists