On Tuesday 30 September 2008 10:29:44 am Linus Torvalds wrote:
quoted text
> 
> On Tue, 30 Sep 2008, Rene Herman wrote:
> > 
> > > Of course, it may be that the PnP code runs too early, and we have only
> > > parsed the PCI resources, not inserted them into the resource tree yet. If
> > > so, none of this will work, of course.
> > 
> > It doesn't. With the test negated it triggers for all PCI resources (and
> > ofcourse my soundcard driver fails again).
> 
> Oh, ok. Looking at it, it does seem that we actually _insert_ the PCI 
> resources too late. We do it in pcibios_allocate_resources(), and there we 
> even take care to look at whether it was enabled or disabled (we 
> prioritize enabled resources, so that a disabled one will never be 
> requested before an enabled one and if they clash, it's always the 
> disabled one that loses the resource).
> 
> But pcibios_allocate_resources() is called from pcibios_resource_survey(), 
> which is called from pcibios_init(), which in turn is caled from 
> pci_subsys_init() that is a "subsys_initcall()".
> 
> In contrast, the PnP fixup thing is called from pnp_fixup_device, called 
> from __pnp_add_device(), called from pnp_add_device() (and 
> pnp_add_card(), but that should be later), and those in turn from
> pnpacpi_add_device and pnpacpi_init(). 
> 
> And pnpacpi_init is _also_ a subsys_initcall, but arch/x86/pci/built-in.o 
> gets linked in _after_ drivers/built-in.o. That, in turn, is because it's 
> marked as a "driver" in the x86 Makefile, and the main Makefile actually 
> ends up forcing "drivers-y" to have drivers/ first.
> 
> Just for fun, does this patch make a difference and allow you to just 
> take the "is it registered" thing into account?
> 
> It's a scary change right now, and I wouldn't commit it as is (I think 
> that for 2.6.27 the thing to do is to just do the minimal "zero means 
> disabled" thing), but having some random driver level initialize before 
> the core architecture-specific PCI code does smell. So something like this 
> sounds conceptually right anyway.

Sorry for the delay in responding -- I'm officially on vacation
yesterday and today.

I agree that for 2.6.27 the "res->start == 0 means disabled" check
in the PNP quirk seems safest.

I don't like it long-term, because (a) I'd like that knowledge to at
least be in PCI, not PNP, and (b) res->start is the CPU address, not
necessarily the PCI bus address, and the BAR value (== PCI bus address)
is what we're trying to check.  Even if we looked at the BAR value
instead of res->start, I think zero is a valid PCI bus address on
machines where the root bridge applies an address offset.

So something like the patch below (same as what Rene originally
proposed, I think)?

diff --git a/drivers/pnp/quirks.c b/drivers/pnp/quirks.c
index 0bdf9b8..b3319e4 100644
--- a/drivers/pnp/quirks.c
+++ b/drivers/pnp/quirks.c
@@ -254,6 +254,10 @@ static void quirk_system_pci_resources(struct pnp_dev *dev)
 
 			pci_start = pci_resource_start(pdev, i);
 			pci_end = pci_resource_end(pdev, i);
+
+			if (!pci_start)
+				continue;
+
 			for (j = 0;
 			     (res = pnp_get_resource(dev, type, j)); j++) {
 				if (res->start == 0 && res->end == 0)

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