LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: kernel version 2.6.35-git10 build failure
From: Piotr Hosowicz @ 2010-08-11  8:59 UTC (permalink / raw)
  To: Sripathi Kodi; +Cc: linuxppc-dev, Stephen Rothwell, LKML, divya
In-Reply-To: <20100811132313.3d6c7f27@sripathi.in.ibm.com>

On 11.08.2010 09:53, Sripathi Kodi wrote:
> On Wed, 11 Aug 2010 12:51:35 +0530
> divya<dipraksh@linux.vnet.ibm.com>  wrote:
>
>> Hi,
>>
>> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p
>>
>>     fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
>>     fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'
>>     make[2]: *** [fs/9p/vfs_inode.o] Error 1
>>     make[2]: *** Waiting for unfinished jobs....
>>     make[1]: *** [fs/9p] Error 2
>>     make[1]: *** Waiting for unfinished jobs....
>>     make: *** [fs] Error 2
>>     make: *** Waiting for unfinished jobs....
>>
>> Seems like the commit 87d7845aa0b is the corrupt which added the function v9fs_vfs_setattr_dotl()
>
> Yes, it is a problem I created. Stephen Rothwell has already fixed it.
> Al Viro has sent a git pull request to Linus today with the fix in it.
> Here is the patch you need: http://lkml.org/lkml/2010/6/21/442

I fail to apply the patch.

aapi205:/usr/src/linux# patch -p1 < ../9p-patch.txt
patching file fs/9p/vfs_inode.c
Hunk #1 FAILED at 1052.
1 out of 1 hunk FAILED -- saving rejects to file fs/9p/vfs_inode.c.rej

aapi205:/usr/src/linux# cat fs/9p/vfs_inode.c.rej
--- fs/9p/vfs_inode.c
+++ fs/9p/vfs_inode.c
@@ -1052,10 +1052,19 @@
                 return PTR_ERR(fid);

         retval = p9_client_setattr(fid, &p9attr);
-       if (retval >= 0)
-               retval = inode_setattr(dentry->d_inode, iattr);
+       if (retval < 0)
+               return retval;

