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
| ||
|
Date: Mon, 3 Nov 2014 09:50:51 +0000 From: Will Deacon <will.deacon@....com> To: Ard Biesheuvel <ard.biesheuvel@...aro.org> Cc: "Wang, Yalin" <Yalin.Wang@...ymobile.com>, Russell King - ARM Linux <linux@....linux.org.uk>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "akinobu.mita@...il.com" <akinobu.mita@...il.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, Joe Perches <joe@...ches.com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [RFC V6 3/3] arm64:add bitrev.h file to support rbit instruction On Mon, Nov 03, 2014 at 08:47:32AM +0000, Ard Biesheuvel wrote: > On 3 November 2014 03:17, Wang, Yalin <Yalin.Wang@...ymobile.com> wrote: > >> From: Will Deacon [mailto:will.deacon@....com] > >> > +#ifndef __ASM_ARM64_BITREV_H > >> > +#define __ASM_ARM64_BITREV_H > >> > >> Really minor nit, but we don't tend to include 'ARM64' in our header guards, > >> so this should just be __ASM_BITREV_H. > >> > >> With that change, > >> > >> Acked-by: Will Deacon <will.deacon@....com> > >> > > I have send the patch to the patch system: > > http://www.arm.linux.org.uk/developer/patches/search.php?uid=4025 > > > > 8187/1 8188/1 8189/1 > > > > Just remind you that , should also cherry-pick Joe Perches's > > 2 patches: > > [PATCH] 6fire: Convert byte_rev_table uses to bitrev8 > > [PATCH] carl9170: Convert byte_rev_table uses to bitrev8 > > > > To make sure there is no build error when build these 2 drivers. > > > > If this is the case, I suggest you update patch 8187/1 to retain the > byte_rev_table symbol, even in the accelerated case, and remove it > with a followup patch once Joe's patches have landed upstream. Also, a > link to the patches would be nice, and perhaps a bit of explanation > how/when they are expected to be merged. Indeed, or instead put together a series with the appropriate acks so somebody can merge it all in one go. Merging this on a piecemeal basis is going to cause breakages (as you pointed out). Will -- 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/
Powered by blists - more mailing lists