All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
	Doug Thompson <dougthompson@xmission.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	linux-edac@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI, EDAC: fix ordering assign resource and bus_add
Date: Sat, 31 May 2014 00:21:08 +0200	[thread overview]
Message-ID: <20140530222108.GN28131@pd.tnic> (raw)
In-Reply-To: <CAErSpo4kQViCtaG9Fs_Amyr0pp96fsmdX2puJueK6Jf_XXdm1Q@mail.gmail.com>

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.
--

      reply	other threads:[~2014-05-30 22:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07 23:29 [PATCH] PCI, EDAC: fix ordering assign resource and bus_add Yinghai Lu
2014-05-30 17:01 ` Bjorn Helgaas
2014-05-30 21:46   ` Borislav Petkov
2014-05-30 22:00     ` Bjorn Helgaas
2014-05-30 22:21       ` Borislav Petkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140530222108.GN28131@pd.tnic \
    --to=bp@alien8.de \
    --cc=bhelgaas@google.com \
    --cc=dougthompson@xmission.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.