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  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:   Mon, 13 May 2019 23:02:27 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Vidya Sagar <vidyas@...dia.com>
Cc:     Christoph Hellwig <hch@...radead.org>, lorenzo.pieralisi@....com,
        bhelgaas@...gle.com, robh+dt@...nel.org, mark.rutland@....com,
        thierry.reding@...il.com, jonathanh@...dia.com, kishon@...com,
        catalin.marinas@....com, will.deacon@....com, jingoohan1@...il.com,
        gustavo.pimentel@...opsys.com, mperttunen@...dia.com,
        linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, kthota@...dia.com,
        mmaddireddy@...dia.com, sagar.tv@...il.com
Subject: Re: [PATCH V6 02/15] PCI/PME: Export pcie_pme_disable_msi() &
 pcie_pme_no_msi() APIs

On Tue, May 14, 2019 at 09:00:19AM +0530, Vidya Sagar wrote:
> There is nothing broken in Tegra194 root port as such, rather,  this is more
> of software configuration choice and we are going with legacy interrupts than
> MSI interrupts (as Tegra194 doesn't support raising PME interrupts through MSI
> and please note that this doesn't mean root port is broken).

It seems odd at least and probably broken if it adverises MSI interrupts,
but than doesn't actually support them fully.

> Since Tegra194 has
> only Synopsys DesignWare core based host controllers and not any other hosts, I
> think it is fine to call this API in driver. Also, since this is a global setting,
> calling this APIs from anywhere (be it from quirk or from driver) would have the
> same effect, or did I miss anything here?

Maybe in your current particular case this is true, but in general
we see more and more systems with different kind of root ports, and
having a driver set a global variable due to its own hardwares quirk
defeats that.  So the right thing here is to replace the global
flag with a per-device one first before setting it for a driver.

Powered by blists - more mailing lists