linux-kernel - Re: [PATCH] PCI, EDAC: fix ordering assign resource and bus

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]

Message-ID: <20140530222108.GN28131@pd.tnic>
Date:	Sat, 31 May 2014 00:21:08 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Doug Thompson <dougthompson@...ssion.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	linux-edac@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PCI, EDAC: fix ordering assign resource and bus_add

On Fri, May 30, 2014 at 04:00:17PM -0600, Bjorn Helgaas wrote:
> Thanks, I should have waited for you. I was assuming the merge window
> would open on Monday, and I hoped for a day or two in -next, but now
> it sounds like we might have an -rc8, so I needn't have been in such a
> hurry.

Bah, no worries. :-) The patch is simple enough and is requiring your
expertise so I wouldnt've said anything, except I wanted to ask about
that pci_bus* functions ordering situation, so... :-)

> Yeah, this is really a mess.  The pci_bus_*() functions (at least
> pci_bus_add_device() and pci_bus_assign_resources()) are not really
> intended to be called by drivers at all -- they should only be used by
> the arch code that drives PCI enumeration.  Eventually I'd like to
> even move them out of the arch code and into the PCI core.

Ah, ok. pci_bus_add_device is called also in some x86 platform drivers,
except the pci core itself, so yeah, it looks like you're trying to hide
it. :)

> In this i82875p case, it looks like this is basically a quirk that
> unhides a device.  I think it's sort of dubious to poke at things the
> BIOS has explicitly hidden from the OS, but apart from that, if we
> turned this into an actual DECLARE_PCI_FIXUP_CLASS_EARLY() quirk on
> the 82875_0 device, I think the normal PCI enumeration process would
> find the 82875_6 device, and we could get rid of the whole "if (dev ==
> NULL)" chunk.

Yeah, I don't think that's worth it - this driver is probably ancient
now, if I trust this:

http://ark.intel.com/products/27711/Intel-82875P-Memory-Controller

Launch Date: Q1'02 - that's a century ago in HW years. :-P

I guess we can leave it at that - even if we did a quirk, I'm at a loss
as to where or who could test it. :-)

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/