linux-kernel - Re: [PATCH 7/7] serial/8250: make PIO support optional

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Jul 2011 21:27:31 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Greg Kroah-Hartman" <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH 7/7] serial/8250: make PIO support optional

On Monday 04 July 2011 19:02:16 Alan Cox wrote:

> > My question is whether we should still care about those. If
> > we can remove the reconfiguration of existing ports or move
> > it to one of the more obscure parts of the driver, it's possible
> > to confine the dependencies on the ioport_ops to the front-end
> > drivers, while the core 8250 library driver would not need it
> > any more.
> 
> otherwise you need a table that drivers register their port types
> in and to take module references on the table entry to pin the relevant
> driver code ?

I hadn't even thought of that, but yes. I would consider that
worse than leaving both UPIO variants defined in the 8250 core
file after some cleanups, and adding the #ifdef that you object
to.

Yet another option would be to separate out the ioport_ops into
a file for each one, but make them conditionally compiled, with
a direct reference from 8250.o that gets compiled out if no
other front-end ever needs it.

> > Today, most ports don't set the UPF_FIXED flag, even though
> > the ports definitely have fixed resources, e.g. all of the
> > 8250-platform drivers in arch/ or the 8250_pnp and 8250_cs
> > front-ends. Do you think it would be reasonable to mark all
> > 8250 ports except the ISA ones as UPF_FIXED, and move the
> > reconfiguration logic into the 8250_isa driver along with
> > old_serial_port, serial8250_isa_devs,  and
> > serial8250_isa_init_ports?
> 
> I suspect one or two people will scream about some peculiar configuration
> that should be handled automatically anyway and those are best fixed
> properly if so rather than by allowing setserial incantations to work
> around stuff like unknown PCI idents.

Ok, makes sense. If I split this out to the ISA driver, I would
probably also disallow changing io_type, as ISA 8250 ports are
all based on PIO mode.

The only use cases that I can think of for run-time configuration
of MMIO based 8250 ports are the misdetected PCI cards you mentioned
and weird embedded systems that fail to register the port correctly.

Both can be addressed by fixing them at the source.

	Arnd
--
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/