gmane.linux.kernel.cross-arch

Re: [PATCH 6/6] serial: add amba-pl011-pci

Alessandro Rubini — 2012-05-26T09:27:12

Ok.


Sure. Thanks for noting. Maybe it wasn't there when I coded this
initially. Will do.


Yes. After sending I noted this and another point. I apologize.
Version 2 will be fixed in all respects.


Thanks a lot for this and also the comments on APB/AHB in the other message.

/alessandro

Re: [PATCH 13/20] arm: Do not call try_to_freeze() in do_signal()

Richard Weinberger — 2012-05-26T08:55:09

Am 26.05.2012 01:43, schrieb Russell King - ARM Linux:

Okay.
I've rebased my patches to Al's signal tree to avoid further conflicts.

Thanks,
//richard

Re: [PATCH 6/6] serial: add amba-pl011-pci

Russell King - ARM Linux — 2012-05-26T08:48:19

One other point.

On Fri, May 25, 2012 at 05:48:57PM +0200, Alessandro Rubini wrote:

APB device.  It's a _peripheral_, it only has a _slave_ port which can't
initiate DMA, so:


This is pointless and unnecessary.  The PL011 driver itself doesn't use
_this_ struct device for anything to do with DMA at all.  That's all
handled by the DMA engine's struct device.

That's true of all APB devices.  Only AHB devices with a master port can
initiate bus transactions, and hence cause accesses to other parts of the
system.

Re: Mostly portable strnlen_user()

Jonas Bonn — 2012-05-26T08:32:51

On 26 May 2012 06:19, Linus Torvalds <torvalds< at >linux-foundation.org> wrote:

I gave this a try on OpenRISC... works fine here, too.

/Jonas

Re: Mostly portable strnlen_user()

David Miller — 2012-05-26T05:59:18

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 22:06:31 -0700


Aha, I see, yes it does work without adding the sparc header.

Re: Mostly portable strnlen_user()

Linus Torvalds — 2012-05-26T05:06:31

Good. I'll combine things and then split them up a bit differently (ie
a "create generic version" patch and then separate "start using
generic version" patches for x86 and sparc).


This part *should* be unnecessary, I already did the

   generic-y += word-at-a-time.h

in arch/sparc/include/asm/Kbuild. Can you verify? Or did something go wrong?

                    Linus

Re: Mostly portable strnlen_user()

David Miller — 2012-05-26T04:44:59

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 21:19:01 -0700


Ok, with the following patch, it seems to work on sparc too.

I'll beat it up with some glibc testsuite runs and stuff like that,
but so far it looks great.

 arch/sparc/Kconfig                      |    1 +
 arch/sparc/include/asm/uaccess_32.h     |   22 ++-----
 arch/sparc/include/asm/uaccess_64.h     |    8 +--
 arch/sparc/include/asm/word-at-a-time.h |    1 +
 arch/sparc/lib/Makefile                 |    1 -
 arch/sparc/lib/ksyms.c                  |    2 -
 arch/sparc/lib/strlen_user_32.S         |  109 -------------------------------
 arch/sparc/lib/strlen_user_64.S         |   97 ---------------------------
 8 files changed, 10 insertions(+), 231 deletions(-)
 create mode 100644 arch/sparc/include/asm/word-at-a-time.h
 delete mode 100644 arch/sparc/lib/strlen_user_32.S
 delete mode 100644 arch/sparc/lib/strlen_user_64.S

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 15e9e05..83bd051 100644
--- a/a

Re: Mostly portable strnlen_user()

David Miller — 2012-05-26T04:34:36

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 21:19:01 -0700


Will do.

Re: Mostly portable strnlen_user()

Linus Torvalds — 2012-05-26T04:19:01

Make sure to take the second patch, the first was scrogged for the
asm-generic case (and thus sparc). It would never have compiled.

The second one should actually hopefully come close to working. At
least I tested the compile by building the lib/ files with that,
instead of the x86 native version.

