mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Robert Hancock <hancockr@shaw.ca>,
	Andrew Morton <akpm@linux-foundation.org>,
	avuton@gmail.com, yakui.zhao@intel.com, shaohua.li@intel.com,
	trenn@suse.de,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	alsa-devel@alsa-project.org
Subject: Re: a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
Date: Thu, 14 Feb 2008 17:13:22 -0700	[thread overview]
Message-ID: <200802141713.23461.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0802141503470.6110@woody.linux-foundation.org>

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

  reply	other threads:[~2008-02-15  0:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.Kmpf0B4W44W1VefIME7+BnfUouY@ifi.uio.no>
2008-01-27 18:17 ` Robert Hancock
2008-01-31 22:58   ` Andrew Morton
2008-02-01  0:14     ` Robert Hancock
2008-02-01  0:50       ` Linus Torvalds
2008-02-04 17:39         ` Bjorn Helgaas
2008-02-04 18:18           ` Linus Torvalds
2008-02-04 20:41             ` Bjorn Helgaas
2008-02-04 21:16               ` Linus Torvalds
2008-02-05  7:03                 ` Bjorn Helgaas
2008-02-05 16:46                   ` Avuton Olrich
2008-02-05 18:15                   ` Linus Torvalds
2008-02-05 20:12                     ` Bjorn Helgaas
2008-02-13 22:33                       ` Avuton Olrich
2008-02-14 18:51                       ` Bjorn Helgaas
2008-02-14 19:42                         ` Linus Torvalds
2008-02-14 20:07                           ` Bjorn Helgaas
2008-02-14 20:26                             ` Linus Torvalds
2008-02-14 21:01                               ` Bjorn Helgaas
2008-02-14 21:37                                 ` Linus Torvalds
2008-02-14 22:28                                   ` Bjorn Helgaas
2008-02-14 22:57                                     ` Linus Torvalds
2008-02-14 23:14                                       ` Linus Torvalds
2008-02-15  0:13                                         ` Bjorn Helgaas [this message]
2008-02-15  0:40                                           ` Linus Torvalds
2008-02-27 17:43                                             ` Bjorn Helgaas
2008-01-27 14:40 Avuton Olrich
2008-01-27 21:50 ` Linus Torvalds
2008-01-28  1:15   ` Shaohua Li

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=200802141713.23461.bjorn.helgaas@hp.com \
    --to=bjorn.helgaas@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=avuton@gmail.com \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=trenn@suse.de \
    --cc=yakui.zhao@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®