Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Thu, Nov 13, 2014 at 04:45:43PM -0800, Joe Perches wrote:
> On Fri, 2014-11-14 at 00:17 +0000, Russell King - ARM Linux wrote:
> > On Thu, Nov 13, 2014 at 04:05:30PM -0800, Joe Perches wrote:
> > > On Thu, 2014-11-13 at 23:53 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Oct 31, 2014 at 01:42:44PM +0800, Wang, Yalin wrote:
> > > > > This patch add bitrev.h file to support rbit instruction,
> > > > > so that we can do bitrev operation by hardware.
> > > > > Signed-off-by: Yalin Wang <yalin.wang@sonymobile.com>
> > > > > ---
> > > > >  arch/arm/Kconfig              |  1 +
> > > > >  arch/arm/include/asm/bitrev.h | 21 +++++++++++++++++++++
> > > > >  2 files changed, 22 insertions(+)
> > > > >  create mode 100644 arch/arm/include/asm/bitrev.h
> > > > > 
> > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > > index 89c4b5c..be92b3b 100644
> > > > > --- a/arch/arm/Kconfig
> > > > > +++ b/arch/arm/Kconfig
> > > > > @@ -28,6 +28,7 @@ config ARM
> > > > >  	select HANDLE_DOMAIN_IRQ
> > > > >  	select HARDIRQS_SW_RESEND
> > > > >  	select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > > > > +	select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7)
> > > > 
> > > > Looking at this, this is just wrong.  Take a moment to consider what
> > > > happens if we build a kernel which supports both ARMv6 _and_ ARMv7 CPUs.
> > > > What happens if an ARMv6 CPU tries to execute an rbit instruction?
> > > > 
> > > > Second point (which isn't obvious from your submissions on-list) is that
> > > > you've loaded the patch system up with patches for other parts of the
> > > > kernel tree for which I am not responsible for.  As such, I can't take
> > > > those patches without the sub-tree maintainer acking them.  Also, the
> > > > commit text in those patches look weird:
> > > > 
> > > > 6fire: Convert byte_rev_table uses to bitrev8
> > > > 
> > > > Use the inline function instead of directly indexing the array.
> > > > 
> > > > This allows some architectures with hardware instructions for bit
> > > > reversals to eliminate the array.
> > > > 
> > > > Signed-off-by: Joe Perches <(address hidden)>
> > > > Signed-off-by: Yalin Wang <(address hidden)>
> > > > 
> > > > Why is Joe signing off on these patches?
> > > > Shouldn't his entry be an Acked-by: ?
> > > 
> > > I didn't sign off on or ack the "add bitrev.h" patch.
> > 
> > Correct, I never said you did.  Please read my message a bit more carefully
> > next time, huh?
> 
> You've no reason to write that Russell.

Absolutely I have, but I'm not going to discuss it because I'll just
end up flaming you because in my mind you are the one who is completely
mistaken with your comments.

In case it hasn't been realised, I hardly read this mailing list anymore,
or messages that I'm Cc'd on.  I do read most messages that I'm in the
To: line, but generally not if they're DT changes (which always end up
being marked To: me.)

> > Great, so I can just discard these that were incorrectly submitted to me
> > then.
> 
> I think you shouldn't apply these patches or updated
> ones either until all the current uses are converted.

Where are the dependencies mentioned?  How do I get to know when all
the dependencies are met?  Who is tracking the dependencies?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>