[PATCH] make 8250_pnp use pnp_manual_config_dev()

[PATCH] make 8250_pnp use pnp_manual_config_dev()

[Aristeu Sergio Rozanski Filho]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

Hi,
	this patch makes 8250_pnp use pnp_manual_config_dev() so
	pnp_reserve_{io,irq} option will be valid for serial ports too.
	Please consider applying

-- 
Aristeu


[-- Attachment #2: 8250_pnp-use_pnp_manual_config_dev.patch --]
[-- Type: text/plain, Size: 949 bytes --]

o Use pnp_manual_config_dev()

Signed-off-by: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>

Index: 2.6/drivers/serial/8250_pnp.c
===================================================================
--- 2.6.orig/drivers/serial/8250_pnp.c	2005-05-09 17:33:05.000000000 -0300
+++ 2.6/drivers/serial/8250_pnp.c	2005-05-09 17:33:59.000000000 -0300
@@ -397,6 +397,7 @@
 serial_pnp_probe(struct pnp_dev * dev, const struct pnp_device_id *dev_id)
 {
 	struct uart_port port;
+	struct pnp_resource_table table;
 	int ret, line, flags = dev_id->driver_data;
 
 	if (flags & UNKNOWN_DEV) {
@@ -418,6 +419,13 @@
 	port.uartclk = 1843200;
 	port.dev = &dev->dev;
 
+	pnp_init_resource_table(&table);
+	pnp_resource_change(&table.port_resource[0], port.iobase, 8);
+	pnp_resource_change(&table.irq_resource[0], port.irq, 1);
+
+	if (pnp_manual_config_dev(dev, &table, 0))
+		return -ENODEV;
+
 	line = serial8250_register_port(&port);
 
 	if (line >= 0)

Re: [PATCH] make 8250_pnp use pnp_manual_config_dev()

[Russell King]

On Tue, May 10, 2005 at 09:15:21AM -0300, Aristeu Sergio Rozanski Filho wrote:
> Hi,
> 	this patch makes 8250_pnp use pnp_manual_config_dev() so
> 	pnp_reserve_{io,irq} option will be valid for serial ports too.
> 	Please consider applying

Please copy this to Adam Belay.  There are some problems with PNP
serial ports because they can clash with with standard addresses
for x86 ports.

We don't particularly want to reconfigure the standard x86 ports
to some other addresses just because we've already detected them
and claimed their resources external to PNP.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [PATCH] make 8250_pnp use pnp_manual_config_dev()

[Aristeu Sergio Rozanski Filho]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

> > Hi,
> > 	this patch makes 8250_pnp use pnp_manual_config_dev() so
> > 	pnp_reserve_{io,irq} option will be valid for serial ports too.
> > 	Please consider applying
> 
> Please copy this to Adam Belay.  There are some problems with PNP
> serial ports because they can clash with with standard addresses
> for x86 ports.
> 
> We don't particularly want to reconfigure the standard x86 ports
> to some other addresses just because we've already detected them
> and claimed their resources external to PNP.
OK, adding Adam Belay to CC and attaching the patch again.

--
Aristeu


[-- Attachment #2: 8250_pnp-use_pnp_manual_config_dev.patch --]
[-- Type: text/plain, Size: 949 bytes --]

o Use pnp_manual_config_dev()

Signed-off-by: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>

Index: 2.6/drivers/serial/8250_pnp.c
===================================================================
--- 2.6.orig/drivers/serial/8250_pnp.c	2005-05-09 17:33:05.000000000 -0300
+++ 2.6/drivers/serial/8250_pnp.c	2005-05-09 17:33:59.000000000 -0300
@@ -397,6 +397,7 @@
 serial_pnp_probe(struct pnp_dev * dev, const struct pnp_device_id *dev_id)
 {
 	struct uart_port port;
+	struct pnp_resource_table table;
 	int ret, line, flags = dev_id->driver_data;
 
 	if (flags & UNKNOWN_DEV) {
@@ -418,6 +419,13 @@
 	port.uartclk = 1843200;
 	port.dev = &dev->dev;
 
+	pnp_init_resource_table(&table);
+	pnp_resource_change(&table.port_resource[0], port.iobase, 8);
+	pnp_resource_change(&table.irq_resource[0], port.irq, 1);
+
+	if (pnp_manual_config_dev(dev, &table, 0))
+		return -ENODEV;
+
 	line = serial8250_register_port(&port);
 
 	if (line >= 0)

Re: [PATCH] make 8250_pnp use pnp_manual_config_dev()

[Adam Belay]

On Tue, May 10, 2005 at 10:07:15AM -0300, Aristeu Sergio Rozanski Filho wrote:
> > > Hi,
> > > 	this patch makes 8250_pnp use pnp_manual_config_dev() so
> > > 	pnp_reserve_{io,irq} option will be valid for serial ports too.
> > > 	Please consider applying

pnp_manual_config_dev is intented for drivers that use different
resource assignments than those automatically set by PnP.  It looks
like you're passing the same config back.

Could you please explain your rational here further.

Values already assigned by the BIOS are not checked against reserved
regions.  Is this what you're getting it?  If so, we could have double
detection issues between the PnP protocol and the legacy detection
mechanism.


> > 
> > Please copy this to Adam Belay.  There are some problems with PNP
> > serial ports because they can clash with with standard addresses
> > for x86 ports.

Ideally, I think we should avoid legacy probing if PnPBIOS or ACPI is
available.  When serial console is enabled we could have an exception.
What do you think?

> > 
> > We don't particularly want to reconfigure the standard x86 ports
> > to some other addresses just because we've already detected them
> > and claimed their resources external to PNP.
> OK, adding Adam Belay to CC and attaching the patch again.
> 
> --
> Aristeu

Thanks,
Adam

Re: [PATCH] make 8250_pnp use pnp_manual_config_dev()

[Aristeu Sergio Rozanski Filho]

> pnp_manual_config_dev is intented for drivers that use different
> resource assignments than those automatically set by PnP.  It looks
> like you're passing the same config back.
> 
> Could you please explain your rational here further.
> 
> Values already assigned by the BIOS are not checked against reserved
> regions.  Is this what you're getting it?  If so, we could have double
> detection issues between the PnP protocol and the legacy detection
> mechanism.
My idea was just to enforce pnp_reserve_{io,irq} options for serial
ports too (8250_pnp does not check for those options). I was looking for a
way of ignoring a serial port I/O range (before Russell King point me to
setserial).
So, yes, please drop this patch as my problem is already solved in a
different (and much better) way. :)

--
Aristeu