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: <20160108150137.GH3097@leverpostej>
Date:	Fri, 8 Jan 2016 15:01:37 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Mark Salter <msalter@...hat.com>
Cc:	Tomasz Nowicki <tn@...ihalf.com>, bhelgaas@...gle.com,
	arnd@...db.de, will.deacon@....com, catalin.marinas@....com,
	rjw@...ysocki.net, hanjun.guo@...aro.org,
	Lorenzo.Pieralisi@....com, okaya@...eaurora.org,
	jiang.liu@...ux.intel.com, Stefano.Stabellini@...citrix.com,
	jchandra@...adcom.com, linaro-acpi@...ts.linaro.org,
	linux-pci@...r.kernel.org, Liviu.Dudau@....com,
	ddaney@...iumnetworks.com, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, robert.richter@...iumnetworks.com,
	Suravee.Suthikulpanit@....com, jcm@...hat.com,
	wangyijing@...wei.com, tglx@...utronix.de, mw@...ihalf.com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors
 against platfrom specific quirks.

On Fri, Jan 08, 2016 at 09:16:21AM -0500, Mark Salter wrote:
> On Wed, 2015-12-16 at 16:16 +0100, Tomasz Nowicki wrote:
> > Some platforms may not be fully compliant with generic set of PCI config
> > accessors. For these cases we implement the way to overwrite accessors
> > set before PCI buses enumeration. Algorithm that overwrite accessors
> > matches against platform ID (DMI), domain and bus number, hopefully
> > enough for all cases. All quirks can be defined using:
> > DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> > 
> > example:
> > 
> > static const struct dmi_system_id yyy[] = {
> >         {
> >                 .ident = "<Platform ident string>",
> >                 .callback = <handler>,
> >                 .matches = {
> >                         DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
> >                         DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
> >                         DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
> >                 },
> >         },
> >         { }
> > };
> > 
> 
> This seems awkward to me in the case where the quirk is SoC-based and there
> may be multiple platforms affected. Needing a DECLARE_ACPI_MCFG_FIXUP for
> each platform using such a SoC (i.e. Mustang and Moonshot) doesn't seem
> right. In that case, I think it'd be better to check CPUID and possibly
> some SoC register to cover all platforms affected.

CPUs get reused across SoCs, so as you've implicitly noted, the CPUID
alone is insufficient.

Given that IP blocks get moved around between SoC variants, I don't
think you can check "some SoC register" based on the CPU ID -- you can
end up bringing the board down at that point.

If the CPU ID alone is insufficient to tell you about a component, it
cannot give you enough information about a component you can use to
query more information from.

If your platform requires a quirk, it's always going to be painful (and
to some extent, rightfulyl so). We should aim for correctness here with
explicit matching.

Thanks,
Mark.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