From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org,
Pavel Kysilka <goldenfish@linuxsoft.cz>,
Adam Belay <abelay@mit.edu>, Jaroslav Kysela <perex@perex.cz>
Subject: Re: [PATCH] PNP: don't check for conflicts with bridge windows
Date: Mon, 03 May 2010 16:50:08 -0600 [thread overview]
Message-ID: <1272927008.28149.91.camel@dc7800.home> (raw)
In-Reply-To: <alpine.LFD.2.00.1005030950530.5478@i5.linux-foundation.org>
On Mon, 2010-05-03 at 09:53 -0700, Linus Torvalds wrote:
>
> On Mon, 3 May 2010, Bjorn Helgaas wrote:
> > if (tres->flags & IORESOURCE_IO) {
> > if (cannot_compare(tres->flags))
> > continue;
> > + if (tres->flags & IORESOURCE_WINDOW)
> > + continue;
> > tport = &tres->start;
> > tend = &tres->end;
> > if (ranged_conflict(port, end, tport, tend))
> > @@ -271,6 +273,8 @@ int pnp_check_mem(struct pnp_dev *dev, struct resource *res)
> > if (tres->flags & IORESOURCE_MEM) {
> > if (cannot_compare(tres->flags))
> > continue;
> > + if (tres->flags & IORESOURCE_WINDOW)
> > + continue;
>
> Hmm. Looking at the patch, I am wondering if it wouldn't make _more_ sense
> to instead say that you never mix IORESOURCE_WINDOW with
> IORESOURCE_IO/MEM? That would make the above patch unnecessary, since it
> would never trigger the test for IORESOURCE_IO/MEM in the first place.
>
> A resource window is a window - it's not the resource itself. It's not IO
> or MEM - that could/should be an attribute of what resource _tree_ the
> window is linked into, not the resource itself.
That's an interesting idea, and it might make more sense. I haven't
done anything useful with IORESOURCE_WINDOW yet, so I don't know how it
will work out.
My *plan* was to make pci_root.c a PNP driver, so it would use the
pre-parsed PNP resources to find the host bridge windows rather than
re-parsing the ACPI _CRS info by hand. Those PNP resources are not in
the resource tree when the driver first sees them (which might be a
deficiency of our current PNP core), so I don't think there's currently
a way for the driver to distinguish IO from MEM unless it's in the
resource itself.
At this stage of the release, my preference would be to use the patch
above (with the intention of coming back later for some more work), or
to just revert fa35b4926 (PNPACPI window support) and maybe 9d7cca04
(generic window support). If we revert those patches, I'll have to
figure out another way to clean up pci_root.c.
Bjorn
next prev parent reply other threads:[~2010-05-03 22:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-03 16:47 [PATCH] PNP: don't check for conflicts with bridge windows Bjorn Helgaas
2010-05-03 16:47 ` Bjorn Helgaas
2010-05-03 16:53 ` Linus Torvalds
2010-05-03 22:50 ` Bjorn Helgaas [this message]
2010-05-03 23:03 ` Linus Torvalds
2010-05-06 6:09 ` Len Brown
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=1272927008.28149.91.camel@dc7800.home \
--to=bjorn.helgaas@hp.com \
--cc=abelay@mit.edu \
--cc=goldenfish@linuxsoft.cz \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=perex@perex.cz \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox