Re: [PATCH] - Increase PNP_MAX_PORT. ACPI devices can have a lot IOresource declarations

[Jean Delvare]

Hi Thomas,

On Mon, 16 Jul 2007 16:21:07 +0200, Thomas Renninger wrote:
> 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.

I just tested on my own workstation, and 8 wasn't enough for me either:
there are 12 resources listed for the PNP0C02 device on my workstation.

After applying your patch, I get the following differences in /proc/ioports:

--- ioports.before      2007-07-16 18:29:30.000000000 +0200
+++ ioports.after       2007-07-16 18:39:05.000000000 +0200
@@ -13,7 +13,8 @@
 01f0-01f7 : 0000:00:0f.0
   01f0-01f7 : ide0
 0290-0297 : f71805f
-  0295-0296 : f71805f
+  0290-0297 : pnp 00:03
+    0295-0296 : f71805f
 0376-0376 : 0000:00:0f.0
   0376-0376 : ide1
 0378-037a : parport0
@@ -21,6 +22,8 @@
 03f6-03f6 : 0000:00:0f.0
   03f6-03f6 : ide0
 03f8-03ff : serial
+04d0-04d1 : pnp 00:03
+0800-0805 : pnp 00:03
 0cf8-0cff : PCI conf1
 4000-407f : pnp 00:02
   4000-4003 : ACPI PM1a_EVT_BLK

> (...)
> ------------------
> 
> 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@xxxxxxx>
> 
> ---
>  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");

PNP_MAX_PORT, not MAX_PNP_PORT.

>  }
>  
>  static void

I like this patch and I'd like to see it upstream soon. I think it can
even be improved:

* If we run out of pnp ports, we should print an error message rather
than a debug message. If it takes CONFIG_PNP_DEBUG=y to get reports
that the max is too low, we won't have many reports.

* Can we have similar messages for PNP_MAX_MEM, PNP_MAX_IRQ and
PNP_MAX_DMA? I think that we really want to know when we hit limits for
these too.

Thanks,
-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/