-       return retval;
+       if ((iattr->ia_valid & ATTR_SIZE) &&
+           iattr->ia_size != i_size_read(dentry->d_inode)) {
+               retval = vmtruncate(dentry->d_inode, iattr->ia_size);
+               if (retval)
+                       return retval;
+       }
+
+       setattr_copy(dentry->d_inode, iattr);
+       mark_inode_dirty(dentry->d_inode);
+       return 0;
  }

  /**

I must be doing something wrong way.

Regards,

Piotr Hosowicz

-- 
Z cyklu "Uroki demokracji", czyli pytania i odpowiedzi w teledurniejach:
- Jaką walutę mają Indie?
- Ramadan.
NP: Patrick O'Hearn - Approaching Summit
NB: 2.6.35-git9

^ permalink raw reply

* Re: [PATCH] powerpc: Feature nop out reservation clear when stcx checks address
From: Benjamin Herrenschmidt @ 2010-08-11  8:21 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <20100811064152.GC15252@drongo>

On Wed, 2010-08-11 at 16:41 +1000, Paul Mackerras wrote:
> On Wed, Aug 11, 2010 at 03:20:05PM +1000, Anton Blanchard wrote:
> 
> > All recent POWER CPUs check the address before letting the stcx succeed
> > so we can create a CPU feature and nop it out. As Ben suggested, we can
> > only do this in our syscall path because there is a remote possibility
> > some kernel code gets interrupted by an exception that ends up operating
> > on the same cacheline.
> 
> Nice...  Just one nit, and that is that I think we now need a dummy
> stcx in the context switch code so there is no possibility of getting
> from one user context to another with a reservation still pending from
> the first context.  I guess our chances of getting through schedule()
> without doing any atomics, bitops or spinlocks are pretty remote, but
> nevertheless it might be as well to make sure.

Do we care ? IE. If we define that the moment you have done a syscall,
the reservation state is undefined, we are clear here, don't you think ?

Cheers,
Ben.

^ permalink raw reply

* Re: kernel version 2.6.35-git10 build failure
From: Sripathi Kodi @ 2010-08-11  7:53 UTC (permalink / raw)
  To: divya; +Cc: linuxppc-dev, LKML, Stephen Rothwell
In-Reply-To: <4C624F7F.3070608@linux.vnet.ibm.com>

On Wed, 11 Aug 2010 12:51:35 +0530
divya <dipraksh@linux.vnet.ibm.com> wrote:

> Hi,
> 
> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p
> 
>    fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
>    fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'
>    make[2]: *** [fs/9p/vfs_inode.o] Error 1
>    make[2]: *** Waiting for unfinished jobs....
>    make[1]: *** [fs/9p] Error 2
>    make[1]: *** Waiting for unfinished jobs....
>    make: *** [fs] Error 2
>    make: *** Waiting for unfinished jobs....
> 
> Seems like the commit 87d7845aa0b is the corrupt which added the function v9fs_vfs_setattr_dotl()

Yes, it is a problem I created. Stephen Rothwell has already fixed it.
Al Viro has sent a git pull request to Linus today with the fix in it.
Here is the patch you need: http://lkml.org/lkml/2010/6/21/442

Thanks,
Sripathi.

> 
> Thanks
> Divya
> 
> 

^ permalink raw reply

* Re: kernel version 2.6.35-git10 build failure
From: Stephen Rothwell @ 2010-08-11  7:51 UTC (permalink / raw)
  To: divya; +Cc: linuxppc-dev, sripathik, LKML
In-Reply-To: <4C624F7F.3070608@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Hi Divya,

On Wed, 11 Aug 2010 12:51:35 +0530 divya <dipraksh@linux.vnet.ibm.com> wrote:
>
> Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p
> 
>    fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
>    fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'

This is known about and a fix is pending.  Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* kernel version 2.6.35-git10 build failure
From: divya @ 2010-08-11  7:21 UTC (permalink / raw)
  To: LKML, linuxppc-dev, sripathik

Hi,

Today kernel(version 2.6.35-git10 -commitid 3d30701b58970) build fails with following error on both system x and p

   fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
   fs/9p/vfs_inode.c:1267: error: implicit declaration of function 'inode_setattr'
   make[2]: *** [fs/9p/vfs_inode.o] Error 1
   make[2]: *** Waiting for unfinished jobs....
   make[1]: *** [fs/9p] Error 2
   make[1]: *** Waiting for unfinished jobs....
   make: *** [fs] Error 2
   make: *** Waiting for unfinished jobs....

Seems like the commit 87d7845aa0b is the corrupt which added the function v9fs_vfs_setattr_dotl()

Thanks
Divya

^ permalink raw reply

* Re: kernel 2.6.33 fail to mount rootfs on ramdisk
From: Shawn Jin @ 2010-08-11  7:16 UTC (permalink / raw)
  To: ppcdev
In-Reply-To: <AANLkTi=ZSBNUYgwv3CKA1PEZm7Vkk6SsubcFR8410qz+@mail.gmail.com>

On Tue, Aug 10, 2010 at 11:55 PM, Shawn Jin <shawnxjin@gmail.com> wrote:
> Hi,
>
> The kernel 2.6.33 failed to mount the rootfs on the ramdisk. I enabled
> the ramdisk block device support and ext2 filesystem as shown below.
>
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_EXT2_FS=y
>
> Are these adequate configurations for kernel to support rootfs on
> ramdisk? What have I missed? The ramdisk image is from DENX's SELF.
> The boot message is shown below.

I figured that out. What I missed is CONFIG_BLK_DEV_INITRD.

Thanks,
-Shawn.

^ permalink raw reply

* kernel 2.6.33 fail to mount rootfs on ramdisk
From: Shawn Jin @ 2010-08-11  6:55 UTC (permalink / raw)
  To: ppcdev

Hi,

The kernel 2.6.33 failed to mount the rootfs on the ramdisk. I enabled
the ramdisk block device support and ext2 filesystem as shown below.

CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_EXT2_FS=y

Are these adequate configurations for kernel to support rootfs on
ramdisk? What have I missed? The ramdisk image is from DENX's SELF.
The boot message is shown below.

=> bootm 1000000 2000000
## Booting image at 01000000 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1070272 Bytes =  1 MB
   Load Address: 00400000
   Entry Point:  00400554
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
   Image Name:   Simple Embedded Linux Framework
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    1459535 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 07bb7000, end 07d1b54f ... OK
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x7270e0 (8MHz)
CPU bus-frequency <- 0x3938700 (60MHz)

zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0)
Allocating 0x23f554 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x0067d01c)...done 0x22e6ec bytes
Using loader supplied ramdisk at 0x7bb7000-0x7d1b54f
initrd head: 0x1f8b0808

Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0x68a300
.......
NET: Registered protocol family 17
List of all partitions:
No filesystem could mount root, tried:  ext2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Call Trace:
[c781fed0] [c0006ce0] show_stack+0x40/0x168 (unreliable)
[c781ff10] [c001cc5c] panic+0x8c/0x178
[c781ff60] [c0201dc0] mount_block_root+0x1d4/0x244
[c781ffb0] [c0201fa4] prepare_namespace+0x64/0x210
[c781ffd0] [c0201220] kernel_init+0x104/0x130
[c781fff0] [c000dcc8] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..

Thanks,
-Shawn.

^ permalink raw reply

* Re: [PATCH] powerpc: Feature nop out reservation clear when stcx checks address
From: Paul Mackerras @ 2010-08-11  6:41 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100811052005.GV29316@kryten>

On Wed, Aug 11, 2010 at 03:20:05PM +1000, Anton Blanchard wrote:

> All recent POWER CPUs check the address before letting the stcx succeed
> so we can create a CPU feature and nop it out. As Ben suggested, we can
> only do this in our syscall path because there is a remote possibility
> some kernel code gets interrupted by an exception that ends up operating
> on the same cacheline.

Nice...  Just one nit, and that is that I think we now need a dummy
stcx in the context switch code so there is no possibility of getting
from one user context to another with a reservation still pending from
the first context.  I guess our chances of getting through schedule()
without doing any atomics, bitops or spinlocks are pretty remote, but
nevertheless it might be as well to make sure.

Paul.

^ permalink raw reply

* [PATCH] powerpc, perf_event: Reduce latency of calling perf_event_do_pending
From: Paul Mackerras @ 2010-08-11  6:38 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Peter Zijlstra, Ingo Molnar, Milton Miller

Commit 0fe1ac48 ("powerpc/perf_event: Fix oops due to
perf_event_do_pending call") moved the call to perf_event_do_pending
in timer_interrupt() down so that it was after the irq_enter() call.
Unfortunately this moved it after the code that checks whether it
is time for the next decrementer clock event.  The result is that
the call to perf_event_do_pending() won't happen until the next
decrementer clock event is due.  This was pointed out by Milton
Miller.

This fixes it by moving the check for whether it's time for the
next decrementer clock event down to the point where we're about
to call the event handler, after we've called perf_event_do_pending.

This has the side effect that on old pre-Core99 Powermacs where we
use the ppc_n_lost_interrupts mechanism to replay interrupts, a
replayed interrupt will incur a little more latency since it will
now do the code from the irq_enter down to the irq_exit, that it
used to skip.  However, these machines are now old and rare enough
that this doesn't matter.  To make it clear that ppc_n_lost_interrupts
is only used on Powermacs, and to speed up the code slightly on
non-Powermac ppc32 machines, the code that tests ppc_n_lost_interrupts
is now conditional on CONFIG_PMAC as well as CONFIG_PPC32.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Cc: stable@kernel.org
---
Ingo, Peter: this is for information & comment, I'll ask Ben to send
this to Linus through his tree.

 arch/powerpc/kernel/time.c |   23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index ce53dfa..8533b3b 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -577,20 +577,11 @@ void timer_interrupt(struct pt_regs * regs)
 	 * some CPUs will continuue to take decrementer exceptions */
 	set_dec(DECREMENTER_MAX);
 
