linux-kernel - Re: [PATCH V1] PCI: designware-ep: Fix DBI access before core init

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

Date:   Thu, 28 Jul 2022 09:17:16 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Vidya Sagar <vidyas@...dia.com>
Cc:     jingoohan1@...il.com, gustavo.pimentel@...opsys.com,
        lpieralisi@...nel.org, robh@...nel.org, kw@...ux.com,
        bhelgaas@...gle.com, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, kthota@...dia.com,
        mmaddireddy@...dia.com, sagar.tv@...il.com
Subject: Re: [PATCH V1] PCI: designware-ep: Fix DBI access before core init

On Thu, Jul 28, 2022 at 05:56:28PM +0530, Vidya Sagar wrote:
> 
> 
> On 7/28/2022 3:44 AM, Bjorn Helgaas wrote:
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Wed, Jun 22, 2022 at 09:31:33AM +0530, Vidya Sagar wrote:
> > > Platforms that cannot support their core initialization without the
> > > reference clock from the host, implement the feature 'core_init_notifier'
> > > to indicate the DesignWare sub-system about when their core is getting
> > > initialized. Any accesses to the core (Ex:- DBI) would result in system
> > > hang in such systems (Ex:- tegra194). This patch moves any access to the
> > > core to dw_pcie_ep_init_complete() API which is effectively called only
> > > after the core initialization.
> > 
> > I assume this is still broken.  I want to fix it.  I assume this patch
> > fixes it and there are no known problems with it.  I assume this can
> > be fixed so it works on all platforms, whether they use
> > core_init_notifier or not.
> Yes. All your assumptions are correct.
> 
> > 
> > I'd like the commit log to be specific about where the hang occurs so
> > it's easy for a non-DesignWare expert (me!) to see the problem.  E.g.,
> > on tegra194, X depends on Y, but Y is initialized after X.  Say
> > specifically what functions X and Y are.
> X = DBI accesses
> Y = Core initialization which in turn depends on the REFCLK from the host
> 
> Without this patch, hang happens when DBI registers are accessed without
> core being initialized. In the case of Tegra194 at least, core gets
> initialized only after REFCLK is available from the host. The way we make
> sure that the REFCLK is available from the host is by checking for PERST#
> de-assertion interrupt. (PCIe spec mandates that the host must supply REFCLK
> before de-asserting PERST# signal).
> This patch prevents any accesses to the DBI/Core registers if the platform
> says that it supports core_init_notifier.

That's basically what the commit log already said.  Can you give me
actual function names as a hint for where to look?

Bjorn