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]

Message-ID: <20110704180216.4dc9c79d@lxorguk.ukuu.org.uk>
Date:	Mon, 4 Jul 2011 18:02:16 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
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

> Where I failed so far is the dynamic configuration of ports using
> setserial. This intentionally allows changing the io_type setting
> as well as the actual resources (ioport, mapbase, irq, ...).
> Changing the io_type is not supported by /bin/setserial, but
> other tools might be doing it.
> 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 ?
 
> 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

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