-#ifdef CONFIG_PPC32
+#if defined(CONFIG_PPC32) && defined(CONFIG_PMAC)
 	if (atomic_read(&ppc_n_lost_interrupts) != 0)
 		do_IRQ(regs);
 #endif
 
-	now = get_tb_or_rtc();
-	if (now < decrementer->next_tb) {
-		/* not time for this event yet */
-		now = decrementer->next_tb - now;
-		if (now <= DECREMENTER_MAX)
-			set_dec((int)now);
-		trace_timer_interrupt_exit(regs);
-		return;
-	}
 	old_regs = set_irq_regs(regs);
 	irq_enter();
 
@@ -606,8 +597,16 @@ void timer_interrupt(struct pt_regs * regs)
 		get_lppaca()->int_dword.fields.decr_int = 0;
 #endif
 
-	if (evt->event_handler)
-		evt->event_handler(evt);
+	now = get_tb_or_rtc();
+	if (now >= decrementer->next_tb) {
+		decrementer->next_tb = ~(u64)0;
+		if (evt->event_handler)
+			evt->event_handler(evt);
+	} else {
+		now = decrementer->next_tb - now;
+		if (now <= DECREMENTER_MAX)
+			set_dec((int)now);
+	}
 
 #ifdef CONFIG_PPC_ISERIES
 	if (firmware_has_feature(FW_FEATURE_ISERIES) && hvlpevent_is_pending())

^ permalink raw reply related

* DMA transfer within kernel space
From: Ravi Gupta @ 2010-08-11  6:09 UTC (permalink / raw)
  To: linuxppc-dev, linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Hi,

I am new to linux device driver development and I'm trying to learn the
DMA transfer. Currently I have created a  DMA buffer using
pci_alloc_consistent() function. Since I don't have a real DMA enabled pci
device, so I am thinking of transfer the data in the DMA buffer to some
other buffer within kernel space(let say created through kmalloc) using
DMA.

Is it possible to do DMA transfer within kernel space? If yes, please
provide some sample code for the same.

Thanks in advance
Ravi Gupta

[-- Attachment #2: Type: text/html, Size: 541 bytes --]

^ permalink raw reply

* [PATCH] powerpc: move arch_sd_sibling_asym_packing() to smp.c
From: Michael Neuling @ 2010-08-11  6:02 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev

Simple cleanup by moving arch_sd_sibling_asym_packing from process.c to
smp.c to save an #ifdef CONFIG_SMP

No functionality change.  

Signed-off-by: Michael Neuling <mikey@neuling.org>
---
 arch/powerpc/kernel/process.c |   11 -----------
 arch/powerpc/kernel/smp.c     |    9 +++++++++
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e78a5ad..551f671 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1299,14 +1299,3 @@ unsigned long randomize_et_dyn(unsigned long base)
 
 	return ret;
 }
-
-#ifdef CONFIG_SMP
-int arch_sd_sibling_asym_packing(void)
-{
-	if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
-		printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
-		return SD_ASYM_PACKING;
-	}
-	return 0;
-}
-#endif
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index a61b3dd..41be244 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -580,6 +580,15 @@ void __init smp_cpus_done(unsigned int max_cpus)
 	dump_numa_cpu_topology();
 }
 
