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: Sat, 6 Apr 2024 01:33:22 +0300
From: Andy Shevchenko <andy@...ck.fi.intel.com>
To: Niklas Schnelle <schnelle@...ux.ibm.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	linux-serial@...r.kernel.org, Arnd Bergmann <arnd@...nel.org>,
	Heiko Carstens <hca@...ux.ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] tty: Handle HAS_IOPORT dependencies

On Fri, Apr 05, 2024 at 05:29:23PM +0200, Niklas Schnelle wrote:
> Hi Greg, Jiri, Ilpo,
> 
> This is a follow up in my ongoing effort of making inb()/outb() and
> similar I/O port accessors compile-time optional. Previously I sent this
> as a treewide series titled "treewide: Remove I/O port accessors for
> HAS_IOPORT=n" with the latest being its 5th version[0]. With a significant
> subset of patches merged I've changed over to per-subsystem series. These
> series are stand alone and should be merged via the relevant tree such
> that with all subsystems complete we can follow this up with the final
> patch that will make the I/O port accessors compile-time optional.
> 
> The current state of the full series with changes to the remaining subsystems
> and the aforementioned final patch can be found for your convenience on my
> git.kernel.org tree in the has_ioport branch[1]. As for compile-time vs runtime
> see Linus' reply to my first attempt[2].
> 
> The patch was previously acked[3] by Greg but given this was almost
> a year ago and didn't apply then I didn't carry the Ack over. That said
> I don't think there were non trivial changes.

Hmm... Can those drivers simply be converted to use ioreadXX/iowriteXX
instead?

-- 
With Best Regards,
Andy Shevchenko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