linux-kernel - Re: a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200802141713.23461.bjorn.helgaas@hp.com>
Date:	Thu, 14 Feb 2008 17:13:22 -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 Thursday 14 February 2008 04:14:45 pm Linus Torvalds wrote:
> 
> On Thu, 14 Feb 2008, Linus Torvalds wrote:
> > 
> > It should insert the resource to the root resource (or a bridge resource), 
> > or not at all. If somebody else has already inserted a real device 
> > resource, we already know about it, and the PnP information is going to be 
> > just making things worse.
> 
> Hmm. The approach I'd take is to always insert the thing into the root 
> resource. If we do want to let PnP insert it into some lower-level bus, 
> we'd need to have some way to distinguish "bus" from "device", and we 
> don't.
> 
> So right now, how about just making PnP/ACPI just use
> 
> 	root = (flags & IORESOURCE_MEM) ? iomem_resource : ioport_resource;
> 	request_resource(root, newresource);
> 
> which is what we do for the e820 map and the other special resources we 
> know about (ie the magic resources we make up ourselves like video ram and 
> our standard PCI/ISA resource lists like the <0x100 DMA/PIC/FPU IO ports 
> etc)

That makes sense, but ...  there are BIOSes that actually list nested
resources, e.g., http://bugzilla.kernel.org/show_bug.cgi?id=9514#c29 :

  [000000290 - 000000294]  Motherboard resources
  [000000290 - 00000029F]  Motherboard resources

We'd have to make sure we don't start with the 0x290-0x294 resource,
because then we'll fail when we try to reserve 0x290-0x29f, and we
really should avoid using the 0x295-0x2f9 piece as well.

And even if we do figure out the "outermost" resources, I'd worry
that some BIOS will have separate ACPI devices that have overlapping
resources.  Then Murphy's Law says that we'll find the device with
the smaller resource first, reserve it, then find a device with an
enclosing resource, and leave something unreserved.

Maybe that's still better than a quirk; I don't know.  I guess it's
pretty ugly either way.

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/