+int arch_sd_sibling_asym_packing(void)
+{
+	if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
+		printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
+		return SD_ASYM_PACKING;
+	}
+	return 0;
+}
+
 #ifdef CONFIG_HOTPLUG_CPU
 int __cpu_disable(void)
 {

^ permalink raw reply related

* [PATCH] powerpc: Feature nop out reservation clear when stcx checks address
From: Anton Blanchard @ 2010-08-11  5:20 UTC (permalink / raw)
  To: paulus, benh; +Cc: linuxppc-dev


The POWER architecture does not require stcx to check that it is operating
on the same address as the larx. This means it is possible for an
an exception handler to execute a larx, get a reservation, decide
not to do the stcx and then return back with an active reservation. If the
interrupted code was in the middle of a larx/stcx sequence the stcx could
incorrectly succeed.

All recent POWER CPUs check the address before letting the stcx succeed
so we can create a CPU feature and nop it out. As Ben suggested, we can
only do this in our syscall path because there is a remote possibility
some kernel code gets interrupted by an exception that ends up operating
on the same cacheline.

Thanks to Paul Mackerras and Derek Williams for the idea.

To test this I used a very simple null syscall (actually getppid) testcase
at http://ozlabs.org/~anton/junkcode/null_syscall.c

I tested against 2.6.35-git10 with the following changes against the
pseries_defconfig:

CONFIG_VIRT_CPU_ACCOUNTING=n
CONFIG_AUDIT=n
CONFIG_PPC_4K_PAGES=n
CONFIG_PPC_64K_PAGES=y
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_PPC_SUBPAGE_PROT=n
CONFIG_FUNCTION_TRACER=n
CONFIG_FUNCTION_GRAPH_TRACER=n
CONFIG_IRQSOFF_TRACER=n
CONFIG_STACK_TRACER=n

to remove the overhead of virtual CPU accounting, syscall auditing and
the ftrace mcount tracers. 64kB pages were enabled to minimise TLB misses.

POWER6: +8.2%
POWER7: +7.0%

Signed-off-by: Anton Blanchard <anton@samba.org>
---

Index: powerpc.git/arch/powerpc/include/asm/cputable.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/cputable.h	2010-08-11 12:56:03.340741765 +1000
+++ powerpc.git/arch/powerpc/include/asm/cputable.h	2010-08-11 13:02:30.131470190 +1000
@@ -198,6 +198,7 @@ extern const char *powerpc_base_platform
 #define CPU_FTR_CP_USE_DCBTZ		LONG_ASM_CONST(0x0040000000000000)
 #define CPU_FTR_UNALIGNED_LD_STD	LONG_ASM_CONST(0x0080000000000000)
 #define CPU_FTR_ASYM_SMT		LONG_ASM_CONST(0x0100000000000000)
+#define CPU_FTR_STCX_CHECKS_ADDRESS	LONG_ASM_CONST(0x0200000000000000)
 
 #ifndef __ASSEMBLY__
 
@@ -392,28 +393,31 @@ extern const char *powerpc_base_platform
 	    CPU_FTR_MMCRA | CPU_FTR_CTRL)
 #define CPU_FTRS_POWER4	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
-	    CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ)
+	    CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ | \
+	    CPU_FTR_STCX_CHECKS_ADDRESS)
 #define CPU_FTRS_PPC970	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
-	    CPU_FTR_CP_USE_DCBTZ)
+	    CPU_FTR_CP_USE_DCBTZ | CPU_FTR_STCX_CHECKS_ADDRESS)
 #define CPU_FTRS_POWER5	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
 	    CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
-	    CPU_FTR_PURR)
+	    CPU_FTR_PURR | CPU_FTR_STCX_CHECKS_ADDRESS)
 #define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
 	    CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
 	    CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
-	    CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD)
+	    CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
+	    CPU_FTR_STCX_CHECKS_ADDRESS)
 #define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
 	    CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
 	    CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
-	    CPU_FTR_DSCR | CPU_FTR_SAO  | CPU_FTR_ASYM_SMT)
+	    CPU_FTR_DSCR | CPU_FTR_SAO  | CPU_FTR_ASYM_SMT | \
+	    CPU_FTR_STCX_CHECKS_ADDRESS)
 #define CPU_FTRS_CELL	(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
 	    CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
Index: powerpc.git/arch/powerpc/kernel/entry_64.S
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/entry_64.S	2010-08-11 12:56:03.360742333 +1000
+++ powerpc.git/arch/powerpc/kernel/entry_64.S	2010-08-11 13:00:08.862283406 +1000
@@ -202,7 +202,9 @@ syscall_exit:
 	bge-	syscall_error
 syscall_error_cont:
 	ld	r7,_NIP(r1)
+BEGIN_FTR_SECTION
 	stdcx.	r0,0,r1			/* to clear the reservation */
