Re: [PATCH] PCI, EDAC: fix ordering assign resource and bus_add

[Borislav Petkov]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/