Obviously the asm-generic version cannot actually work with the dentry
hashing routines (it needs the whole bytemask generation at a minimum
for that), so it may be broken in the sense of "it doesn't actually
work", but it is *closer*. And the concept seems to be ok, since it
seems to work on x86 (I'm running it right now)

                Linus

Re: Mostly portable strnlen_user()

Linus Torvalds — 2012-05-26T04:16:38

On Fri, May 25, 2012 at 8:56 PM, Linus Torvalds
<torvalds< at >linux-foundation.org> wrote:

It actually works on x86 - I just booted it, and it all seems ok. The
extra abstraction generates *one* extra instruction in fs/namei.c, but
on the whole that all seems ok.

But the asm-generic.h thing was in a half-arsed half-way-state between
your version and my final interface, so it sure as hell wouldn't have
worked on sparc or openrisc.

This is the "fix up that header file to actually do what it is
supposed to do" version. Sorry about that,

                   Linus

Re: Mostly portable strnlen_user()

David Miller — 2012-05-26T04:15:52

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 20:56:37 -0700


At first glance, it does.

I play with this and try to get it working on sparc tonight, thanks.

Re: Mostly portable strnlen_user()

Linus Torvalds — 2012-05-26T03:56:37

Ok, I think I have a solution.

This is *totally* untested, but it compiles on x86. And I think it's
"close to the right thing".

It makes those constants explicit, so that sharing them is easy when
we have two different users, and actually does that in fs/namei.c.

The interface is a bit odd, but the rules are:

 - has_zero -> prep_zero_mask -> create_zero_mask -> { zero_bytemask ,
find_zero }

where two masks that have been created by prep_zero_mask can be or'ed
together to create one "one or the other" mask.

So the has_zero -> prep_zero_mask boundary is due to your BE
efficiency issue (ie "has_zero()" goes inside the loop, and
"prep_zero_mask()" goes outside).

The prep_zero_mask -> create_zero_mask boundary is due to that "we can
combine multiple masks at this level" issue.

And the create_zero_mask -> { zero_bytemask , find_zero } boundary is
because we actually want to create a bytemask for some things, and
just find the zero for others.

Does this *work*? I don't know. But it generates code that loo

Re: Mostly portable strnlen_user()

David Miller — 2012-05-26T02:43:18

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 19:13:31 -0700

It CSE's them into the loop, but like I said a few days
ago it doesn't CSE them into the find_zero() code block.

Yes, GCC refused to do it.

It CSEs it into the loop, but not the tail code.

It looks like GCC reconstituting the constants for the zero byte
determination, which on 64-bit is nearly half of the instructions
of the exit path.

But you shouldn't really need to care about this, we can surely
abstract it behind something.

Re: Mostly portable strnlen_user()

Linus Torvalds — 2012-05-26T02:13:31

On Fri, May 25, 2012 at 6:09 PM, Linus Torvalds
<torvalds< at >linux-foundation.org> wrote:

Ugh. So this was not at all as trivial as I thought it would be.

One issue is just syntactic: the fact that you want to initialize
those constants just results in nasty syntax. Is gcc really so bad on
sparc that it doesn't do the obvious CSE etc on the constants? That
surprises me, because it does it on x86-64..

But the more annoying issue is that the dentry code really does depend
on the fact that we can just combine the masks for two values (the
zero bytes and the '/' bytes) and test and munge them together. And
that's simply not true of your big-endian version.

I think that instead of the "find_zero()" function, we need a
"generate_mask()" function that actually generates the reliable mask
of "these bytes have a bit set if the byte was zero". That's the

  unsigned long mask = (c & p->low_bits) + p->low_bits;
  mask = (mask | p->rhs);

phase of the big-endian logic (and would be a no-op on little endian).

So it loo

Re: Mostly portable strnlen_user()

David Miller — 2012-05-26T01:21:45

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 18:09:33 -0700


Agreed, it will look a lot nicer that way.


Ok.

Re: Mostly portable strnlen_user()

Linus Torvalds — 2012-05-26T01:09:33

Looks good to me.


Actually, I think it's better if we just do two separate ones: a
"generic little-endian" and a "generic big-endian" one. Rather than
mixing both into one file that is then included from some arch-file
that statically knows its endianness instead.


I can do that. Give me a few minutes. Or more. Let's see how it ends up..

                 Linus

Re: Mostly portable strnlen_user()

David Miller — 2012-05-26T00:41:35

From: David Miller <davem< at >davemloft.net>
Date: Fri, 25 May 2012 19:41:25 -0400 (EDT)

Ok, something like the following, just to give you an idea.  Just the
sparc word-at-a-time.h header addition and the lib/strnlen_user.c
changes.

Probably I should add little-endian code to the header and put it
under asm-generic instead since there isn't really anything sparc
specific about it and this will make it easier for other ports to use
this stuff.

This is untested and of course we'd need to tweak the x86
word-at-a-time header and adjust the other call sites in
the DCACHE and elsewhere.

In fact, one thing I need to do next is see how suitable these
interface adjustments are for those uses.  I've only really made sure
that they work out for the new generic lib/str*.c routines.

Looking at the assembler, gcc does a reasonable job with the
aggregates, optimizing them just as if they were scalar local
variables.

diff --git a/arch/sparc/include/asm/word-at-a-time.h b/arch/sparc/include/asm/word-at-a-time.h
new file

Re: [PATCH 13/20] arm: Do not call try_to_freeze() in do_signal()

Russell King - ARM Linux — 2012-05-25T23:43:45

NAK.  Please check linux-next (okay, viro's patches haven't appeared
there yet) but a lot of this stuff is covered by a truckload of work
that Al's done.

Please don't work across Al.

commit d9be5ea6f9b6a51535ccdd9881ffb3be2dbd48e9
Author: Al Viro <viro< at >zeniv.linux.org.uk>
Date:   Fri Apr 27 01:18:52 2012 -0400

    arm: don't call try_to_freeze() from do_signal()
    
    get_signal_to_deliver() will handle it itself
    
    Signed-off-by: Al Viro <viro< at >zeniv.linux.org.uk>

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index a6c4e78..3b37c14 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
< at >< at > -642,9 +642,6 < at >< at > static void do_signal(struct pt_regs *regs, int syscall)
                }
        }
 
-       if (try_to_freeze())
-               goto no_signal;
-
        /*
         * Get the signal to deliver.  When running under ptrace, at this
         * point the debugger may change all our registers ...
< at >< at > -684,7 +681,6 < at >< at > static void do_signal(struct pt_regs *regs, i

Re: Mostly portable strnlen_user()

David Miller — 2012-05-25T23:41:25

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 16:37:40 -0700


I'm playing around with this now, I should have something for you
to look at in the next few hours.

Re: Mostly portable strnlen_user()

Linus Torvalds — 2012-05-25T23:37:40

Gcc is *usually* pretty good about optimizing small structures on the
stack, even if you pass a pointer (if the pointer then always gets
dereferenced within that function). So I think you could try the
"pointer to opaque thing" approach and see.

But yeah, the macro approach obviously puts much less reliance on the
optimizer getting things right, so it might be the way to go if it
turns out that gcc screws up code generation.

                  Linus

Re: Mostly portable strnlen_user()

David Miller — 2012-05-25T23:14:07

From: Linus Torvalds <torvalds< at >linux-foundation.org>
Date: Fri, 25 May 2012 16:11:36 -0700


That might be better.

I suppose then I'd need to make BE's has_zero() a macro instead of a
function.  Either that or we pass a pointer to this opaque typedef
thing.