Re: [2.6.23-rc3 possible regression] 8250 claims nonexisting device blocking IO port

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Friday 24 August 2007 11:42:36 am Andrey Borzenkov wrote:
> On Tuesday 21 August 2007, Bjorn Helgaas wrote:
> > On Tuesday 21 August 2007 12:28:49 pm Andrey Borzenkov wrote:
> > > On Monday 20 August 2007, Bjorn Helgaas wrote:
> > > > On Monday 20 August 2007 10:28:22 am Andrey Borzenkov wrote:
> > > > > This worked in 2.6.22 with the same quirks. I will test without later
> > > > > but I fail to see how they are related.
> > > >
> > > > OK, let me know what happens.  The way it's related is that the quirk
> > > > fiddles with the IRDA device, and it probably changes the SIR config
> > > > so that it starts responding at the ttyS3 address.
> > >
> > > You are probably right. Disabling quirk makes it work again (with pnp off
> > > in smsc-ircc2 of course).
> >
> > I think pnp is off in smsc-ircc2 by default, right?
> >
> > > Hmm ... is there any reason why this quirk is in PnP core in the first
> > > place? Would not it be more logical to have it in (PnP) part of
> > > smsc-ircc2? This way it could share code with legacy detection; and it
> > > even may have chance to work - assuming BIOS is aware that 0x100 is
> > > claimed by PCMCIA it could allocate different port when we try to
> > > activate device after that ... should I give it a try?
> >
> > I agree it would make sense to put the quirk in smsc-ircc2, since
> > we only need it if we want to use the smsc-ircc2 driver.  But I don't
> > think we have a mechanism for calling quirks at module load-time, so
> > it has to be part of the static kernel.  And we don't have anything
> > like DECLARE_PCI_FIXUP_SECTION, so it really has to be in quirks.c for
> > now.
> >
> > How does the following patch look?
> >
> I am fine with any patch that works. Of course, it would be better to fix 8250 
> to respect PnP (it does load 8250_pnp in the first place).

I agree.  8250_pnp is actually fine -- it won't claim SMCf010 devices.
The problem is that we have the legacy addresses (including the SMCf010
SIR range) in SERIAL_PORT_DFNS, so 8250.c claims the SIR range in
serial8250_isa_init_ports().

I'm still hoping to fix that bit of 8250, but it's going to take some
work.

I'll post the SMCf010 quirk removal as a fix for the 2.6.23-rc3
regression.

Bjorn