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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200708241233.55698.bjorn.helgaas@hp.com>
Date:	Fri, 24 Aug 2007 12:33:55 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Andrey Borzenkov <arvidjaar@...l.ru>
Cc:	linux-serial@...r.kernel.org,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6.23-rc3 possible regression] 8250 claims nonexisting device blocking IO port

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


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