- 08 Dec, 2011 3 commits
-
-
sukadev@linux.vnet.ibm.com authored
With CONFIG_STRICT_DEVMEM=y, user space cannot read any part of /dev/mem. Since this breaks librtas, punch a hole in /dev/mem to allow access to the rmo_buffer that librtas needs. Anton Blanchard reported the problem and helped with the fix. A quick test for this patch: # cat /proc/rtas/rmo_buffer 000000000f190000 10000 # python -c "print 0x000000000f190000 / 0x10000" 3865 # dd if=/dev/mem of=/tmp/foo count=1 bs=64k skip=3865 1+0 records in 1+0 records out 65536 bytes (66 kB) copied, 0.000205235 s, 319 MB/s # dd if=/dev/mem of=/tmp/foo dd: reading `/dev/mem': Operation not permitted 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.00022519 s, 0.0 kB/s Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
So I've had one of these for a while and it looks like the vendor never bothered submitting the support upstream. This adds it using ppc40x_simple and provides a device-tree. There are some changes to the boot wrapper because the way u-boot works on this thing, it seems to expect a multipart image with the kernel, initrd and dtb in it. The USB support is missing as it needs the yet unmerged driver for the DWC OTG part and the GPIOs may need further definition in the dts. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
-
- 07 Dec, 2011 28 commits
-
-
Benjamin Herrenschmidt authored
-
Benjamin Herrenschmidt authored
It's only used inside the same file where it's defined. There's also no point exporting it anymore. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
Open Firmware on OPAL machines seems to have issues if we close stdin and/or we try to print things after calling "quiesce" so we avoid doing both. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
This adds some more interfaces for OPAL v2 Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
Define HUGETLB_NEED_PRELOAD in mmu-book3e.h for CONFIG_PPC64 instead of having a much more complicated #if block. This is easier to read and maintain. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
This avoids an extra find_vma() and is less error-prone. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
Allow hugetlb to be enabled on 64b FSL_BOOK3E. No platforms enable it by default yet. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
For 64-bit FSL_BOOKE implementations, gigantic pages need to be reserved at boot time by the memblock code based on the command line. This adds the call that handles the reservation, and fixes some code comments. It also removes the previous pr_err when reserve_hugetlb_gpages is called on a system without hugetlb enabled - the way the code is structured, the call is unconditional and the resulting error message spurious and confusing. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
Before hugetlb, at each level of the table, we test for !0 to determine if we have a valid table entry. With hugetlb, this compare becomes: < 0 is a normal entry 0 is an invalid entry > 0 is huge This works because the hugepage code pulls the top bit off the entry (which for non-huge entries always has the top bit set) as an indicator that we have a hugepage. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
I happened to comment this code while I was digging through it; we might as well commit that. I also made some whitespace changes - the existing code had a lot of unnecessary newlines that I found annoying when I was working on my tiny laptop. No functional changes. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
The original 32-bit hugetlb implementation used PPC64 vs PPC32 to determine which code path to take. However, the final hugetlb implementation for 64-bit FSL ended up shared with the FSL 32-bit code so the actual check needs to be FSL_BOOK3E vs everything else. This patch changes the include protections to reflect this. There are also a couple of related comment fixes. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
This updates the hugetlb page table code to handle 64-bit FSL_BOOKE. The previous 32-bit work counted on the inner levels of the page table collapsing. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
This patch does 2 things: It corrects the code that determines the size to write into MAS1 for the PPC_MM_SLICES case (this originally came from David Gibson and I had incorrectly altered it), and it changes the methodolody used to calculate the size for !PPC_MM_SLICES to work for 64-bit as well as 32-bit. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
There was an unconditional return of "1" in the original code from David Gibson, and I dropped it because it wasn't needed for FSL BOOKE 32-bit. However, not all systems (including 64-bit FSL BOOKE) do loading of the hpte from the fault handler asm and depend on this function returning 1, which causes a call to update_mmu_cache() that writes an entry into the tlb. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Becky Bruce authored
If we don't have slices, we should be able to use the generic hugetlb_get_unmapped_area() code Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
The Cell and PowerMac platforms use virtually identical cascaded-IRQ setup code, so just merge it into the core. Ideally this code would trigger automatically when an MPIC device-node specifies an "interrupts" property, perhaps even enabling MPIC_SECONDARY along the way. Unfortunately, Benjamin Herrenschmidt has had bad experiences in the past with the quality of Apple PowerMac device-trees, so to be safe we will only try to parse out an IRQ if the MPIC_SECONDARY flag is set by the caller. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
Store the node pointer in the MPIC during initialization so that all of the later operational code can just reuse the cached pointer. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
There's not really any reason to have this one-liner in a separate static inline function, given that all the other similar tests are already in the alloc_mpic() code. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
Don't open-code the OpenFirmware "dcr-reg" property lookup trying to map DCR resources. This makes the code a bit easier to read. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
It turns out that there are only 2 in-tree platforms which use MPICs which are not "primary": IBM Cell and PowerMac. To reduce the complexity of the typical board setup code, invert the MPIC_PRIMARY bit into MPIC_SECONDARY. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
Almost all PowerPC platforms use a standard "open-pic" device node so the mpic_alloc() function now accepts NULL for the device-node. This will cause it to perform a default search with of_find_matching_node(). Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
The MPIC code can already perform an automatic OF address translation step as part of mpic_alloc(), but several boards need to use that base address when they perform mpic_assign_isu(). The easiest solution is to save the computed physical address into the "struct mpic" for later use by the board code. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
All of the existing callers of mpic_alloc() pass in a non-NULL device-node pointer, so the checks for a NULL device-node may be removed. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
Instead of using the open-coded "reg" property lookup and address translation in mpic_alloc(), directly call of_address_to_resource(). This includes various workarounds for special cases which the naive of_address_translate() does not. Afterwards it is possible to remove the copiously copy-pasted calls to of_address_translate() from the 85xx/86xx/powermac platforms. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Kyle Moffett authored
This removes a bunch of "extern" declarations and CONFIG_SMP ifdefs. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 28 Nov, 2011 6 commits
-
-
Dan McGee authored
Since commit 8a0a9bd4, this comment in mmap_rnd() does not hold true as the value returned by get_random_int() will in fact be different every single call. Remove the comment and simplify the code back to its original desired form. This reverts commit a5adc91a which is no longer necessary and also fixes the sparc code that copied this same adjustment. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Anton Blanchard authored
During kdump stress testing I sometimes see the kdump kernel panic with: Interrupt 0x306 (real) is invalid, disabling it. Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306 Instead of panicing print the error message, dump the stack the first time it happens and continue on. Add some more information to the debug messages as well. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Anton Blanchard authored
On a 64bit book3s machine I have an oops from a system reset that claims the book3e CE bit was set: MSR: 8000000000021032 <ME,CE,IR,DR> CR: 24004082 XER: 00000010 On a book3s machine system reset sets IBM bit 46 and 47 depending on the power saving mode. Separate the definitions by type and for completeness add the rest of the bits in. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Matthew McClintock authored
In lieu of having multiple similiar lines, we can just have one generic cpu-as line for CONFIG_ALTIVEC Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Dmitry Eremin-Solenikov authored
CPC925/CPC945 use special window to access host bridge functionality of u3-ht. Provide a way to access this device. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
sukadev@linux.vnet.ibm.com authored
As described in the help text in the patch, this token restricts general access to /dev/mem as a way of increasing the security. Specifically, access to exclusive IOMEM and kernel RAM is denied unless CONFIG_STRICT_DEVMEM is set to 'n'. Implement the 'devmem_is_allowed()' interface for Powerpc. It will be called from range_is_allowed() when userpsace attempts to access /dev/mem. This patch is based on an earlier patch from Steve Best and with input from Paul Mackerras and Scott Wood. [BenH] Fixed a typo or two and removed the generic change which should be submitted as a separate patch Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 25 Nov, 2011 3 commits
-
-
Benjamin Herrenschmidt authored
-
Justin P. Mattock authored
The patch below removes an extra semicolon. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> CC: linuxppc-dev@lists.ozlabs.org CC: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Ananth N Mavinakayanahalli authored
On Fri, Nov 11, 2011 at 10:17:55AM +0530, Ananth N Mavinakayanahalli wrote: > > > > At this rate we're going to end up with no bits left for CPU features > > way too quickly... Especially for something we only care about once at > > boot time. > > > > Wouldn't CPU_FTR_PPCAS_ARCH_V2 be a good enough test ? > > /me checks Cell manuals... yes, that test would be good enough. I will > cook up a patch to use this. Here it is... Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-