linux-kernel - Re: [PATCH 18/18] asm-generic: io: define relaxed accessor macros unconditionally

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:	Tue, 22 Apr 2014 16:09:46 +0200
From:	Michal Simek <monstr@...str.eu>
To:	Will Deacon <will.deacon@....com>
CC:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	arnd@...db.de, dhowells@...hat.com, broonie@...aro.org,
	benh@...nel.crashing.org, peterz@...radead.org,
	paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH 18/18] asm-generic: io: define relaxed accessor macros
 unconditionally

On 04/17/2014 03:44 PM, Will Deacon wrote:
> Now that no architectures using asm-generic/io.h define their own relaxed
> accessors, the dummy definitions can be used unconditionally.
> 
> Cc: Arnd Bergmann <arnd@...db.de>
> Signed-off-by: Will Deacon <will.deacon@....com>
> ---
>  include/asm-generic/io.h | 18 ------------------
>  1 file changed, 18 deletions(-)

Do we need this? I think there could be a need to overwrite them.
Currently we are just lucky that architecture which uses asm-generic/io.h
don't need to overwrite it.
But I expect that all archs should use asm-generic/io.h to clean
architecture io.h exactly I have done it for Microblaze.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)