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

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:

quoted

On Thu, Nov 13, 2014 at 04:05:30PM -0800, Joe Perches wrote:

quoted

On Thu, 2014-11-13 at 23:53 +0000, Russell King - ARM Linux wrote:

quoted

On Fri, Oct 31, 2014 at 01:42:44PM +0800, Wang, Yalin wrote:

quoted

This patch add bitrev.h file to support rbit instruction,
so that we can do bitrev operation by hardware.
Signed-off-by: Yalin Wang <redacted>
---
 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.)

quoted

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.