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]
Message-ID: <5661F9DD.7060303@arm.com>
Date:	Fri, 4 Dec 2015 14:38:53 -0600
From:	Jeremy Linton <jeremy.linton@....com>
To:	Gabriele Paoloni <gabriele.paoloni@...wei.com>,
	bhelgaas@...gle.com, arnd@...db.de, will.deacon@....com,
	catalin.marinas@....com, hanjun.guo@...aro.org,
	Lorenzo.Pieralisi@....com, Liviu.Dudau@....com, tn@...ihalf.com
Cc:	linaro-acpi@...ts.linaro.org, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, xuwei5@...ilicon.com,
	linux-acpi@...r.kernel.org, wangzhou1@...ilicon.com,
	liudongdong3@...wei.com, wangyijing@...wei.com, tglx@...utronix.de,
	liguozhu@...ilicon.com, jiang.liu@...ux.intel.com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 1/2] PCI/ACPI: Add ACPI support for non ECAM Host
 Bridge Controllers

On 12/03/2015 09:19 AM, Gabriele Paoloni wrote:
> This patch modifies the ARM64 architecure specific PCI framework to
> support Host Bridge specific quirks. these quirks are need for
> host bridge controllers that are not fully ECAM compliant.
> The quirks array allows each vendor to define his own
> acpi_scan_handler where its own pci_ops can be defined
> and the global pointer "vendor_specific_ops" should be
> set to them accordingly.

I have a similar set of changes working for a APM based platform. That 
platform has the same problem, that the default config space access 
methods don't work.

The one comment I have is that I've tried hard to set it up as a generic 
quirk system for which the ACPI/PCI subsystem makes the decision about 
which hardware quirk is being enabled. But its hard because the platform 
in question claims PNP0A08 too, which IMHO is completely wrong if your 
not actually compliant. OTOH, I don't want to base it off the DMI data 
because I don't want it to be tied to a particular implementation.

Lucky, the host bridge VID/PID _CAN_ be read with the default ECAM 
accessor. The only gocha is that the rescan needs to be restarted once 
the ops are replaced.

So my question, is does that work for this device as well?





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