[PATCH] powerpc: Fix bogus cache flushing on all 40x and BookE processors

We were missing the CPU_FTR_NOEXECUTE bit in our cputable for all these processors. The result is that update_mmu_cache() would flush the cache for all pages mapped to userspace which is totally unnecessary on those processors since we already handle flushing on execute in the page fault path. Thi

[PATCH] powerpc: Fix dma_map_sg() cache flushing on non coherent platforms

On PowerPC 4xx or other non cache coherent platforms, we lost the appropriate cache flushing in dma_map_sg() when merging the 32 and 64-bit DMA code. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- Oops .. nobody spotted that when Becky patches went in ! Paul: This is a 2.6.28 regr

[git pull] Please pull powerpc.git merge branch again

Linus, Please do another pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge Sorry for a second request so soon after the previous one, but I realized that I had missed one commit that I intended to include, and without it our 32-bit SMP configs

[git pull] Please pull powerpc.git merge branch

Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get a set of fixes for various powerpc regressions, build failures and serious bugs that have accumulated since my last pull request, plus some defconfig updates. This include

Re: [PATCH 1/2] powerpc and sparc: Introduce dev_archdata node accessors

On Fri, 2008-11-28 at 22:13 +0300, Anton Vorontsov wrote: > The name of the device_node field differ across the platforms, so we > have to implement inlined accessors. This is needed to avoid ugly > #ifdef in the generic code. My grep skills may not be 1337 enough, but I only see maybe three uses

Re: [PATCH] powerpc: Fix system calls on Cell entered with XER.SO=1

On Mon, 2008-12-01 at 08:49 +1100, Paul Mackerras wrote: > It turns out that on Cell, on a kernel with CONFIG_VIRT_CPU_ACCOUNTING > = y, if a program sets the SO (summary overflow) bit in the XER and > then does a system call, the SO bit in CR0 will be set on return > regardless of whether the syst

[PATCH] powerpc: Fix system calls on Cell entered with XER.SO=1

It turns out that on Cell, on a kernel with CONFIG_VIRT_CPU_ACCOUNTING = y, if a program sets the SO (summary overflow) bit in the XER and then does a system call, the SO bit in CR0 will be set on return regardless of whether the system call detected an error. Since CR0.SO is used as the error ind

Re: powerpc: hv{cs, si}_close() both unsigned hp->count and hvcsd->open_count cannot be negative

Alan Cox writes: > See the tty_port patches in -next - this is an argument about code which > ought eventually to go away replaced by standard helper functions. OK. In that case I think the best fix for the existing code is just to change the count to be int rather than unsigned int. Paul.

Re: [PATCH v2] mmc: Add mmc_vddrange_to_ocrmask() helper function

On Wed, 26 Nov 2008 22:54:17 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > This function sets the OCR mask bits according to provided voltage > ranges. Will be used by the mmc_spi OpenFirmware bindings. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > --- > > Hi Pierre, > > Sorry f

Re: powerpc: hv{cs, si}_close() both unsigned hp->count and hvcsd->open_count cannot be negative

> Also, I don't see why those changes have anything to do with "unsigned > things cannot be negative". As long as those counts are never zero on > entry to those code sections, the existing code is fine, and I believe > that assertion can be maintained. If you believe the code needs to > defend a