+END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
 	andi.	r6,r8,MSR_PR
 	ld	r4,_LINK(r1)
 	/*

^ permalink raw reply

* RE: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
From: Zang Roy-R61911 @ 2010-08-11  4:47 UTC (permalink / raw)
  To: Zang Roy-R61911, akpm, linux-mmc; +Cc: linuxppc-dev, mirqus
In-Reply-To: <1281433632-18758-1-git-send-email-tie-fei.zang@freescale.com>

=20

> -----Original Message-----
> From: Zang Roy-R61911=20
> Sent: Tuesday, August 10, 2010 17:47 PM
> To: akpm@linux-foundation.org; linux-mmc@vger.kernel.org
> Cc: linuxppc-dev@ozlabs.org; mirqus@gmail.com;=20
> cbouatmailru@gmail.com; grant.likely@secretlab.ca
> Subject: [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
>=20
> Change ACMD12 to AUTO_CMD12 to reduce the confusion.
> ACMD12 might be confused with MMC/SD App CMD 12 (CMD55+CMD12 combo).
>=20
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
>  drivers/mmc/host/sdhci-of-core.c |    2 +-
>  drivers/mmc/host/sdhci.c         |    8 ++++----
>  drivers/mmc/host/sdhci.h         |   10 +++++-----
>  3 files changed, 10 insertions(+), 10 deletions(-)
Andrew,=20
Could you help to pick up this minor fix?
Thanks.
Roy

^ permalink raw reply

* RE: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-08-11  2:45 UTC (permalink / raw)
  To: Zang Roy-R61911, linux-mtd
  Cc: Lan Chunhe-B25806, linuxppc-dev, akpm, Gala Kumar-B11780,
	Wood Scott-B07421
In-Reply-To: <1281063096-26598-1-git-send-email-tie-fei.zang@freescale.com>

=20

> -----Original Message-----
> From: Zang Roy-R61911=20
> Sent: Friday, August 06, 2010 10:52 AM
> To: linux-mtd@lists.infradead.org
> Cc: linuxppc-dev@ozlabs.org; akpm@linux-foundation.org; Gala=20
> Kumar-B11780; Lan Chunhe-B25806
> Subject: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc=20
> interrupt common to elbc devices
>=20
> From: Lan Chunhe-B25806 <b25806@freescale.com>
>=20
> Move Freescale elbc interrupt from nand dirver to elbc driver.
> Then all elbc devices can use the interrupt instead of ONLY nand.
>=20
> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> send the patch to linux-mtd@lists.infradead.org
> it has been posted to linuxppc-dev@ozlabs.org and do not get=20
> any comment.
>=20
>  arch/powerpc/Kconfig               |    7 +-
>  arch/powerpc/include/asm/fsl_lbc.h |   34 +++++-
>  arch/powerpc/sysdev/fsl_lbc.c      |  254=20
> ++++++++++++++++++++++++++++++------
>  3 files changed, 253 insertions(+), 42 deletions(-)
Who is response to review the nand driver in mtd list?
Please help to  comment on this serial patch.
Thanks.
Roy

^ permalink raw reply

* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-08-10 22:36 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
	Will Schmidt, Paul Mackerras
In-Reply-To: <alpine.LFD.2.00.1007222028420.2616@localhost.localdomain>

On 07/22/2010 11:38 AM, Thomas Gleixner wrote:
> On Thu, 22 Jul 2010, Darren Hart wrote:
>
>> Also of interest is that this path
>> cpu_idle()->cpu_die()->pseries_mach_cpu_die() to start_secondary()
>> enters with a preempt_count=1 if it wasn't corrupted across the hcall.
>
> That triggers the problem as well. preempt_count needs to be 0 when
> entering start_secondary(). So I really wonder how that ever worked.
>
>> The early boot path from _start however appears to call
>> start_secondary() with a preempt_count of 0.
>
> Which is correct.
>
>> The following patch is most certainly not correct, but it does eliminate
>
> It is correct, but i think it is incomplete as other portions of the
> thread_info on the stack might be in some weird state as well.

Just FYI, I took a look at the stack pointers as well as all the fields 
in the thread_info struct. The only one that changes is preempt_count. 
The previous value of preempt_count doesn't impact the value after cede. 
An initial value of 0, 1, or 4 all result in an after-cede value of 
0xffffffff. I also added 32 bits of padding on either side of the 
preempt_count in case the change was accidental - it wasnt', the padded 
values remained unchanged across the cede call while the preempt_count 
still changed to 0xffffffff.


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

^ permalink raw reply

* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Guenter Roeck @ 2010-08-10 16:43 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mark Brown, David Woodhouse, James Smart, Greg KH,
	linuxppc-dev@ozlabs.org, James E.J. Bottomley, Paul Mackerras,
	Nick Cheng, linux-scsi@vger.kernel.org, Eric Biederman,
	Alex Iannicelli, Benjamin Thery, Chris Wright, Tejun Heo,
	Liam Girdwood, Linus Walleij, Dmitry Torokhov, Greg Kroah-Hartman,
	linux-kernel@vger.kernel.org, Richard Purdie, Jani Nikula,
	Jean Delvare
In-Reply-To: <20100811012001.6fb50655.sfr@canb.auug.org.au>

On Tue, 2010-08-10 at 11:20 -0400, Stephen Rothwell wrote:
> Hi Jean,
> 
> On Wed, 11 Aug 2010 01:17:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Tue, 10 Aug 2010 15:43:37 +0200 Jean Delvare <khali@linux-fr.org> wrote:
> > >
> > > Related bug?
> > > 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=16544
> > 
> > Yep, fixed in linux-next today - hopefully the fix is on its way to Linus.
> 
> Sorry, more info:
> 
> Fixed by commit 690e85a3957291f4cfe0cac22d97994ec7e5ee45 ("olpc_battery:
> Fix build failure caused by sysfs changes") from the battery tree.

Excellent. Guess the patch I sent out earlier today to fix the problem
wasn't needed then.

Guenter

^ permalink raw reply

* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Stephen Rothwell @ 2010-08-10 15:20 UTC (permalink / raw)
  To: Jean Delvare
  Cc: Mark Brown, David Woodhouse, James Smart, Greg KH, linuxppc-dev,
	James E.J. Bottomley, Paul Mackerras, Guenter Roeck, Nick Cheng,
	linux-scsi, Eric Biederman, Alex Iannicelli, Benjamin Thery,
	Chris Wright, Liam Girdwood, Linus Walleij, Dmitry Torokhov,
	Greg Kroah-Hartman, linux-kernel, Richard Purdie, Jani Nikula,
	Tejun Heo
In-Reply-To: <20100811011733.16243ddb.sfr@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

Hi Jean,

On Wed, 11 Aug 2010 01:17:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 10 Aug 2010 15:43:37 +0200 Jean Delvare <khali@linux-fr.org> wrote:
> >
> > Related bug?
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=16544
> 
> Yep, fixed in linux-next today - hopefully the fix is on its way to Linus.

Sorry, more info:

Fixed by commit 690e85a3957291f4cfe0cac22d97994ec7e5ee45 ("olpc_battery:
Fix build failure caused by sysfs changes") from the battery tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Stephen Rothwell @ 2010-08-10 15:17 UTC (permalink / raw)
  To: Jean Delvare
  Cc: Guenter Roeck, Greg Kroah-Hartman, Dmitry Torokhov, Linus Walleij,
	James Smart, Eric Biederman, Greg KH, Mark Brown, linux-kernel,
	Chris Wright, linuxppc-dev, James E.J. Bottomley, Richard Purdie,
	Nick Cheng, Jani Nikula, Tejun Heo, Paul Mackerras, Liam Girdwood,
	linux-scsi, Alex Iannicelli, Benjamin Thery
In-Reply-To: <20100810154337.006a0df9@hyperion.delvare>

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

Hi Jean,

On Tue, 10 Aug 2010 15:43:37 +0200 Jean Delvare <khali@linux-fr.org> wrote:
>
> Related bug?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=16544

Yep, fixed in linux-next today - hopefully the fix is on its way to Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Jean Delvare @ 2010-08-10 13:43 UTC (permalink / raw)
  To: Greg KH
  Cc: Mark Brown, Jani Nikula, Linus Walleij, James Smart,
	Eric Biederman, Benjamin Thery, Greg Kroah-Hartman, linux-kernel,
	Chris Wright, linuxppc-dev, James E.J. Bottomley, Richard Purdie,
	Nick Cheng, Dmitry Torokhov, Tejun Heo, Paul Mackerras,
	Liam Girdwood, linux-scsi, Alex Iannicelli, Guenter Roeck
In-Reply-To: <20100802233128.GA21286@kroah.com>

On Mon, 2 Aug 2010 16:31:28 -0700, Greg KH wrote:
> On Wed, Jul 28, 2010 at 11:16:35PM -0700, Eric Biederman wrote:
> > On Wed, Jul 28, 2010 at 10:09 PM, Guenter Roeck
> > <guenter.roeck@ericsson.com> wrote:
> > > The following comment is found in include/linux/sysfs.h:
> > >
> > > =C2=A0 /* FIXME
> > > =C2=A0 =C2=A0* The *owner field is no longer used.
> > > =C2=A0 =C2=A0* x86 tree has been cleaned up. The owner
> > > =C2=A0 =C2=A0* attribute is still left for other arches.
> > > =C2=A0 =C2=A0*/
> > >
> > > As it turns out, the *owner field is (again?) initialized in several =
modules,
> > > suggesting that such initialization may be creeping back into the cod=
e.
> > >
> > > This patch set removes the above comment, the *owner field, and each =
instance
> > > in the code where it was found to be initialized.
> > >
> > > Compiled with x86 allmodconfig as well as with all alpha, arm, mips, =
powerpc,
> > > and sparc defconfig builds.
> >=20
> > This seems reasonable to me.  Can we get this in linux-next?
>=20
> It will show up in linux-next tomorrow.

