[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200802051312.47074.bjorn.helgaas@hp.com>
Date: Tue, 5 Feb 2008 13:12:46 -0700
From: Bjorn Helgaas <bjorn.helgaas@...com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Robert Hancock <hancockr@...w.ca>,
Andrew Morton <akpm@...ux-foundation.org>, avuton@...il.com,
yakui.zhao@...el.com, shaohua.li@...el.com, trenn@...e.de,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
alsa-devel@...a-project.org
Subject: Re: a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
On Tuesday 05 February 2008 11:15:12 am Linus Torvalds wrote:
>
> On Tue, 5 Feb 2008, Bjorn Helgaas wrote:
> > >
> > > - PnP/ACPI resource allocation *after* it, but before driver loading
> > > (which wll cause new resources to be allocated). This could be
> > > fs_initcall, or whatever (that's what things like "acpi_event_init"
> > > already do).
> >
> > If we put the PNP system driver here, we can easily do a quirk that
> > ignores PNP resources that overlap PCI resources.
>
> No, you don't need any quirks: you just do an "insert_resource()" and
> ignore the error return. If the (bogus) PnP resource clashes with the
> (correct) hardware PCI resource, the insert will simply fail. No quirks
> needed.
>
> > But it's kind of
> > ugly to have the ACPI PCI root driver early and other PNP drivers
> > later because they're basically similar animals.
>
> No they are not.
>
> If one does just device enumeration, and the other does resource
> registrations, then they ARE NOT similar animals at all. Don't claim that
> they are.
Whoa, easy :-) I just meant they're similar in that we discover PCI
root bridges and other PNP devices by traversing the ACPI namespace,
so unless we make special arrangements, we bind drivers to them at
roughly the same time.
I'll play with your insert_resource() idea and see if I can figure
something out.
Bjorn
--
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/
Powered by blists - more mailing lists