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 for Android: free password hash cracker in your pocket

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

Message-Id: <201107041835.22660.arnd@arndb.de>
Date:	Mon, 4 Jul 2011 18:35:22 +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 Tuesday 28 June 2011, Alan Cox wrote:
> Agreed but that can be done by io_serial_in/io_serial_out out of the
> 8250.c file. Really we need p->ops or a function in another file which
> provides the ioport 8250 interface and then all you'd have in the core
> code would be
> 
>         uart8250_set_ioport_ops(p);
> 
> which would live in 8250_ioport.c or be a "return -EINVAL' for anything
> else. 
> 
> That leaves request/release_std resources depending how such platforms
> handle request_region attempts, and the other fourport bits which want
> pushing into the 8250f_fourport driver perhaps as extra p-> ops.
> 
>         if (p->startup)
>                 p->startup(p);
> 
> etc
> 
> (Or indeed probably a p->ops-> for the lot is even saner)
> 
> Thoughts ?

I've tried a few of variations of that now, and I felt that I'm
getting drawn into some of the darkest corners of Linux driver
history ;-)

I first started out by separating the classing ISA device probing
and the platform driver into separate files. I think these
are useful to split out, because e.g. the PCI driver has no
dependency on either. Having the option to build without the
ISA stuff simplifies a lot of things.

I also made a patch for the mn10300 use of SERIAL_PORT_DFNS,
which is the only architecture that defines non-ISA ports
that way.

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.

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?

	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/