public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: linux-acpi <linux-acpi@vger.kernel.org>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Alexey Starikovskiy <aystarik@gmail.com>,
	Jean Delvare <khali@linux-fr.org>,
	Bernhard Walle <bwalle@suse.de>
Subject: [PATCH] - Increase PNP_MAX_PORT. ACPI devices can have a lot IO resource declarations
Date: Mon, 16 Jul 2007 16:21:07 +0200	[thread overview]
Message-ID: <1184595667.19959.312.camel@queen.suse.de> (raw)

PNP0C02 devices normally have a lot more IO port declarations than
currently defined in PNP_MAX_PORT

For checking, have a look at your disassembled DSDT, and look out for
the _CRS function (and/or a ResourceTemplate often called CRS).

Here an  example:
IO (Decode16,0x0010,             // Range Minimum
             0x0010,             // Range Maximum
             0x00,               // Alignment
             0x10,               // Length
)
IO (Decode16,
             0x0022,             // Range Minimum
             0x0022,             // Range Maximum
             0x00,               // Alignment
             0x1E,               // Length
)
...
IO (Decode16,
             0x0000,             // Range Minimum
             0x0000,             // Range Maximum
             0x00,               // Alignment
             0x00,               // Length
_Y06)
IO (Decode16,
             0x0000,             // Range Minimum
             0x0000,             // Range Maximum
             0x00,               // Alignment
             0x00,               // Length
_Y07)

The latter zeroed (_Y07) declarations are filled with dynamic values in
_CRS and also need an PNP IO port reserved.

On this machine (x86_64 workstation) more then 20 IO resource
declarations exist for one PNP0C02 device.
It could be that the suggested 32 is still not big enough.

Most of the ports are below 0x100, which get ignored by the pnp layer
anyways (cmp. with drivers/pnp/system.c:reserve_resources_of_dev() ).
These could already be ignore in
drivers/pnp/pnpacpi/rsparser.c:pnpacpi_parse_allocated_ioresource()
not filling up PNP_MAX_PORTs, but this is not that nice and probably
will get reverted at some later point when standard PC hardware (below
0x100, pics, kbd, timer, dma, ...) also gets requested by ACPI
sublayers.


I also wonder whether other limits like:
 #define PNP_MAX_MEM        4
 #define PNP_MAX_IRQ        2
 #define PNP_MAX_DMA        2
could get exceeded with pnpacpi?

I don't know what the theoretical max for ports on one device is, but
IMO the static array should get something dynamically allocated?

Something like:

+++ linux-2.6.22.1/include/linux/pnp.h
@@ -14,7 +14,7 @@
-#define PNP_MAX_PORT           8
+#define PNP_MAX_PORT           256

 struct pnp_resource_table {
-       struct resource port_resource[PNP_MAX_PORT];
+       struct resource *port_resource[PNP_MAX_PORT];
        struct resource mem_resource[PNP_MAX_MEM];

or
-       struct resource port_resource[PNP_MAX_PORT];
+       struct resource **port_resource;

and then k(z)alloc the resource structs...

BTW: This was the reason why:
  50e0-50ef : amd756_smbus
got not reserved on the patch:
"Identify native drivers and ACPI subsystem accessing the same
resources"
I sent some days ago. In 2.6.18 it seems this got handled (correctly) by
/drivers/acpi/motherboard which got replaced with pnpacpi system driver.

This would be the less intrusive short term fix:

------------------

Increase PNP_MAX_PORT. ACPI devices can have a lot IO resource declarations

Also print a message if PNP_DEBUG is set if we run out of PNP_MAX_PORTS.

Signed-off-by: Thomas Renninger <trenn@suse.de>

---
 drivers/pnp/pnpacpi/rsparser.c |    3 ++-
 include/linux/pnp.h            |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

Index: linux-2.6.22.1/include/linux/pnp.h
===================================================================
--- linux-2.6.22.1.orig/include/linux/pnp.h
+++ linux-2.6.22.1/include/linux/pnp.h
@@ -14,7 +14,7 @@
 #include <linux/errno.h>
 #include <linux/mod_devicetable.h>
 
-#define PNP_MAX_PORT		8
+#define PNP_MAX_PORT		32
 #define PNP_MAX_MEM		4
 #define PNP_MAX_IRQ		2
 #define PNP_MAX_DMA		2
Index: linux-2.6.22.1/drivers/pnp/pnpacpi/rsparser.c
===================================================================
--- linux-2.6.22.1.orig/drivers/pnp/pnpacpi/rsparser.c
+++ linux-2.6.22.1/drivers/pnp/pnpacpi/rsparser.c
@@ -185,7 +185,8 @@ pnpacpi_parse_allocated_ioresource(struc
 		}
 		res->port_resource[i].start = io;
 		res->port_resource[i].end = io + len - 1;
-	}
+	} else
+		pnp_dbg("Run out of pnp ports - MAX_PNP_PORT must be increased");
 }
 
 static void




             reply	other threads:[~2007-07-16 14:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-16 14:21 Thomas Renninger [this message]
2007-07-16 16:48 ` [PATCH] - Increase PNP_MAX_PORT. ACPI devices can have a lot IO resource declarations Jean Delvare
2007-07-17 15:49 ` Bjorn Helgaas
2007-07-18  8:21   ` Thomas Renninger
2007-07-18 21:33     ` Bjorn Helgaas
2007-07-19  9:23       ` Thomas Renninger

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=1184595667.19959.312.camel@queen.suse.de \
    --to=trenn@suse.de \
    --cc=aystarik@gmail.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=bwalle@suse.de \
    --cc=khali@linux-fr.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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