[PATCH 5/5]8250_pnp fix

[PATCH 5/5]8250_pnp fix

[Li Shaohua]

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

Hi,
This is a small fix found when debugging the 8250 driver in IA64.

Thanks,
Shaohua

Signed-off-by: Li Shaohua <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

--- 2.6/drivers/serial/8250_pnp.c.stg4	2004-09-28 11:27:42.371840736
+0800
+++ 2.6/drivers/serial/8250_pnp.c	2004-09-28 11:28:14.036027048 +0800
@@ -407,7 +407,7 @@ serial_pnp_probe(struct pnp_dev * dev, c
 	serial_req.irq = pnp_irq(dev,0);
 	serial_req.port = pnp_port_start(dev, 0);
 	if (HIGH_BITS_OFFSET)
-		serial_req.port = pnp_port_start(dev, 0) >> HIGH_BITS_OFFSET;
+		serial_req.port_high = pnp_port_start(dev, 0) >> HIGH_BITS_OFFSET;
 #ifdef SERIAL_DEBUG_PNP
 	printk("Setup PNP port: port %x, irq %d, type %d\n",
 	       serial_req.port, serial_req.irq, serial_req.io_type);


[-- Attachment #2: 8250.patch --]
[-- Type: text/x-patch, Size: 587 bytes --]

--- 2.6/drivers/serial/8250_pnp.c.stg4	2004-09-28 11:27:42.371840736 +0800
+++ 2.6/drivers/serial/8250_pnp.c	2004-09-28 11:28:14.036027048 +0800
@@ -407,7 +407,7 @@ serial_pnp_probe(struct pnp_dev * dev, c
 	serial_req.irq = pnp_irq(dev,0);
 	serial_req.port = pnp_port_start(dev, 0);
 	if (HIGH_BITS_OFFSET)
-		serial_req.port = pnp_port_start(dev, 0) >> HIGH_BITS_OFFSET;
+		serial_req.port_high = pnp_port_start(dev, 0) >> HIGH_BITS_OFFSET;
 #ifdef SERIAL_DEBUG_PNP
 	printk("Setup PNP port: port %x, irq %d, type %d\n",
 	       serial_req.port, serial_req.irq, serial_req.io_type);

Re: [PATCH 5/5]8250_pnp fix

[Len Brown]

Applied.

thanks,
-Len

On Wed, 2004-10-20 at 23:00, Li Shaohua wrote:
> Hi,
> This is a small fix found when debugging the 8250 driver in IA64.
> 
> Thanks,
> Shaohua
> 
> Signed-off-by: Li Shaohua <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> --- 2.6/drivers/serial/8250_pnp.c.stg4  2004-09-28 11:27:42.371840736
> +0800
> +++ 2.6/drivers/serial/8250_pnp.c       2004-09-28 11:28:14.036027048
> +0800
> @@ -407,7 +407,7 @@ serial_pnp_probe(struct pnp_dev * dev, c
>         serial_req.irq = pnp_irq(dev,0);
>         serial_req.port = pnp_port_start(dev, 0);
>         if (HIGH_BITS_OFFSET)
> -               serial_req.port = pnp_port_start(dev, 0) >>
> HIGH_BITS_OFFSET;
> +               serial_req.port_high = pnp_port_start(dev, 0) >>
> HIGH_BITS_OFFSET;
>  #ifdef SERIAL_DEBUG_PNP
>         printk("Setup PNP port: port %x, irq %d, type %d\n",
>                serial_req.port, serial_req.irq, serial_req.io_type);
> 
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

PNPACPI / 8250 discovery

[Bjorn Helgaas]

Hi Li,

I haven't seen much activity on the PNPACPI front recently.

If/when we switch from 8250_acpi to 8250_pnp, serial device
names will change (8250_acpi devices are discovered *before*
8250_pci, but 8250_pnp is currently *after* 8250_pci in
drivers/serial/Makefile).

Do you plan to switch that around?  I think it makes more
sense to have PNP/ACPI devices named before PCI, since the
PNP/ACPI ones are more likely to be built-in.

Bjorn


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: PNPACPI / 8250 discovery

[Li Shaohua]

On Tue, 2004-12-07 at 09:36, Bjorn Helgaas wrote:
Hi Bjorn,
> I haven't seen much activity on the PNPACPI front recently.
> 
> If/when we switch from 8250_acpi to 8250_pnp, serial device
> names will change (8250_acpi devices are discovered *before*
> 8250_pci, but 8250_pnp is currently *after* 8250_pci in
> drivers/serial/Makefile).
This makes sense to me. Matthieu is working on migrating acpi drivers to
pnp drivers, so I actually didn't look at them.

> Do you plan to switch that around?  I think it makes more
> sense to have PNP/ACPI devices named before PCI, since the
> PNP/ACPI ones are more likely to be built-in.
Currently PNP/ACPI uses some ACPI bus APIs, which only work after ACPI
scan, but the scan is very latter. We need change ACPI driver and PNP
link order for this (at least the PNP driver should be before ACPI PCI
root drvier). The order would be: 
1. ACPI scan bus
2. register PNP drivers
3. register ACPI drivers
I will work on it, but I'd like to listen to Len and Adam's opinion for
it.

Thanks,
Shaohua



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/