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] [day] [month] [year] [list]
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