Related bug?

https://bugzilla.kernel.org/show_bug.cgi?id=3D16544

--=20
Jean Delvare

^ permalink raw reply

* Re: [spi-devel-general] [PATCH v2 4/6] mtd: m25p80: add a read function to read page by page
From: David Brownell @ 2010-08-10 13:44 UTC (permalink / raw)
  To: Mingkai Hu, David Woodhouse, Grant Likely
  Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <AANLkTikM5je7Ckt=7bP6fj7OKCaroSn_AqgcS4T+Bv5d@mail.gmail.com>

=0A=0A--- On Tue, 8/10/10, Grant Likely <grant.likely@secretlab.ca> wrote:=
=0A=0A> This one bothers me, but I can't put my=0A> finger on it.=A0The fla=
g feels=0A> like a controller specific hack.=0A=0AThat's because it *IS* ..=
.=0A=0ANot clear what a good fix would look like.=0ABut in general, SPI mas=
ter controllers are=0Aresponsible for returning all bytes requested,=0Ainst=
ead of (as with this one) a subset.=0A=0ASuggesting the real issue is a bug=
gy SPI=0Amaster controller and/or driver.  Can't it=0Aissue multiple reads =
to collect all the data=0Arequested?? =0A=0A- Dave=0A=0A=0A

^ permalink raw reply

