ource tree (for reasons I don't see a need to repeat
> here).
>
>> You could add linux-m...@linux-mips.org if that helps.
>
> I wanted to let the mips folks decide if they should be listedand
> CC'd Helge (parisc maintainer) in case he objected to added
> linux-parisc mailing
stat.h, we do not support HP-UX binaries
since kernel 4.0.
Thanks,
Helge
Helge Deller (2):
parisc: Drop hpux_stat64 struct from stat.h header file
parisc: Fixes and cleanups in kernel uapi header files
arch/parisc/include
stat.h, we do not support HP-UX binaries
since kernel 4.0.
Thanks,
Helge
Helge Deller (2):
parisc: Drop hpux_stat64 struct from stat.h header file
parisc: Fixes and cleanups in kernel uapi header files
arch/parisc/include
Hi Linus,
On 03.11.2015 22:01, Linus Torvalds wrote:
> On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller wrote:
>>
>> please pull some patches for the parisc architecture for kernel v4.3 from:
>
> So no way was I going to pull that for 4.3,
Yes, since you didn't pulled I assu
Hi Linus,
On 03.11.2015 22:01, Linus Torvalds wrote:
> On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller <del...@gmx.de> wrote:
>>
>> please pull some patches for the parisc architecture for kernel v4.3 from:
>
> So no way was I going to pull that for 4.3,
Yes, since you
layer was needed.
Then we wire up the sys_membarrier and userfaultfd syscalls and added two other
small cleanups.
Thanks,
Helge
Axel Lin (1):
parisc: serial/mux: Convert to uart_console_device instead of open-coded
Helge Deller
layer was needed.
Then we wire up the sys_membarrier and userfaultfd syscalls and added two other
small cleanups.
Thanks,
Helge
Axel Lin (1):
parisc: serial/mux: Convert to uart_console_device instead of open-coded
Helge Deller
On 16.09.2015 17:07, Mathieu Desnoyers wrote:
> - On Sep 7, 2015, at 12:15 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> Signed-off-by: Mathieu Desnoyers
>> Tested-by: Helge Deller
>> CC: Andrew Morton
>> CC: linux-...@vger.kernel
On 16.09.2015 17:07, Mathieu Desnoyers wrote:
> - On Sep 7, 2015, at 12:15 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
>> Tested-by: Helge Deller <del...@gmx.de>
,
Helge
Guenter Roeck (1):
parisc: Define ioremap_uc and ioremap_wc
Helge Deller (5):
PCI,parisc: Enable 64-bit bus addresses on PA-RISC
parisc: Additionally check for in_atomic() in page fault handler
parisc
,
Helge
Guenter Roeck (1):
parisc: Define ioremap_uc and ioremap_wc
Helge Deller (5):
PCI,parisc: Enable 64-bit bus addresses on PA-RISC
parisc: Additionally check for in_atomic() in page fault handler
parisc
Hi Andreas,
On 03.09.2015 11:23, Andreas Ziegler wrote:
> today's linux-next tree (next-20150903) contains commit 20f924902ff6
> ("parisc: adjust L1_CACHE_BYTES to 128 bytes on PA8800 and PA8900 CPUs")
> which you authored.
>
> I noticed it because we[0] are running a daily analysis on all
C: "James E.J. Bottomley"
> CC: Helge Deller
> CC: linux-par...@vger.kernel.org
> ---
> arch/parisc/include/uapi/asm/unistd.h | 3 ++-
> arch/parisc/kernel/syscall_table.S| 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/parisc/i
Hi Andreas,
On 03.09.2015 11:23, Andreas Ziegler wrote:
> today's linux-next tree (next-20150903) contains commit 20f924902ff6
> ("parisc: adjust L1_CACHE_BYTES to 128 bytes on PA8800 and PA8900 CPUs")
> which you authored.
>
> I noticed it because we[0] are running a daily analysis on all
t;a...@linux-foundation.org>
> CC: linux-...@vger.kernel.org
> CC: "James E.J. Bottomley" <j...@parisc-linux.org>
> CC: Helge Deller <del...@gmx.de>
> CC: linux-par...@vger.kernel.org
> ---
> arch/parisc/include/uapi/asm/unistd.h | 3 ++-
> arch/pari
Hi Linus,
please pull the latest fixes for the parisc architecture for v4.2 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.2-2
A memory leak fix from Christophe Jaillet which was introduced with kernel 4.0
and which leads to kernel crashes on parisc
Hi Linus,
please pull the latest fixes for the parisc architecture for v4.2 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.2-2
A memory leak fix from Christophe Jaillet which was introduced with kernel 4.0
and which leads to kernel crashes on parisc
ue already in this thread:
http://marc.info/?l=linux-parisc=142999113232154=2
Signed-off-by: Christophe JAILLET
Acked-by: Helge Deller
Will this patch be pushed via linux-mm or another tree, if
not I can take it via the parisc tree?
Helge
---
This patch is *untested* as I don't have the hardwa
in this thread:
http://marc.info/?l=linux-pariscm=142999113232154w=2
Signed-off-by: Christophe JAILLET christophe.jail...@wanadoo.fr
Acked-by: Helge Deller del...@gmx.de
Will this patch be pushed via linux-mm or another tree, if
not I can take it via the parisc tree?
Helge
---
This patch is *untested
Hi Linus,
please pull the latest fixes for the parisc architecture for v4.2-rc2 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.2-1
We have one important patch from Dave Anglin and myself which fixes PTE/TLB
race conditions which caused random
Hi Linus,
please pull the latest fixes for the parisc architecture for v4.2-rc2 from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.2-1
We have one important patch from Dave Anglin and myself which fixes PTE/TLB
race conditions which caused random
Hi Linus,
* Linus Torvalds :
> On Thu, Jun 4, 2015 at 6:45 AM, Helge Deller wrote:
> >
> > Do you want me to send it again cleaned up, or will you just take yours?
>
> I'd prefer to get a re-send, I've already nuked the patch from me tree.
Sure.
The new patch is attache
Hi Linus,
On 02.06.2015 03:49, Linus Torvalds wrote:
On Mon, Jun 1, 2015 at 11:44 AM, Helge Deller wrote:
Since nr_compat_longs gets unconditionally decremented in each loop, it's type
needs to be signed instead of unsigned to avoid possibly accessing userspace
memory behind the bitmap which
Hi Linus,
* Linus Torvalds torva...@linux-foundation.org:
On Thu, Jun 4, 2015 at 6:45 AM, Helge Deller del...@gmx.de wrote:
Do you want me to send it again cleaned up, or will you just take yours?
I'd prefer to get a re-send, I've already nuked the patch from me tree.
Sure.
The new patch
Hi Linus,
On 02.06.2015 03:49, Linus Torvalds wrote:
On Mon, Jun 1, 2015 at 11:44 AM, Helge Deller del...@gmx.de wrote:
Since nr_compat_longs gets unconditionally decremented in each loop, it's type
needs to be signed instead of unsigned to avoid possibly accessing userspace
memory behind
ame coding. I didn't checked earlier versions.
Signed-off-by: Helge Deller
To: Al Viro
Cc: sta...@vger.kernel.org
diff --git a/kernel/compat.c b/kernel/compat.c
index 24f0061..bfbb312 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -893,7 +893,7 @@ long compat_get_bitmap(unsigned long *m
coding. I didn't checked earlier versions.
Signed-off-by: Helge Deller del...@gmx.de
To: Al Viro v...@zeniv.linux.org.uk
Cc: sta...@vger.kernel.org
diff --git a/kernel/compat.c b/kernel/compat.c
index 24f0061..bfbb312 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -893,7 +893,7 @@ long
of the kthread_arg() function and fixes a
printk output.
Thanks,
Helge
Alex Dowad (1):
parisc: copy_thread(): rename 'arg' argument to 'kthread_arg'
Helge Deller (1):
parisc,metag: Fix crashes due to stack randomization
of the kthread_arg() function and fixes a
printk output.
Thanks,
Helge
Alex Dowad (1):
parisc: copy_thread(): rename 'arg' argument to 'kthread_arg'
Helge Deller (1):
parisc,metag: Fix crashes due to stack randomization
randomization.
The changes to fs/exec.c are inside an "#ifdef CONFIG_STACK_GROWSUP"
section, so it does not affect other platformws beside those where the
stack grows upwards (parisc and metag).
Signed-off-by: Helge Deller
Cc: linux-par...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
randomization.
The changes to fs/exec.c are inside an #ifdef CONFIG_STACK_GROWSUP
section, so it does not affect other platformws beside those where the
stack grows upwards (parisc and metag).
Signed-off-by: Helge Deller del...@gmx.de
Cc: linux-par...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc
Hi Linus,
Please pull two patches for kernel v4.1 for the parisc architecture from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.1-1
The patch by Guenter Roeck fixes the build on parisc which got broken because
of commit f24ffde43237 (parisc: expose number of
Hi Linus,
Please pull two patches for kernel v4.1 for the parisc architecture from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.1-1
The patch by Guenter Roeck fixes the build on parisc which got broken because
of commit f24ffde43237 (parisc: expose number of
Helge Deller (2):
parisc: Add compile-time check when adding new syscalls
parisc: Fix pmd code to depend on PT_NLEVELS value, not on CONFIG_64BIT
Mikulas Patocka (1):
parisc: mm: don't count preallocated pmds
arch/parisc/include/asm/pgalloc.h | 17 ++---
arch/parisc
Helge Deller (2):
parisc: Add compile-time check when adding new syscalls
parisc: Fix pmd code to depend on PT_NLEVELS value, not on CONFIG_64BIT
Mikulas Patocka (1):
parisc: mm: don't count preallocated pmds
arch/parisc/include/asm/pgalloc.h | 17 ++---
arch/parisc
sparse errors and have
some whitespace cleanups.
Thanks,
Helge
Helge Deller (8):
parisc: Wire up execveat syscall
parisc: Add error checks when building up signal trampoline handler
parisc: hpux - Drop support for HP
H Paul,
On 17.02.2015 09:49, Paul Bolle wrote:
On Mon, 2015-02-16 at 22:24 +0100, Helge Deller wrote:
The hpux code is broken anyway.
I'm going to remove it from the tree.
That happened in commit 04c161497716 ("parisc: hpux - Drop support for
HP-UX binaries"), which is included
H Paul,
On 17.02.2015 09:49, Paul Bolle wrote:
On Mon, 2015-02-16 at 22:24 +0100, Helge Deller wrote:
The hpux code is broken anyway.
I'm going to remove it from the tree.
That happened in commit 04c161497716 (parisc: hpux - Drop support for
HP-UX binaries), which is included in today's
sparse errors and have
some whitespace cleanups.
Thanks,
Helge
Helge Deller (8):
parisc: Wire up execveat syscall
parisc: Add error checks when building up signal trampoline handler
parisc: hpux - Drop support for HP
Hello Nicholas,
On 03.02.2015 10:37, Nicholas Mc Guire wrote:
scanning for if STATEMENT else STATEMENT triggered here - and it does look
like it needs a fix-up or at least some comments.
The if-else here has no effect and the printk will not convey any information
as its always
Hello Nicholas,
On 03.02.2015 10:37, Nicholas Mc Guire wrote:
scanning for if STATEMENT else STATEMENT triggered here - and it does look
like it needs a fix-up or at least some comments.
snip?
int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
{
int fstype;
, parisc and s390 no longer need to implement
their own module_free() at all. avr32 doesn't need module_finalize()
either.
Signed-off-by: Rusty Russell
Cc: Chris Metcalf
Cc: Haavard Skinnemoen
Cc: Hans-Christian Egtvedt
Cc: Tony Luck
Cc: Fenghua Yu
Cc: "James E.J. Bottomley"
Cc: Helge
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit
resources")
Signed-off-by: Yinghai Lu
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
I tested it on the parisc arch - everything OK.
Acked-by: Helge De
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: James E.J. Bottomley j...@parisc-linux.org
Cc: Helge Deller del...@gmx.de
Cc: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Heiko Carstens heiko.carst...@de.ibm.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-i
kordikma...@gmail.com
Fixes: 5b28541552ef (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit
resources)
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: James E.J. Bottomley j...@parisc-linux.org
Cc: Helge Deller del...@gmx.de
Cc: linux-par...@vger.kernel.org
I tested it on the parisc
On 01/02/2015 07:09 PM, Rickard Strandqvist wrote:
Removes some functions that are not used anywhere:
parisc_personality() parisc_fallocate() parisc_sync_file_range()
parisc_fadvise64_64() parisc_readahead() parisc_pwrite64() parisc_pread64()
parisc_ftruncate64() parisc_truncate64()
This was
On 01/02/2015 07:09 PM, Rickard Strandqvist wrote:
Removes some functions that are not used anywhere:
parisc_personality() parisc_fallocate() parisc_sync_file_range()
parisc_fadvise64_64() parisc_readahead() parisc_pwrite64() parisc_pread64()
parisc_ftruncate64() parisc_truncate64()
This was
Hi Linus,
please pull one patch for the parisc architecture for kernel 3.19 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-3.19-1
This patch unbreaks the kernel compilation on parisc with gcc-4.9.
Thanks,
Helge
Hi Linus,
please pull one patch for the parisc architecture for kernel 3.19 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-3.19-1
This patch unbreaks the kernel compilation on parisc with gcc-4.9.
Thanks,
Helge
| 2 +-
For the parisc change:
Acked-by: Helge Deller
Helge
arch/powerpc/Makefile | 6 +++---
arch/x86/Makefile.um | 2 +-
kernel/gcov/Makefile | 2 +-
scripts/Kbuild.include | 7 ++-
6 files changed, 10 insertions(+), 13 deletions
Hi Michael,
On 12/25/2014 10:29 AM, Michael S. Tsirkin wrote:
virtio wants to read bitwise types from userspace using get_user. At the
I don't know the virtio code much yet, but does it makes sense to read bitwise
types?
Will virtio then get possible troubles because of endianess correct as
Hi Michael,
On 12/25/2014 10:29 AM, Michael S. Tsirkin wrote:
virtio wants to read bitwise types from userspace using get_user. At the
I don't know the virtio code much yet, but does it makes sense to read bitwise
types?
Will virtio then get possible troubles because of endianess correct as
/Makefile | 2 +-
For the parisc change:
Acked-by: Helge Deller del...@gmx.de
Helge
arch/powerpc/Makefile | 6 +++---
arch/x86/Makefile.um | 2 +-
kernel/gcov/Makefile | 2 +-
scripts/Kbuild.include | 7 ++-
6 files
compat functions for msgctl, shmat, shmctl and semtimedop syscalls
Thanks,
Helge
Helge Deller (4):
parisc: Wire up bpf syscall
parisc: Use BUILD_BUG() instead of undefined functions
parisc: Use compat layer for msgctl
compat functions for msgctl, shmat, shmctl and semtimedop syscalls
Thanks,
Helge
Helge Deller (4):
parisc: Wire up bpf syscall
parisc: Use BUILD_BUG() instead of undefined functions
parisc: Use compat layer for msgctl
On 10/13/2014 03:41 PM, One Thousand Gnomes wrote:
On Sun, 12 Oct 2014 12:08:37 +0200
Helge Deller wrote:
Hi Linus,
please pull one patch for the parisc architecture for kernel 3.18 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-3.18-1
This patch
On 10/13/2014 03:41 PM, One Thousand Gnomes wrote:
On Sun, 12 Oct 2014 12:08:37 +0200
Helge Deller del...@gmx.de wrote:
Hi Linus,
please pull one patch for the parisc architecture for kernel 3.18 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-3.18-1
maintainer after this patch went into 3.18.
Some more background information about this patch is in the commit
message.
Thanks,
Helge
Helge Deller (1):
parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux
architectures
maintainer after this patch went into 3.18.
Some more background information about this patch is in the commit
message.
Thanks,
Helge
Helge Deller (1):
parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux
architectures
for machines with serial port on superio chip
Helge Deller (1):
parisc: Fix serial console for machines with serial port on superio chip
drivers/parisc/superio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
for machines with serial port on superio chip
Helge Deller (1):
parisc: Fix serial console for machines with serial port on superio chip
drivers/parisc/superio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
Hi Peter,
> > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> > serial8250: ttyS0 at I/O 0x3f8 (irq = 3, base_baud = 115200) is a 16550A
> >
> > The source code for this driver is in drivers/parisc/superio.c,
> > see e.g. function superio_serial_init().
> > Maybe something is missing
Hi Peter,
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 3, base_baud = 115200) is a 16550A
The source code for this driver is in drivers/parisc/superio.c,
see e.g. function superio_serial_init().
Maybe something is missing in here which
On 09/24/2014 07:17 PM, Will Deacon wrote:
This patch adds dummy macros for the write accessors to parisc, in the
same vein as the dummy definitions for the relaxed read accessors.
Cc: Helge Deller
Signed-off-by: Will Deacon
---
arch/parisc/include/asm/io.h | 12
1 file
On 09/24/2014 07:17 PM, Will Deacon wrote:
This patch adds dummy macros for the write accessors to parisc, in the
same vein as the dummy definitions for the relaxed read accessors.
Cc: Helge Deller del...@gmx.de
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/parisc/include/asm/io.h
Hi Peter,
On 09/23/2014 11:08 PM, Peter Hurley wrote:
On 09/23/2014 04:11 PM, Helge Deller wrote:
During the release cycle of v3.17 I've seen sometimes a broken serial console
output
on the parisc platform. Interestingly all kernel messages printed by the kernel
via printk() show
up
Hi Peter,
On 09/23/2014 11:08 PM, Peter Hurley wrote:
On 09/23/2014 04:11 PM, Helge Deller wrote:
During the release cycle of v3.17 I've seen sometimes a broken serial console
output
on the parisc platform. Interestingly all kernel messages printed by the kernel
via printk() show
up
Hi Nick,
On 09/22/2014 09:24 PM, nick wrote:
Greetings James and Other Maintainers of the Parisc Architecture,
I am wondering about two fix mes in init.c and how to fix them
for being const declared into actual variables.
...
/* FIXME: This is 'const' in order to trick the compiler
During the release cycle of v3.17 I've seen sometimes a broken serial console
output
on the parisc platform. Interestingly all kernel messages printed by the kernel
via printk() show
up correctly, but output from userspace (e.g. by the init process during boot)
show
up as random bytes.
Since
Helge Deller (2):
parisc: ptrace: use secure_computing_strict()
parisc: pdc_stable.c: Avoid potential stack overflows
John David Anglin (1):
parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds
Rickard Strandqvist (1):
parisc: pdc_stable.c: Cleaning up
Helge Deller (2):
parisc: ptrace: use secure_computing_strict()
parisc: pdc_stable.c: Avoid potential stack overflows
John David Anglin (1):
parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds
Rickard Strandqvist (1):
parisc: pdc_stable.c: Cleaning up
During the release cycle of v3.17 I've seen sometimes a broken serial console
output
on the parisc platform. Interestingly all kernel messages printed by the kernel
via printk() show
up correctly, but output from userspace (e.g. by the init process during boot)
show
up as random bytes.
Since
Hi Nick,
On 09/22/2014 09:24 PM, nick wrote:
Greetings James and Other Maintainers of the Parisc Architecture,
I am wondering about two fix mes in init.c and how to fix them
for being const declared into actual variables.
...
/* FIXME: This is 'const' in order to trick the compiler
Hi Günter,
On 09/20/2014 11:01 PM, Guenter Roeck wrote:
On 09/20/2014 12:36 PM, Helge Deller wrote:
Hi Günter,
On 09/19/2014 09:15 PM, Guenter Roeck wrote:
On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
Changes since 20140917:
The fsl tree still had its build failure so
Hi Günter,
On 09/20/2014 11:01 PM, Guenter Roeck wrote:
On 09/20/2014 12:36 PM, Helge Deller wrote:
Hi Günter,
On 09/19/2014 09:15 PM, Guenter Roeck wrote:
On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
Changes since 20140917:
The fsl tree still had its build failure so
Hi Günter,
On 09/19/2014 09:15 PM, Guenter Roeck wrote:
On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
Changes since 20140917:
The fsl tree still had its build failure so I used the version from
next-20140917.
The v4l-dvb tree lost its build failure.
The security tree
Hi Günter,
On 09/19/2014 09:15 PM, Guenter Roeck wrote:
On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
Changes since 20140917:
The fsl tree still had its build failure so I used the version from
next-20140917.
The v4l-dvb tree lost its build failure.
The security tree
):
parisc: sys_hpux: NUL terminator is one past the end
Guy Martin (1):
parisc: Implement new LWS CAS supporting 64 bit operations.
Hans Wennborg (1):
parisc: dino: fix %d confusingly prefixed with 0x in format string
Helge Deller (1):
parisc: Wire up seccomp, getrandom
):
parisc: sys_hpux: NUL terminator is one past the end
Guy Martin (1):
parisc: Implement new LWS CAS supporting 64 bit operations.
Hans Wennborg (1):
parisc: dino: fix %d confusingly prefixed with 0x in format string
Helge Deller (1):
parisc: Wire up seccomp, getrandom
. Everything seems OK. Please add my Acked-by.
Acked-by: Helge Deller
Thanks!
Helge
---
drivers/parisc/ccio-dma.c | 14 +++---
drivers/parisc/sba_iommu.c | 11 +++
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio
the changes to the
sba_iommu.c driver. Everything seems OK. Please add my Acked-by.
Acked-by: Helge Deller del...@gmx.de
Thanks!
Helge
---
drivers/parisc/ccio-dma.c | 14 +++---
drivers/parisc/sba_iommu.c | 11 +++
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git
Hi Linus,
please pull the latest parisc architecture fixes for kernel 3.16 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-3.16-6
We have two trivial patches in here. One removes the SA_RESTORER #define since
on parisc we don't have the sa_restorer field in
Hi Linus,
please pull the latest parisc architecture fixes for kernel 3.16 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-3.16-6
We have two trivial patches in here. One removes the SA_RESTORER #define since
on parisc we don't have the sa_restorer field in
On 07/18/2014 10:37 PM, Nicholas Krause wrote:
> The comment for size of frame not being needed is incorrect , the
> function called needs this parameter.
Thanks for the patch Nicholas.
It has been queued up:
https://patchwork.kernel.org/patch/4587631/
and
On 07/18/2014 10:37 PM, Nicholas Krause wrote:
The comment for size of frame not being needed is incorrect , the
function called needs this parameter.
Thanks for the patch Nicholas.
It has been queued up:
https://patchwork.kernel.org/patch/4587631/
and
Hi Richard,
nice work!
I pulled your tree and tested your patch series on parisc.
Everything seems OK.
Regarding the changes to the parisc arch, you can add my
Acked-by: Helge Deller
Thanks!
Helge
> Betreff: [PATCH 15/43] parisc: Use get_signal() signal_setup_done()
>
> Use the mor
Hi Richard,
nice work!
I pulled your tree and tested your patch series on parisc.
Everything seems OK.
Regarding the changes to the parisc arch, you can add my
Acked-by: Helge Deller del...@gmx.de
Thanks!
Helge
Betreff: [PATCH 15/43] parisc: Use get_signal() signal_setup_done()
Use
two patches are trivial and remove unused headers, #includes and adds
the serial ports of the fastest C8000 workstation to the parisc-kernel internal
hardware database.
Thanks,
Helge
Helge Deller (3):
parisc: add serial ports
two patches are trivial and remove unused headers, #includes and adds
the serial ports of the fastest C8000 workstation to the parisc-kernel internal
hardware database.
Thanks,
Helge
Helge Deller (3):
parisc: add serial ports
On 07/07/2014 05:28 PM, Heiko Carstens wrote:
> On Mon, Jul 07, 2014 at 03:54:37PM +0200, Helge Deller wrote:
>> Hi Heiko,
>>> So for sys_fanotify_mark everything is fine on s390, and probably most other
>>> architectures as well. Having a 64 bit syscall parameter i
On 07/07/2014 05:28 PM, Heiko Carstens wrote:
On Mon, Jul 07, 2014 at 03:54:37PM +0200, Helge Deller wrote:
Hi Heiko,
So for sys_fanotify_mark everything is fine on s390, and probably most other
architectures as well. Having a 64 bit syscall parameter indeed does work,
if all the architecture
Hi Heiko,
> On Fri, Jul 04, 2014 at 05:12:35PM +0200, Helge Deller wrote:
> > This patch affects big endian architectures only.
> >
> > On those with 32bit userspace and 64bit kernel (CONFIG_COMPAT=y) the
> > 64bit mask parameter is correctly construc
Hi Heiko,
On Fri, Jul 04, 2014 at 05:12:35PM +0200, Helge Deller wrote:
This patch affects big endian architectures only.
On those with 32bit userspace and 64bit kernel (CONFIG_COMPAT=y) the
64bit mask parameter is correctly constructed out of two 32bit values
Hi Heinrich,
On 07/04/2014 06:48 PM, Heinrich Schuchardt wrote:
> On 04.07.2014 17:12, Helge Deller wrote:
>> This patch affects big endian architectures only.
>>
>> On those with 32bit userspace and 64bit kernel (CONFIG_COMPAT=y) the
>> 64bit mask parameter is corre
_u32, mask1, int, dfd,
const char __user *, pathname)
#endif
Signed-off-by: Helge Deller
To: Eric Paris
Cc: Heinrich Schuchardt
Cc: Heiko Carstens
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 3fdc8a3..374261c 10
, mask1, int, dfd,
const char __user *, pathname)
#endif
Signed-off-by: Helge Deller del...@gmx.de
To: Eric Paris epa...@redhat.com
Cc: Heinrich Schuchardt xypron.g...@gmx.de
Cc: Heiko Carstens heiko.carst...@de.ibm.com
diff --git a/fs/notify/fanotify/fanotify_user.c
Hi Heinrich,
On 07/04/2014 06:48 PM, Heinrich Schuchardt wrote:
On 04.07.2014 17:12, Helge Deller wrote:
This patch affects big endian architectures only.
On those with 32bit userspace and 64bit kernel (CONFIG_COMPAT=y) the
64bit mask parameter is correctly constructed out of two 32bit
can pull from to keep this order
> intact.
Sadly the arch-related tracing code in parisc is really broken.
It doesn't even compile cleanly on parisc (at least on 64bit), and as I wrote
you in another mail
I really need to fix this soon (which I already started on).
But your patches look
compile cleanly on parisc (at least on 64bit), and as I wrote
you in another mail
I really need to fix this soon (which I already started on).
But your patches look clean, so to get the basics right, I'm happy to give a
Acked-by: Helge Deller del...@gmx.de
for the two patches which affect parisc
On 05/23/2014 11:12 AM, Miklos Szeredi wrote:
> On Fri, May 23, 2014 at 3:27 AM, Linus Torvalds
> wrote:
>> On Thu, May 22, 2014 at 6:07 PM, Guenter Roeck wrote:
>>> On 05/22/2014 05:43 PM, Linus Torvalds wrote:
only s390 seems to need a compat wrapper, and s390 is kind of odd in
501 - 600 of 795 matches
Mail list logo
