Linus says:
> I have nothing against this patch-series, but I'm not really much of a
> pnp person, so I'd like to see this at a minimum being acked by people who
> are, and who would use this.
> In fact, since the primary _reason_ for this seems to be to improve on the
> _CRS parsing code for PCI, I'd have expected that the people involved
> with previous _CRS issues be involved, and perhaps this whole thing could
> go through the PCI tree? But Yinghai Lu and Jesse Barnes weren't even
> cc'd.
> But maybe this really is more of an ACPI issue. I dunno. I get the feeling
> that ACPI doesn't really care, though - the subsystem that actually gets
> _affected_ by all this in the end is PCI.
> Anyway, more acks, please. And preferably involve the PCI people too.
So here you go :-) Please comment.
Linus is right; eventually I would like to use this to improve the PCI
host bridge _CRS parsing. I didn't think to include you at first because
that goal is still so far off that I can only dimly envision it. What I
*can* see as possible steps are these:
- add PNP support for bus number ranges and windows (these patches)
- initialize PNP (at least PNPACPI, probably PNPBIOS & ISAPNP also)
earlier, before PCI probing
- get rid of acpi_pci_root_start() by folding it into acpi_pci_root_add()
(this is the big one and will require lots of PCI and ACPI hotplug
cleanup that I don't know how to do yet)
- convert pci_root.c from an ACPI driver to a PNP driver
- remove pci_root.c _CRS parsing because PNPACPI already does it
The whole series is here: http://lkml.org/lkml/2010/3/5/243 and the
cover is below.
Bjorn
-------- Forwarded Message --------
From: Bjorn Helgaas <bjorn.helgaas@xxxxxx>
To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Len Brown
<lenb@xxxxxxxxxx>
Cc: linux-acpi@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Adam Belay
<abelay@xxxxxxx>
Subject: [PATCH v2 0/7] resource, PNPACPI: add bus number and window
support
Date: Fri, 05 Mar 2010 10:47:21 -0700
These patches add a new resource type, IORESOURCE_BUS, a new resource flag,
IORESOURCE_WINDOW, and PNPACPI support that uses them.
IORESOURCE_BUS is for PCI bus number ranges. For bridge devices, ACPI reports
secondary bus number ranges in _CRS descriptors, but we currently ignore them.
Adding this resource type will allow us to handle those descriptors in PNPACPI.
IORESOURCE_WINDOW is also for bridges: ACPI reports the regions that the bridge
forwards to its secondary bus. We have _CRS parsing code in pci_root.c that
handles these window descriptors, but PNPACPI currently ignores them. Adding
this flag bit will allow PNPACPI to deal with the windows correctly.
No drivers use bus or window resources yet, but ultimately, I would like to
drop the _CRS parsing code from pci_root.c and rely on PNPACPI to do it for us.
The current effect of this series is to change /sys/bus/pnp/.../resources (and
"lspnp -v" output) from this:
00:00 PNP0a03 PCI bus
state = active
to something like this:
00:00 PNP0a03 PCI bus
state = active
bus 0x0-0x0
io 0x0-0xcff window
io 0x0-0x2cfe window
io 0x3b0-0x3bb window
io 0x3c0-0x3df window
mem 0xf5d00000-0xf6ffffff window
mem disabled
mem 0xa0000-0xbffff window
Changes from v1 to v2:
- Add close quote in vsprintf SPECIAL comment (Randy Dunlap).
---
Bjorn Helgaas (7):
resource: expand IORESOURCE_TYPE_BITS to make room for bus resource type
vsprintf: clarify comments for printf_spec flags
vsprintf: move %pR resource printf_specs off the stack
resource: add bus number support
resource: add window support
PNPACPI: add window support
PNPACPI: add bus number support
drivers/pnp/base.h | 3 ++
drivers/pnp/interface.c | 7 +++--
drivers/pnp/pnpacpi/rsparser.c | 49 ++++++++++++++++++++++----------
drivers/pnp/resource.c | 27 +++++++++++++++++
drivers/pnp/support.c | 4 ++-
include/linux/ioport.h | 18 ++++++------
lib/vsprintf.c | 62 +++++++++++++++++++++++++---------------
7 files changed, 119 insertions(+), 51 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