* Accessing GPIO registers on MPC8377ERDB board
From: Ravi Gupta @ 2010-08-10 12:59 UTC (permalink / raw)
  To: linuxppc-dev, linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

Hi,

I want to access the GPIO registers present in MPC8377ERDB board. I have to
write a GPIO driver for that, I am completely confused that how to do it.
Please suggest some way or doc to start with.

For the start-up, I was thinking of setting GPIO pins 9, 10 and 11 present
on the board to active low as they are connected to leds D3, D4 and D5 resp.


Thanks in advance
Ravi Gupta

[-- Attachment #2: Type: text/html, Size: 414 bytes --]

^ permalink raw reply

* Re: [PATCH 8/8] v5  Update memory-hotplug documentation
From: Nathan Fontenot @ 2010-08-10 12:17 UTC (permalink / raw)
  To: Nishanth Aravamudan
  Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
	linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <201008091344.37878.nacc@us.ibm.com>

On 08/09/2010 03:44 PM, Nishanth Aravamudan wrote:
> On Monday, August 09, 2010 11:43:46 am Nathan Fontenot wrote:
>> Update the memory hotplug documentation to reflect the new behaviors of
>> memory blocks reflected in sysfs.
> 
> <snip>
> 
>> Index: linux-2.6/Documentation/memory-hotplug.txt
>> ===================================================================
>> --- linux-2.6.orig/Documentation/memory-hotplug.txt	2010-08-09 07:36:48.000000000 -0500
>> +++ linux-2.6/Documentation/memory-hotplug.txt	2010-08-09 07:59:54.000000000 -0500
> 
> <snip>
> 
>> -/sys/devices/system/memory/memoryXXX/phys_index
>> +/sys/devices/system/memory/memoryXXX/start_phys_index
>> +/sys/devices/system/memory/memoryXXX/end_phys_index
>>  /sys/devices/system/memory/memoryXXX/phys_device
>>  /sys/devices/system/memory/memoryXXX/state
>>  /sys/devices/system/memory/memoryXXX/removable
>>
>> -'phys_index' : read-only and contains section id, same as XXX.
> 
> <snip>
> 
>> +'phys_index'      : read-only and contains section id of the first section
> 
> Shouldn't this be "start_phys_index"?

Hmmm... looks like  I missed something in the documentation.

The property should be 'phys_index'.  I thought about changing it to
'start_phys_index' but that was rejected.  The listing of the files
above is wrong in this patch, it should be 

 +/sys/devices/system/memory/memoryXXX/phys_index
 +/sys/devices/system/memory/memoryXXX/end_phys_index

Thanks, 

Nathan

^ permalink raw reply

* RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Zang Roy-R61911 @ 2010-08-10 10:07 UTC (permalink / raw)
  To: Michał Mirosław; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <AANLkTikUypKobPAHsE+tz-Py-XvvJhbcj7Syj3rX_ej0@mail.gmail.com>

=20

> -----Original Message-----
> From: Micha=B3 Miros=B3aw [mailto:mirqus@gmail.com]=20
> Sent: Tuesday, August 10, 2010 2:25 AM
> To: Zang Roy-R61911
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@ozlabs.org;=20
> akpm@linux-foundation.org
> Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for=20
> eSDHC driver
>=20
> 2010/8/3 Roy Zang <tie-fei.zang@freescale.com>:
> [...]
> > @@ -240,6 +240,8 @@ struct sdhci_host {
> > =A0#define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN =A0 =A0 =A0 =A0 =A0 =A0 =
=A0(1<<25)
> > =A0/* Controller cannot support End Attribute in NOP ADMA=20
> descriptor */
> > =A0#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC =A0 =A0 =A0 =A0 =A0 =A0 =
=A0(1<<26)
> > +/* Controller uses Auto CMD12 command to stop the transfer */
> > +#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 =A0 =A0 =A0 =A0 =A0 =A0 =
(1<<27)
> >
> > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq; =A0 =
=A0 =A0 =A0 =A0 =A0/* Device IRQ */
> > =A0 =A0 =A0 =A0void __iomem * =A0 =A0 =A0 =A0 =A0ioaddr; =A0 =A0 =A0 =
=A0 /* Mapped address */
>=20
> Just a cosmetic hint: I suggest SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12
> or something for the quirk name, because ACMD12 part might be confused
> with MMC/SD App CMD 12 (CMD55+CMD12 combo) if/whenever that gets used.
Thanks for the suggestion.
There are several ACMD12 needed to be updated.
Send a new patch to update it.
Roy

^ permalink raw reply

* RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Zang Roy-R61911 @ 2010-08-10 10:04 UTC (permalink / raw)
  To: Anton Vorontsov, Grant Likely; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <20100809174333.GC7665@oksana.dev.rtsoft.ru>

=20

> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]=20
> Sent: Tuesday, August 10, 2010 1:44 AM
> To: Grant Likely
> Cc: Zang Roy-R61911; linuxppc-dev@ozlabs.org;=20
> akpm@linux-foundation.org; linux-mmc@vger.kernel.org
> Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for=20
> eSDHC driver
>=20
> On Wed, Aug 04, 2010 at 07:02:56PM -0600, Grant Likely wrote:
> > On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang=20
> <tie-fei.zang@freescale.com> wrote:
> > > From: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > >
> > > Add auto CMD12 command support for eSDHC driver.
> > > This is needed by P4080 and P1022 for block read/write.
> > > Manual asynchronous CMD12 abort operation causes protocol=20
> violations on
> > > these silicons.
> > >
> > > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > > ---
> > > =A0drivers/mmc/host/sdhci-of-core.c | =A0 =A04 ++++
> > > =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 | =A0 14 =
++++++++++++--
> > > =A0drivers/mmc/host/sdhci.h =A0 =A0 =A0 =A0 | =A0 =A02 ++
> > > =A03 files changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > index c6d1bd8..a92566e 100644
> > > --- a/drivers/mmc/host/sdhci.c
> > > +++ b/drivers/mmc/host/sdhci.c
> > > @@ -817,8 +817,12 @@ static void=20
> sdhci_set_transfer_mode(struct sdhci_host *host,
> > > =A0 =A0 =A0 =A0WARN_ON(!host->data);
> > >
> > > =A0 =A0 =A0 =A0mode =3D SDHCI_TRNS_BLK_CNT_EN;
> > > - =A0 =A0 =A0 if (data->blocks > 1)
> > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MULTI;
> > > + =A0 =A0 =A0 if (data->blocks > 1) {
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks &=20
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI |=20
> SDHCI_TRNS_ACMD12;
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI;
> >=20
> > nit:
> > +               mode |=3D SDHCI_TRNS_MULTI;
> > +               if (host->quirks &=20
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> > +                       mode |=3D SDHCI_TRNS_ACMD12;
> >=20
> > Clearer, no?
>=20
> Much clearer. I would prefer the nit incorporated.
Agree.

>=20
> Another nit:
>=20
> > @@ -154,6 +154,10 @@ static int __devinit=20
> sdhci_of_probe(struct of_device *ofdev,
> >                 host->ops =3D &sdhci_of_data->ops;
> >         }
> >=20
> > +       if (of_get_property(np, "sdhci,auto-cmd12", NULL))
> > +               host->quirks |=3D =
SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
> > +
> > +     =20
>=20
> ^^ No need for the two empty lines.
Agree.
>=20
> >        if (of_get_property(np, "sdhci,1-bit-only", NULL))
>=20
> Though, technically the patch looks OK, feel free to add my
>=20
>   Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
I send a new patch to fix the nip. you are Cced.
Thanks.
Roy

^ permalink raw reply

* [PATCH 2/2] mmc: some nip clean up for the sdhci driver
From: Roy Zang @ 2010-08-10  9:47 UTC (permalink / raw)
  To: akpm, linux-mmc; +Cc: linuxppc-dev, mirqus
In-Reply-To: <1281433632-18758-1-git-send-email-tie-fei.zang@freescale.com>

remove the extra line and rewrite the if condition line.

Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
 drivers/mmc/host/sdhci-of-core.c |    1 -
 drivers/mmc/host/sdhci.c         |    5 ++---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index d059805..732cffd 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -157,7 +157,6 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
 	if (of_get_property(np, "sdhci,auto-cmd12", NULL))
 		host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12;
 
-
 	if (of_get_property(np, "sdhci,1-bit-only", NULL))
 		host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
 
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4b7b2d5..a1e6269 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -818,10 +818,9 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
 
 	mode = SDHCI_TRNS_BLK_CNT_EN;
 	if (data->blocks > 1) {
+		mode |= SDHCI_TRNS_MULTI;
 		if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12)
-			mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_AUTO_CMD12;
-		else
-			mode |= SDHCI_TRNS_MULTI;
+			mode |= SDHCI_TRNS_AUTO_CMD12;
 	}
 	if (data->flags & MMC_DATA_READ)
 		mode |= SDHCI_TRNS_READ;
-- 
1.5.6.5

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox