On 23.6.2010 12:02, Ian Munsie wrote:
From: Jason Baron jba...@redhat.com
make tags.sh recognize the new syscall macros:
COMPAT_SYSCALL_DEFINE#N()
ARCH_COMPAT_SYSCALL_DEFINE#N()
Signed-off-by: Jason Baron jba...@redhat.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Acked-by: Michal
On 23.6.2010 12:37, Andi Kleen wrote:
It also has maintenance costs, e.g. I doubt ctags and cscope
will be able to deal with these kinds of macros, so it has a
high cost for everyone using these tools.
FWIW, patch 16/40 of this series teaches 'make tags' to recognize these
macros:
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = serial;
compatible = ucc_uart;
This patch enables the on-chip DWC SATA controller of the AppliedMicro
processor 460EX.
Signed-off-by: Rupjyoti Sarmah rsar...@appliedmicro.com
Signed-off-by: Mark Miesfeld mmiesf...@appliedmicro.com
Signed-off-by: Prodyut Hazarika phazar...@appliedmicro.com
---
This patch incorporates the
On 06/24/2010 06:54 AM, Gary Thomas wrote:
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = serial;
compatible = ucc_uart;
cell-index
One thing I noticed is that the firmware patch seems quite old.
I got the firmware package from http://opensource.freescale.com/firmware/
We were also told (by FreeScale) to look at
https://www.freescale.com/webapp/Download?colCode=QERAMPKG
Looking at these two packages, it's unclear that
On 06/24/2010 07:38 AM, Chuck Meade wrote:
One thing I noticed is that the firmware patch seems quite old.
I got the firmware package from http://opensource.freescale.com/firmware/
We were also told (by FreeScale) to look at
https://www.freescale.com/webapp/Download?colCode=QERAMPKG
Looking at
On Wed, Jun 23, 2010 at 12:23:44PM -0700, H. Peter Anvin wrote:
arch/s390/kernel/sys_s390.c:SYSCALL_DEFINE(s390_fallocate)(int fd, int
mode, loff_t offset,
arch/sparc/kernel/sys_sparc_64.c:SYSCALL_DEFINE1(sparc_pipe_real, struct
pt_regs *, regs)
In fact we sort of wanted to
You can use strategic printk debugging in the ucc_uart.c driver to
determine
on the Tx side what is going wrong. For example, after you tell the
QE to
output chars, wait a bit and printk out the BD. See if the QE is
clearing the
READY bit in that BD. That will tell you if the QE is even
Fix build warning:
arch/powerpc/kvm/book3s_64_mmu.c: In function
'kvmppc_mmu_book3s_64_esid_to_vsid':
arch/powerpc/kvm/book3s_64_mmu.c:446: warning: 'slb' may be used uninitialized
in this function
Signed-off-by: Denis Kirjanov dkirja...@kernel.org
---
arch/powerpc/kvm/book3s_64_mmu.c |2 +-
On 24.06.2010, at 21:44, Denis Kirjanov wrote:
Fix build warning:
arch/powerpc/kvm/book3s_64_mmu.c: In function
'kvmppc_mmu_book3s_64_esid_to_vsid':
arch/powerpc/kvm/book3s_64_mmu.c:446: warning: 'slb' may be used
uninitialized in this function
Signed-off-by: Denis Kirjanov
Timur Tabi wrote:
I'd say that there are plenty of unknown issues with this driver/hardware.
For some reason, QE UART is just unreliable. I've had several people try to
use the QE for UART, and almost everyone has problems with it.
I finally got in touch with one of the other development
On 06/24/2010 03:20 PM, Timur Tabi wrote:
Timur Tabi wrote:
I'd say that there are plenty of unknown issues with this driver/hardware.
For some reason, QE UART is just unreliable. I've had several people try to
use the QE for UART, and almost everyone has problems with it.
I finally got in
Oops... put the old linuxppc list on the CC, sorry!
On Thu, Jun 24, 2010 at 23:45, Kyle Moffett k...@moffetthome.net wrote:
Hello,
I've got a new P2020 (32bit mpc85xx family) board I'm working on a
port for that includes 2 NOR flashes (128MB each) and a removable
SO-RDIMM of 2GB or 4GB.
Oops, put the old linuxppc list on the CC, sorry!
On Thu, Jun 24, 2010 at 23:32, Kyle Moffett k...@moffetthome.net wrote:
Hello,
I'm working on a new board port for a P2020-based board, and I'm
having problems with my second core not starting up on 2.6.34, even
though it starts up fine on
15 matches
Mail list logo
