[PATCH] [POWERPC] Provide access to arch/powerpc include path on ppc64
There does not appear to be any reason that we shouldn't just have -Iarch/$(ARCH) on both ppc32 and ppc64 builds. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/Makefile | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index ab5cfe8..43ee815 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -71,13 +71,11 @@ endif LDFLAGS_vmlinux:= -Bstatic -CPPFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -AFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc -CFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -ffixed-r2 -mmultiple -KBUILD_CPPFLAGS+= $(CPPFLAGS-y) -KBUILD_AFLAGS += $(AFLAGS-y) -KBUILD_CFLAGS += -msoft-float -pipe $(CFLAGS-y) +CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple +KBUILD_CPPFLAGS+= -Iarch/$(ARCH) +KBUILD_AFLAGS += -Iarch/$(ARCH) +KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y) CPP= $(CC) -E $(KBUILD_CFLAGS) CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__ -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts
On Friday 21 March 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
+ [EMAIL PROTECTED] {
+ device_type = cpu;
+ model = PowerPC,460GT;
+ reg = 0;
I wonder if we should do something here to differenciate the SoC chip
from the core. After all, all those 4xx mostly have the same core (there
are 2 or 3 revisions of the core maybe ...) but they tend to have all
different PVR which is a pain and won't scale...
Maybe AMCC could do something in HW (splitting the PVR from whatever
indicates what chip it is, and keeping the PVR purely for the core
rev) but I'm wondering if we should also do something in the DTS..
Stefan can you talk to your AMCC contacts about this ?
Yes, I'll do that. Not sure about the outcome though.
As for the DTS, maybe a compatible property in the CPU might make some
sense with a content along the lines of ppc440x6 or whatever rev of
the 440 core it is.
What do you think ?
Good idea. I'll try to come up with a list for all existing 4xx SoC's and it's
core versions.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]
=
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS question
I wondered about this. Since the AD from Analog Devices is built into the part number, I didn't know if it was needed. And analog-devices is pretty long ;) But I am willing to put it in if it is necessary. Convention is to use the stock ticker symbol. If the company is private and has no stock ticker symbol, then the company name should be used. The three forms are, in order of preference: 0NN with NN the (hexadecimal) OUI; ABCDE (uppercase stock symbol); abcde (any name that cannot be confused for the other two forms; usually by making it lowercase). The preference is in this order because OUI _is_ unique, stock ticker will likely be unique (but not always!), and for random names there is no guarantee or assurance at all. I've never actually seen the OUI used, it's not very user-friendly ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS question
Convention is to use the stock ticker symbol. If the company is private and has no stock ticker symbol, then the company name should be used. I didn't know that. ADI it is then. Well.. stock ticker is the new convention. IEEE1275 used IEEE assigned OUI strings (Organization Unique Identifiers). Often those are the same as the stock ticker, but not always. Erm, an OUI is a 24-bit number. I think you're confusing something here. Stock ticker is a good choice for new things, but for anything from a vendor which has existing 1275 bindings for its products, I think we should keep the original assigned OUI, even if it differs from the stock ticker. Yes, when there is an existing binding, obviously you should use what it says (unless that binding is *completely* broken). Compatibility is good. Note that a stock symbol needs to be written in uppercase; in lowercase, it is just a random name that has no collision protection. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash in init_ipic_sysfs on efika
Is the MPC5200B PSC-AC97 driver in there? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Paul Mackerras wrote: Grant Likely writes: Confirmed, this patch fixes the problem. Paulus or Kumar, can you please pick it up for .25? Sure, will do. I thought about putting it in the last batch but I wanted an ack from you. Anyone else got any last-minute things for 2.6.25? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
On Fri, Mar 21, 2008 at 02:50:01PM +0100, Thomas Gleixner wrote: What about adding a CONFIG_ARCH_HAS_PTRACE2, which is set by the archs which are converted. For those which are not you add a fallback implementation: Bah. Folks, we're talking about adding a single new argument to a single function implemented by our 24 architectures. This is a trivial almost scriptable conversion. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
On Fri, Mar 21, 2008 at 02:50:01PM +0100, Thomas Gleixner wrote: On Thu, 20 Mar 2008, Roland McGrath wrote: Wouldn't it be nicer to just let arch_ptrace() return a flag saying whether it handled things or not? It would certainly be nicer. I would prefer: extern int arch_ptrace(struct task_struct *child, long request, long addr, long data, long *retval); where it returns an error code or it returns 0 and *retval is the value or it returns 1 and it didn't do anything. So this ugliness seemed like a better bet than waiting for 20 more arch sign-offs before any of it could go in. You are certainly in a position to just change the generic signature and make every arch do the update (or fix your typos if you just tweak them all blind), and let them grumble. I did not presume to do so. What about adding a CONFIG_ARCH_HAS_PTRACE2, which is set by the archs which are converted. For those which are not you add a fallback implementation: HAVE_PTRACE2 or at least following the HAVE_* semnatic. And then do: config HAVE_PTRACE2 def_bool n In some common file. Then arch files can do: config X86 ... + select HAVE_PTRACE2 Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
On Thu, 20 Mar 2008, Roland McGrath wrote:
Wouldn't it be nicer to just let arch_ptrace() return a flag saying
whether it handled things or not?
It would certainly be nicer. I would prefer:
extern int arch_ptrace(struct task_struct *child, long request,
long addr, long data, long *retval);
where it returns an error code or it returns 0 and *retval is the value
or it returns 1 and it didn't do anything.
So this ugliness seemed like a better bet than waiting for 20 more
arch sign-offs before any of it could go in. You are certainly in a
position to just change the generic signature and make every arch do
the update (or fix your typos if you just tweak them all blind), and
let them grumble. I did not presume to do so.
What about adding a CONFIG_ARCH_HAS_PTRACE2, which is set by the archs
which are converted. For those which are not you add a fallback
implementation:
#ifndef CONFIG_ARCH_HAS_PTRACE2
static int arch_ptrace2(whatever your favourite interface)
{
ret = arch_ptrace();
return do_ugly_fixups(ret);
}
#endif
That way you introduce the new interface and convert one or two archs
initialy without breaking the other 22.
At the same time you mark arch_ptrace() deprecated so it will get the
attention of the arch maintainers pretty fast. Once all archs are
converted we can remove the config flag and the fallback quirk.
Thanks,
tglx
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
On Thu, 20 Mar 2008, Roland McGrath wrote: The motivation is to get the arch function out of the code path for the machine-independent request handling. I want to be able to change the implementation later without touching the arch code again. If there is no stronger motivation than that, then I don't want to have this ugly and unnecessary complication. I really don't see the advantage of doing /* We can't handle it, let the generic code sort it out */ return -ENOSYS; over a /* We can't handle it, let the generic code sort it out */ return ptrace_request(child, request, addr, data); in the arch-specific code, and I think the latter version is *much* preferable if it avoids this whole unnecessary new abstraction crud and odd testing in the generic part. The reason I took the approach I did instead is incrementalism. I can't change that signature without breaking about 22 arch builds. Don't worry about the arch builds. If that's your main worry and reason for this, it's not worth it. Yes, ptrace changes, and yes, we may have arch issues, but no, it's not that big of a deal. Just break them. Make sure x86[-64] works, and make sure that other architectures *can* work (and explain it on linux-arch) when you have to fix something up, but ptrace is a blip on the radar for people, it's not going to be a huge issue. I'm only really prepared to thoroughly verify a change on 2 of those myself. .. and you really aren't expected to. It's why we have architecture people: if there is a good reason for the change (ie it's not just some churn for churns sake), it's largely up to them to make sure the code works. Sure, you need to be able to explain the interface changes and answer questions, but as mentioned, the ptrace code is not a big deal: it has lots of tiny _details_, but it's not conceptually complex code. So this ugliness seemed like a better bet than waiting for 20 more arch sign-offs before any of it could go in. Really, that has never been a major concern. I will _happily_ break the odd architectures if I see that it's a matter of changing over some detail (ie it's not some fundamentally hard issue for an arch maintaner to fix up). I think it's *wrong* to add a new an odd calling convention that is less readable than what we have now, just to try to avoid something like this that really isn't a big problem. It's not like we haven't broken architectures over ptrace in the past, and it's also not like it's an area that I think anybody has ever lost sleep over.. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] generic __remove_pages() support
Badari-san.
Index: linux-2.6.25-rc2/mm/memory_hotplug.c
===
--- linux-2.6.25-rc2.orig/mm/memory_hotplug.c 2008-02-27 12:58:17.0
-0800
+++ linux-2.6.25-rc2/mm/memory_hotplug.c 2008-02-27 16:06:50.0
-0800
@@ -102,6 +102,21 @@ static int __add_section(struct zone *zo
return register_new_memory(__pfn_to_section(phys_start_pfn));
}
+static int __remove_section(struct zone *zone, struct mem_section *ms)
+{
+ int ret = -EINVAL;
+
+ if (!valid_section(ms))
+ return ret;
+
+ ret = unregister_memory_section(ms);
+ if (ret)
+ return ret;
+
+ sparse_remove_one_section(zone, ms);
+ return 0;
+}
+
/*
* Reasonably generic function for adding memory. It is
* expected that archs that support memory hotplug will
@@ -135,6 +150,35 @@ int __add_pages(struct zone *zone, unsig
}
EXPORT_SYMBOL_GPL(__add_pages);
+int __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
+ unsigned long nr_pages)
+{
+ unsigned long i, ret = 0;
+ int sections_to_remove;
+ unsigned long flags;
+ struct pglist_data *pgdat = zone-zone_pgdat;
+
+ /*
+ * We can only remove entire sections
+ */
+ BUG_ON(phys_start_pfn ~PAGE_SECTION_MASK);
+ BUG_ON(nr_pages % PAGES_PER_SECTION);
+
+ release_mem_region(phys_start_pfn PAGE_SHIFT, nr_pages * PAGE_SIZE);
+
+ sections_to_remove = nr_pages / PAGES_PER_SECTION;
+ for (i = 0; i sections_to_remove; i++) {
+ unsigned long pfn = phys_start_pfn + i*PAGES_PER_SECTION;
+ pgdat_resize_lock(pgdat, flags);
+ ret = __remove_section(zone, __pfn_to_section(pfn));
+ pgdat_resize_unlock(pgdat, flags);
+ if (ret)
+ break;
+ }
+ return ret;
+}
+EXPORT_SYMBOL_GPL(__remove_pages);
Here may be a bug.
__remove_section() is called with pgdat_resize_lock() which is
spin_lock_irqsave().
__remove_section()
|
+-- unregister_memory_section()
|
+-- remove_memory_block()
|
+-- unregister_memory()
|
+-- sysdev_unregister()
sysdev_unregister() calls mutex_lock().
It might sleep with irq disable, right?
I found BUG()'s messages by this.
Bye.
--
Yasunori Goto
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
Personally, I'm not fond of this approach. There is already some traction to using the reg-shift property to specify spacing, and I think it would be appropriate to also define a reg-offset property to handle the +3 offset and then let the xilinx 16550 nodes use those. That's making things only worse than the mere reg-shift idea. I think that both are totally wrong. Everything about the programming interface should be said in the compatible and possibly model properties. No. In effect, you are saying here that no device binding should define any binding-specific properties. This will just lead to combinatorial explosion of compatible values. That said, reg-spacing/reg-shift/reg-offset should *not* be considered something generic; they are part of specific device bindings. Of course it is nice if various bindings use the same names for the same concepts, but that's an orthogonal issue. of_serial driver should recognize them and pass the necessary details to 8250.c. As for me, I'm strongly against plaguing the device tree with the *Linux driver implementation specifics* reg-* has nothing to do with Linux device driver implementation issues: it describes how a device is physically wired up! (despite I was trying this with MTD -- there it seemed somewhat more grounded :-). Quite the opposite, but let's not rehash that discussion. In support of my argument; the fact that you need a table of data says to me that this data should really be encoded in the device tree. :-) Not at all. Not _necessarily_. I agree with Grant here: for many of these devices with byte-size registers, it is very common to find them with their register banks wired up differently, and that is often the *only* difference to the normal device. In this situation, it makes a lot of sense to describe that difference with reg-* properties. In some other situations, it is better to create a new binding for the device. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Make 83xx perfmon support selectable
On Thu, Mar 20, 2008 at 07:59:41PM -0400, Jerry Van Baren wrote: Per Andy (and my limited reading of the UMs), some 83xx have the PMR registers and some don't. The compiler either supports the PMR register or it doesn't. If you make it runtime configurable, people running CPUs that don't support the specific PMR will have to change compiler configurations in order to compile with the PMR register in there (could have unintended consequences). I'm not saying make it runtime-only -- you can still have a config option to determine whether to build a kernel that supports it. I'm saying there should be an additional runtime check so that if you run a multiplatform kernel with perfmon enabled on a chip that doesn't support it, you won't take a program check. Also, if you look at the code (arch/powerpc/kernel/pmc.c), there are several different types of PMR registers, based on the core and flavor of the core. Finding or making a compiler setup that supports all of the possible PMR registers could be a problem. It only needs to support all possible registers within a class of hardware over which we support multiplatform kernels. You would still have to make the PMR read/write runtime selectable because the CPUs that don't support that register will raise an exception IIRC (an Really Bad Thing[tm]). Yes, that was my point. The changelog on the patch seemed to indicate that the compile-time option was intended to address this, not just the toolchain problem. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart16550.
I thought about this, and reconsidered it again after I finally figured out how to get the Power.org website to relenquish the ePAPR spec, which (FWIW) has reg-shift as an optional property of the ns16550 binding. However, I'm not enamoured of it, since I doubt it's really good to be doing ioremaps and memory management on unaligned blocks. It seems more logical to me to have the reg property define a range of aligned addresses, and in this case, it happens that the driver never touches some of those bytes. Yes, and that is (part of) why reg-offset might be needed / might be a good idea. In any event, the real point of the patch was to spark some discussion, which we failed to get otherwise.. :) You succeeded :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart16550.
-Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Segher Boessenkool Sent: Friday, March 21, 2008 9:46 AM To: Sergei Shtylyov Cc: linuxppc-dev@ozlabs.org; John Linn Subject: Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart16550. The proposed use clearly would treat them as generic, since in the context of the Xilinx UART they're just not needed -- it's known beforehand and most probably fixed how/where the registers are mapped. There's just no need for such info in the device tree -- unless you're going to teach the *generic* driver to handle this specific (and possibly others alike) kind of a device. I was under the impression that the xilinx uart was just a 16550 (or so) with its registers wired up in a slightly unusual way. If it's a completely different device, of course you need a separate binding, and you might not want reg-shift properties etc. there. It's a standard 16550, with registers in the standard order, but at offsets 3,7,11, etc. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dcr stuff.
Is anybody working on the dcr infrastructure? In particular, there seems to be inconsistency between what the kernel does and what ePAPR thinks it should. The code in the kernel selects mmio or native access based on a Kconfig parameter and uses some device tree parameters to correctly configure the mmio access, whereas ePAPR doesn't seem to document all the device tree attributes (in particular, dcr-mmio-stride and dcr-mmio-range) and provides a dynamic binding for dcr-access-method... Is there a plan here? (In particular, in FPGA designs, its possible to have crazy things like multiple independent dcr busses, some using native access, some using mmio. Or even if there is one bus, many of the existing non-linux drivers we have assume native or mmio access. I'd like to clean this up, obviously.. :) Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dcr stuff.
On Fri, 2008-03-21 at 12:05 -0700, Stephen Neuendorffer wrote: Is anybody working on the dcr infrastructure? In particular, there seems to be inconsistency between what the kernel does and what ePAPR thinks it should. The code in the kernel selects mmio or native access based on a Kconfig parameter and uses some device tree parameters to correctly configure the mmio access, whereas ePAPR doesn't seem to document all the device tree attributes (in particular, dcr-mmio-stride and dcr-mmio-range) and provides a dynamic binding for dcr-access-method... Is there a plan here? (In particular, in FPGA designs, its possible to have crazy things like multiple independent dcr busses, some using native access, some using mmio. Or even if there is one bus, many of the existing non-linux drivers we have assume native or mmio access. I'd like to clean this up, obviously.. :) So far, the crazy things never happened, at least as far as I can tell, which is why the kernel does what it does. That allows to inline the DCR instructions on 4xx processors, and thus avoids code bloat. It also avoids trying to use DCR instructions on processors that don't support them like Cell with the Axon bridge. If it becomes necessary, we can make it dynamic tho. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
The following series of patches implement a basic framework for hypervisor-assisted dump. The very first patch provides documentation explaining what this is. A list of open issues / todo list is included in the documentation. It also appears that the not-yet-released firmware versions this was tested on are still,incomplete; this work is also pending. The following is a list of changes from previous version: - Deleted ifdef CONFIG_PHYP_DUMP from early_init_dt_scan_phyp_dump function. - Changed reserve_crashed_mem() to phyp_dump_reserve_mem() as suggested. - Added #ifdef CONFIG_PHYP_DUMP around of_scan_flat_dt call, removed empty function from header file. - Changed phyp_dump_global to phyp_dump_vars. - Changed style issues at several places. Manish Linas. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] pseries: phyp dump: Documentation
Basic documentation for hypervisor-assisted dump. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Signed-off-by: Manish Ahuja [EMAIL PROTECTED] --- Documentation/powerpc/phyp-assisted-dump.txt | 127 +++ 1 file changed, 127 insertions(+) Index: 2.6.25-rc1/Documentation/powerpc/phyp-assisted-dump.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ 2.6.25-rc1/Documentation/powerpc/phyp-assisted-dump.txt 2008-02-18 03:22:33.0 -0600 @@ -0,0 +1,127 @@ + + Hypervisor-Assisted Dump + + November 2007 + +The goal of hypervisor-assisted dump is to enable the dump of +a crashed system, and to do so from a fully-reset system, and +to minimize the total elapsed time until the system is back +in production use. + +As compared to kdump or other strategies, hypervisor-assisted +dump offers several strong, practical advantages: + +-- Unlike kdump, the system has been reset, and loaded + with a fresh copy of the kernel. In particular, + PCI and I/O devices have been reinitialized and are + in a clean, consistent state. +-- As the dump is performed, the dumped memory becomes + immediately available to the system for normal use. +-- After the dump is completed, no further reboots are + required; the system will be fully usable, and running + in it's normal, production mode on it normal kernel. + +The above can only be accomplished by coordination with, +and assistance from the hypervisor. The procedure is +as follows: + +-- When a system crashes, the hypervisor will save + the low 256MB of RAM to a previously registered + save region. It will also save system state, system + registers, and hardware PTE's. + +-- After the low 256MB area has been saved, the + hypervisor will reset PCI and other hardware state. + It will *not* clear RAM. It will then launch the + bootloader, as normal. + +-- The freshly booted kernel will notice that there + is a new node (ibm,dump-kernel) in the device tree, + indicating that there is crash data available from + a previous boot. It will boot into only 256MB of RAM, + reserving the rest of system memory. + +-- Userspace tools will parse /sys/kernel/release_region + and read /proc/vmcore to obtain the contents of memory, + which holds the previous crashed kernel. The userspace + tools may copy this info to disk, or network, nas, san, + iscsi, etc. as desired. + + For Example: the values in /sys/kernel/release-region + would look something like this (address-range pairs). + CPU:0x177fee000-0x1: HPTE:0x177ffe020-0x1000: / + DUMP:0x177fff020-0x1000, 0x1000-0x16F1D370A + +-- As the userspace tools complete saving a portion of + dump, they echo an offset and size to + /sys/kernel/release_region to release the reserved + memory back to general use. + + An example of this is: + echo 0x4000 0x1000 /sys/kernel/release_region + which will release 256MB at the 1GB boundary. + +Please note that the hypervisor-assisted dump feature +is only available on Power6-based systems with recent +firmware versions. + +Implementation details: +-- + +During boot, a check is made to see if firmware supports +this feature on this particular machine. If it does, then +we check to see if a active dump is waiting for us. If yes +then everything but 256 MB of RAM is reserved during early +boot. This area is released once we collect a dump from user +land scripts that are run. If there is dump data, then +the /sys/kernel/release_region file is created, and +the reserved memory is held. + +If there is no waiting dump data, then only the highest +256MB of the ram is reserved as a scratch area. This area +is *not* be released: this region will be kept permanently +reserved, so that it can act as a receptacle for a copy +of the low 256MB in the case a crash does occur. See, +however, open issues below, as to whether +such a reserved region is really needed. + +Currently the dump will be copied from /proc/vmcore to a +a new file upon user intervention. The starting address +to be read and the range for each data point in provided +in /sys/kernel/release_region. + +The tools to examine the dump will be same as the ones +used for kdump. + +General notes: +-- +Security: please note that there are potential security issues +with any sort of dump mechanism. In particular, plaintext +(unencrypted) data, and possibly passwords, may be present in +the dump data. Userspace tools must take adequate precautions to +preserve security. + +Open issues/ToDo: + + o The various code paths that tell the hypervisor that a crash + occurred, vs. it simply being a normal reboot, should be + reviewed, and possibly clarified/fixed. + + o Instead of using /sys/kernel, should there be a /sys/dump + instead? There is a
[PATCH 2/8] pseries: phyp dump: reserve-release
Initial patch for reserving memory in early boot, and freeing it later.
If the previous boot had ended with a crash, the reserved memory would contain
a copy of the crashed kernel data.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
---
arch/powerpc/kernel/prom.c | 52 ++
arch/powerpc/platforms/pseries/Makefile|1
arch/powerpc/platforms/pseries/phyp_dump.c | 103 +
include/asm-powerpc/phyp_dump.h| 41 +++
4 files changed, 197 insertions(+)
Index: 2.6.25-rc1/include/asm-powerpc/phyp_dump.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ 2.6.25-rc1/include/asm-powerpc/phyp_dump.h 2008-03-21 23:37:11.0
-0500
@@ -0,0 +1,41 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2008
+ * Copyright 2008 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _PPC64_PHYP_DUMP_H
+#define _PPC64_PHYP_DUMP_H
+
+#ifdef CONFIG_PHYP_DUMP
+
+/* The RMR region will be saved for later dumping
+ * whenever the kernel crashes. Set this to 256MB. */
+#define PHYP_DUMP_RMR_START 0x0
+#define PHYP_DUMP_RMR_END (1UL28)
+
+struct phyp_dump {
+ /* Memory that is reserved during very early boot. */
+ unsigned long init_reserve_start;
+ unsigned long init_reserve_size;
+ /* Check status during boot if dump supported, active present*/
+ unsigned long phyp_dump_configured;
+ unsigned long phyp_dump_is_active;
+ /* store cpu hpte size */
+ unsigned long cpu_state_size;
+ unsigned long hpte_region_size;
+};
+
+extern struct phyp_dump *phyp_dump_info;
+
+int early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data);
+
+#endif /* CONFIG_PHYP_DUMP */
+#endif /* _PPC64_PHYP_DUMP_H */
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
23:37:12.0 -0500
@@ -0,0 +1,103 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2008
+ * Copyright 2008 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include linux/init.h
+#include linux/mm.h
+#include linux/pfn.h
+#include linux/swap.h
+
+#include asm/page.h
+#include asm/phyp_dump.h
+#include asm/machdep.h
+#include asm/prom.h
+
+/* Variables, used to communicate data between early boot and late boot */
+static struct phyp_dump phyp_dump_vars;
+struct phyp_dump *phyp_dump_info = phyp_dump_vars;
+
+/**
+ * release_memory_range -- release memory previously lmb_reserved
+ * @start_pfn: starting physical frame number
+ * @nr_pages: number of pages to free.
+ *
+ * This routine will release memory that had been previously
+ * lmb_reserved in early boot. The released memory becomes
+ * available for genreal use.
+ */
+static void
+release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+{
+ struct page *rpage;
+ unsigned long end_pfn;
+ long i;
+
+ end_pfn = start_pfn + nr_pages;
+
+ for (i = start_pfn; i = end_pfn; i++) {
+ rpage = pfn_to_page(i);
+ if (PageReserved(rpage)) {
+ ClearPageReserved(rpage);
+ init_page_count(rpage);
+ __free_page(rpage);
+ totalram_pages++;
+ }
+ }
+}
+
+static int __init phyp_dump_setup(void)
+{
+ unsigned long start_pfn, nr_pages;
+
+ /* If no memory was reserved in early boot, there is nothing to do */
+ if (phyp_dump_info-init_reserve_size == 0)
+ return 0;
+
+ /* Release memory that was reserved in early boot */
+ start_pfn = PFN_DOWN(phyp_dump_info-init_reserve_start);
+ nr_pages = PFN_DOWN(phyp_dump_info-init_reserve_size);
+ release_memory_range(start_pfn, nr_pages);
+
+ return 0;
+}
+machine_subsys_initcall(pseries, phyp_dump_setup);
+
+int __init early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ const unsigned int *sizes;
+
+ phyp_dump_info-phyp_dump_configured = 0;
+ phyp_dump_info-phyp_dump_is_active = 0;
+
+ if (depth != 1 || strcmp(uname, rtas) != 0)
+ return
[PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo 0x4000 0x1000 /sys/kernel/release_region
will release 256MB starting at the 1GB. The released memory
becomes free for general use.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/phyp_dump.c | 81 +++--
1 file changed, 76 insertions(+), 5 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
00:10:15.0 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
22:39:21.0 -0500
@@ -12,19 +12,24 @@
*/
#include linux/init.h
+#include linux/kobject.h
#include linux/mm.h
+#include linux/of.h
#include linux/pfn.h
#include linux/swap.h
+#include linux/sysfs.h
#include asm/page.h
#include asm/phyp_dump.h
#include asm/machdep.h
#include asm/prom.h
+#include asm/rtas.h
/* Variables, used to communicate data between early boot and late boot */
static struct phyp_dump phyp_dump_vars;
struct phyp_dump *phyp_dump_info = phyp_dump_vars;
+/* - */
/**
* release_memory_range -- release memory previously lmb_reserved
* @start_pfn: starting physical frame number
@@ -54,18 +59,84 @@ release_memory_range(unsigned long start
}
}
-static int __init phyp_dump_setup(void)
+/* - */
+/**
+ * sysfs_release_region -- sysfs interface to release memory range.
+ *
+ * Usage:
+ * echo start addr length /sys/kernel/release_region
+ *
+ * Example:
+ * echo 0x4000 0x1000 /sys/kernel/release_region
+ *
+ * will release 256MB starting at 1GB.
+ */
+static ssize_t store_release_region(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
+ unsigned long start_addr, length, end_addr;
unsigned long start_pfn, nr_pages;
+ ssize_t ret;
+
+ ret = sscanf(buf, %lx %lx, start_addr, length);
+ if (ret != 2)
+ return -EINVAL;
+
+ /* Range-check - don't free any reserved memory that
+* wasn't reserved for phyp-dump */
+ if (start_addr phyp_dump_info-init_reserve_start)
+ start_addr = phyp_dump_info-init_reserve_start;
+
+ end_addr = phyp_dump_info-init_reserve_start +
+ phyp_dump_info-init_reserve_size;
+ if (start_addr+length end_addr)
+ length = end_addr - start_addr;
+
+ /* Release the region of memory assed in by user */
+ start_pfn = PFN_DOWN(start_addr);
+ nr_pages = PFN_DOWN(length);
+ release_memory_range(start_pfn, nr_pages);
+
+ return count;
+}
+
+static struct kobj_attribute rr = __ATTR(release_region, 0600,
+NULL, store_release_region);
+
+static int __init phyp_dump_setup(void)
+{
+ struct device_node *rtas;
+ const int *dump_header = NULL;
+ int header_len = 0;
+ int rc;
/* If no memory was reserved in early boot, there is nothing to do */
if (phyp_dump_info-init_reserve_size == 0)
return 0;
- /* Release memory that was reserved in early boot */
- start_pfn = PFN_DOWN(phyp_dump_info-init_reserve_start);
- nr_pages = PFN_DOWN(phyp_dump_info-init_reserve_size);
- release_memory_range(start_pfn, nr_pages);
+ /* Return if phyp dump not supported */
+ if (!phyp_dump_info-phyp_dump_configured)
+ return -ENOSYS;
+
+ /* Is there dump data waiting for us? */
+ rtas = of_find_node_by_path(/rtas);
+ if (rtas) {
+ dump_header = of_get_property(rtas, ibm,kernel-dump,
+ header_len);
+ of_node_put(rtas);
+ }
+
+ if (dump_header == NULL)
+ return 0;
+
+ /* Should we create a dump_subsys, analogous to s390/ipl.c ? */
+ rc = sysfs_create_file(kernel_kobj, rr.attr);
+ if (rc) {
+ printk(KERN_ERR phyp-dump: unable to create sysfs file (%d)\n,
+ rc);
+ return 0;
+ }
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/8] pseries: phyp dump: register dump area.
Set up the actual dump header, register it with the hypervisor.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/phyp_dump.c | 137 +++--
1 file changed, 131 insertions(+), 6 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
22:39:21.0 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
22:52:53.0 -0500
@@ -29,6 +29,117 @@
static struct phyp_dump phyp_dump_vars;
struct phyp_dump *phyp_dump_info = phyp_dump_vars;
+static int ibm_configure_kernel_dump;
+/* - */
+/* RTAS interfaces to declare the dump regions */
+
+struct dump_section {
+ u32 dump_flags;
+ u16 source_type;
+ u16 error_flags;
+ u64 source_address;
+ u64 source_length;
+ u64 length_copied;
+ u64 destination_address;
+};
+
+struct phyp_dump_header {
+ u32 version;
+ u16 num_of_sections;
+ u16 status;
+
+ u32 first_offset_section;
+ u32 dump_disk_section;
+ u64 block_num_dd;
+ u64 num_of_blocks_dd;
+ u32 offset_dd;
+ u32 maxtime_to_auto;
+ /* No dump disk path string used */
+
+ struct dump_section cpu_data;
+ struct dump_section hpte_data;
+ struct dump_section kernel_data;
+};
+
+/* The dump header *must be* in low memory, so .bss it */
+static struct phyp_dump_header phdr;
+
+#define NUM_DUMP_SECTIONS 3
+#define DUMP_HEADER_VERSION0x1
+#define DUMP_REQUEST_FLAG 0x1
+#define DUMP_SOURCE_CPU0x0001
+#define DUMP_SOURCE_HPTE 0x0002
+#define DUMP_SOURCE_RMO0x0011
+
+/**
+ * init_dump_header() - initialize the header declaring a dump
+ * Returns: length of dump save area.
+ *
+ * When the hypervisor saves crashed state, it needs to put
+ * it somewhere. The dump header tells the hypervisor where
+ * the data can be saved.
+ */
+static unsigned long init_dump_header(struct phyp_dump_header *ph)
+{
+ unsigned long addr_offset = 0;
+
+ /* Set up the dump header */
+ ph-version = DUMP_HEADER_VERSION;
+ ph-num_of_sections = NUM_DUMP_SECTIONS;
+ ph-status = 0;
+
+ ph-first_offset_section =
+ (u32)offsetof(struct phyp_dump_header, cpu_data);
+ ph-dump_disk_section = 0;
+ ph-block_num_dd = 0;
+ ph-num_of_blocks_dd = 0;
+ ph-offset_dd = 0;
+
+ ph-maxtime_to_auto = 0; /* disabled */
+
+ /* The first two sections are mandatory */
+ ph-cpu_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph-cpu_data.source_type = DUMP_SOURCE_CPU;
+ ph-cpu_data.source_address = 0;
+ ph-cpu_data.source_length = phyp_dump_info-cpu_state_size;
+ ph-cpu_data.destination_address = addr_offset;
+ addr_offset += phyp_dump_info-cpu_state_size;
+
+ ph-hpte_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph-hpte_data.source_type = DUMP_SOURCE_HPTE;
+ ph-hpte_data.source_address = 0;
+ ph-hpte_data.source_length = phyp_dump_info-hpte_region_size;
+ ph-hpte_data.destination_address = addr_offset;
+ addr_offset += phyp_dump_info-hpte_region_size;
+
+ /* This section describes the low kernel region */
+ ph-kernel_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph-kernel_data.source_type = DUMP_SOURCE_RMO;
+ ph-kernel_data.source_address = PHYP_DUMP_RMR_START;
+ ph-kernel_data.source_length = PHYP_DUMP_RMR_END;
+ ph-kernel_data.destination_address = addr_offset;
+ addr_offset += ph-kernel_data.source_length;
+
+ return addr_offset;
+}
+
+static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
+{
+ int rc;
+ ph-cpu_data.destination_address += addr;
+ ph-hpte_data.destination_address += addr;
+ ph-kernel_data.destination_address += addr;
+
+ do {
+ rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+ 1, ph, sizeof(struct phyp_dump_header));
+ } while (rtas_busy_delay(rc));
+
+ if (rc)
+ printk(KERN_ERR phyp-dump: unexpected error (%d) on
+ register\n, rc);
+}
+
/* - */
/**
* release_memory_range -- release memory previously lmb_reserved
@@ -107,7 +218,9 @@ static struct kobj_attribute rr = __ATTR
static int __init phyp_dump_setup(void)
{
struct device_node *rtas;
- const int *dump_header = NULL;
+ const struct phyp_dump_header *dump_header = NULL;
+ unsigned long dump_area_start;
+ unsigned long dump_area_length;
int header_len = 0;
int rc;
@@ -119,7 +232,13 @@ static int __init phyp_dump_setup(void)
[PATCH 5/8] pseries: phyp dump: debugging print routines.
Provide some basic debugging support.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/phyp_dump.c | 61 -
1 file changed, 59 insertions(+), 2 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
22:52:53.0 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
22:54:44.0 -0500
@@ -123,6 +123,61 @@ static unsigned long init_dump_header(st
return addr_offset;
}
+static void print_dump_header(const struct phyp_dump_header *ph)
+{
+#ifdef DEBUG
+ printk(KERN_INFO dump header:\n);
+ /* setup some ph-sections required */
+ printk(KERN_INFO version = %d\n, ph-version);
+ printk(KERN_INFO Sections = %d\n, ph-num_of_sections);
+ printk(KERN_INFO Status = 0x%x\n, ph-status);
+
+ /* No ph-disk, so all should be set to 0 */
+ printk(KERN_INFO Offset to first section 0x%x\n,
+ ph-first_offset_section);
+ printk(KERN_INFO dump disk sections should be zero\n);
+ printk(KERN_INFO dump disk section = %d\n, ph-dump_disk_section);
+ printk(KERN_INFO block num = %ld\n, ph-block_num_dd);
+ printk(KERN_INFO number of blocks = %ld\n, ph-num_of_blocks_dd);
+ printk(KERN_INFO dump disk offset = %d\n, ph-offset_dd);
+ printk(KERN_INFO Max auto time= %d\n, ph-maxtime_to_auto);
+
+ /*set cpu state and hpte states as well scratch pad area */
+ printk(KERN_INFO CPU AREA \n);
+ printk(KERN_INFO cpu dump_flags =%d\n, ph-cpu_data.dump_flags);
+ printk(KERN_INFO cpu source_type =%d\n, ph-cpu_data.source_type);
+ printk(KERN_INFO cpu error_flags =%d\n, ph-cpu_data.error_flags);
+ printk(KERN_INFO cpu source_address =%lx\n,
+ ph-cpu_data.source_address);
+ printk(KERN_INFO cpu source_length =%lx\n,
+ ph-cpu_data.source_length);
+ printk(KERN_INFO cpu length_copied =%lx\n,
+ ph-cpu_data.length_copied);
+
+ printk(KERN_INFO HPTE AREA \n);
+ printk(KERN_INFO HPTE dump_flags =%d\n, ph-hpte_data.dump_flags);
+ printk(KERN_INFO HPTE source_type =%d\n, ph-hpte_data.source_type);
+ printk(KERN_INFO HPTE error_flags =%d\n, ph-hpte_data.error_flags);
+ printk(KERN_INFO HPTE source_address =%lx\n,
+ ph-hpte_data.source_address);
+ printk(KERN_INFO HPTE source_length =%lx\n,
+ ph-hpte_data.source_length);
+ printk(KERN_INFO HPTE length_copied =%lx\n,
+ ph-hpte_data.length_copied);
+
+ printk(KERN_INFO SRSD AREA \n);
+ printk(KERN_INFO SRSD dump_flags =%d\n, ph-kernel_data.dump_flags);
+ printk(KERN_INFO SRSD source_type =%d\n, ph-kernel_data.source_type);
+ printk(KERN_INFO SRSD error_flags =%d\n, ph-kernel_data.error_flags);
+ printk(KERN_INFO SRSD source_address =%lx\n,
+ ph-kernel_data.source_address);
+ printk(KERN_INFO SRSD source_length =%lx\n,
+ ph-kernel_data.source_length);
+ printk(KERN_INFO SRSD length_copied =%lx\n,
+ ph-kernel_data.length_copied);
+#endif
+}
+
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
@@ -135,9 +190,11 @@ static void register_dump_area(struct ph
1, ph, sizeof(struct phyp_dump_header));
} while (rtas_busy_delay(rc));
- if (rc)
+ if (rc) {
printk(KERN_ERR phyp-dump: unexpected error (%d) on
register\n, rc);
+ print_dump_header(ph);
+ }
}
/* - */
@@ -246,8 +303,8 @@ static int __init phyp_dump_setup(void)
of_node_put(rtas);
}
+ print_dump_header(dump_header);
dump_area_length = init_dump_header(phdr);
-
/* align down */
dump_area_start = phyp_dump_info-init_reserve_start PAGE_MASK;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC] mpc52xx: Amalgamated dts fixes and updates
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with few
other updates, in particluar one posted by Anatolij Gustschin, which fixes
an Oops during boot.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
Anatolij, would you like to add your S-O-B?
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..8b2e8e4 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -159,6 +159,7 @@
};
[EMAIL PROTECTED] {
+ device_type = dma-controller;
compatible =
fsl,mpc5200b-bestcomm,fsl,mpc5200-bestcomm;
reg = 1200 80;
interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
@@ -212,13 +213,31 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
+ compatible = fsl,mpc5200b-mdio;
+ reg = 3000 400; // fec range, since we need to
setup fec interrupts
+ interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
};
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible =
fsl,mpc5200b-i2c,fsl,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
@@ -231,4 +250,22 @@
reg = 8000 4000;
};
};
+
+ lpb {
+ model = fsl,lpb;
+ compatible = fsl,lpb;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 fc00 200;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 200;
+ bank-width = 2;
+ device-width = 2;
+ #size-cells = 1;
+ #address-cells = 1;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..9ca81ff 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -127,6 +127,13 @@
interrupt-parent = mpc5200_pic;
};
+ [EMAIL PROTECTED] {
+ compatible = mpc5200b-mscan\0mpc5200-mscan;
+ interrupts = 2 11 0;
+ interrupt-parent = mpc5200_pic;
+ reg = 900 80;
+ };
+
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-mscan,fsl,mpc5200-mscan;
interrupts = 2 12 0;
@@ -148,7 +155,6 @@
interrupt-parent = mpc5200_pic;
};
-
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-spi,fsl,mpc5200-spi;
reg = f00 20;
@@ -164,6 +170,7 @@
};
[EMAIL PROTECTED] {
+ device_type = dma-controller;
compatible =
fsl,mpc5200b-bestcomm,fsl,mpc5200-bestcomm;
reg = 1200 80;
interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
@@ -209,10 +216,26 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
+ compatible = fsl,mpc5200b-mdio;
+ reg = 3000 400; // fec range, since
[PATCH 6/8] pseries: phyp dump: Invalidate and print dump areas.
Routines to
a. invalidate dump
b. Calculate region that is reserved and needs to be freed. This is
exported through sysfs interface.
Unregister has been removed for now as it wasn't being used.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/phyp_dump.c | 83 ++---
include/asm-powerpc/phyp_dump.h|3 +
2 files changed, 80 insertions(+), 6 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-20
21:52:59.0 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-20
21:55:52.0 -0500
@@ -70,6 +70,10 @@ static struct phyp_dump_header phdr;
#define DUMP_SOURCE_CPU0x0001
#define DUMP_SOURCE_HPTE 0x0002
#define DUMP_SOURCE_RMO0x0011
+#define DUMP_ERROR_FLAG0x2000
+#define DUMP_TRIGGERED 0x4000
+#define DUMP_PERFORMED 0x8000
+
/**
* init_dump_header() - initialize the header declaring a dump
@@ -181,9 +185,15 @@ static void print_dump_header(const stru
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
- ph-cpu_data.destination_address += addr;
- ph-hpte_data.destination_address += addr;
- ph-kernel_data.destination_address += addr;
+
+ /* Add addr value if not initialized before */
+ if (ph-cpu_data.destination_address == 0) {
+ ph-cpu_data.destination_address += addr;
+ ph-hpte_data.destination_address += addr;
+ ph-kernel_data.destination_address += addr;
+ }
+
+ /* ToDo Invalidate kdump and free memory range. */
do {
rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
@@ -197,6 +207,30 @@ static void register_dump_area(struct ph
}
}
+static
+void invalidate_last_dump(struct phyp_dump_header *ph, unsigned long addr)
+{
+ int rc;
+
+ /* Add addr value if not initialized before */
+ if (ph-cpu_data.destination_address == 0) {
+ ph-cpu_data.destination_address += addr;
+ ph-hpte_data.destination_address += addr;
+ ph-kernel_data.destination_address += addr;
+ }
+
+ do {
+ rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+ 2, ph, sizeof(struct phyp_dump_header));
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk(KERN_ERR phyp-dump: unexpected error (%d)
+ on invalidate\n, rc);
+ print_dump_header(ph);
+ }
+}
+
/* - */
/**
* release_memory_range -- release memory previously lmb_reserved
@@ -207,8 +241,8 @@ static void register_dump_area(struct ph
* lmb_reserved in early boot. The released memory becomes
* available for genreal use.
*/
-static void
-release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+static void release_memory_range(unsigned long start_pfn,
+ unsigned long nr_pages)
{
struct page *rpage;
unsigned long end_pfn;
@@ -269,8 +303,29 @@ static ssize_t store_release_region(stru
return count;
}
+static ssize_t show_release_region(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ u64 second_addr_range;
+
+ /* total reserved size - start of scratch area */
+ second_addr_range = phyp_dump_info-init_reserve_size -
+ phyp_dump_info-reserved_scratch_size;
+ return sprintf(buf, CPU:0x%lx-0x%lx: HPTE:0x%lx-0x%lx:
+DUMP:0x%lx-0x%lx, 0x%lx-0x%lx:\n,
+ phdr.cpu_data.destination_address,
+ phdr.cpu_data.length_copied,
+ phdr.hpte_data.destination_address,
+ phdr.hpte_data.length_copied,
+ phdr.kernel_data.destination_address,
+ phdr.kernel_data.length_copied,
+ phyp_dump_info-init_reserve_start,
+ second_addr_range);
+}
+
static struct kobj_attribute rr = __ATTR(release_region, 0600,
-NULL, store_release_region);
+ show_release_region,
+ store_release_region);
static int __init phyp_dump_setup(void)
{
@@ -313,6 +368,22 @@ static int __init phyp_dump_setup(void)
return 0;
}
+ /* re-register the dump area, if old dump was invalid */
+ if ((dump_header) (dump_header-status DUMP_ERROR_FLAG)) {
+ invalidate_last_dump(phdr, dump_area_start);
+ register_dump_area(phdr, dump_area_start);
+ return 0;
+ }
+
+ if
[PATCH 7/8] pseries: phyp dump: Tracking memory range freed.
This patch tracks the size freed. For now it does a simple
rudimentary calculation of the ranges freed. The idea is
to keep it simple at the external shell script level and
send in large chunks for now.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/phyp_dump.c | 35 +
1 file changed, 35 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
22:14:00.0 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-21
22:14:05.0 -0500
@@ -261,6 +261,39 @@ static void release_memory_range(unsigne
}
}
+/**
+ * track_freed_range -- Counts the range being freed.
+ * Once the counter goes to zero, it re-registers dump for
+ * future use.
+ */
+static void
+track_freed_range(unsigned long addr, unsigned long length)
+{
+ static unsigned long scratch_area_size, reserved_area_size;
+
+ if (addr phyp_dump_info-init_reserve_start)
+ return;
+
+ if ((addr = phyp_dump_info-init_reserve_start)
+ (addr = phyp_dump_info-init_reserve_start +
+phyp_dump_info-init_reserve_size))
+ reserved_area_size += length;
+
+ if ((addr = phyp_dump_info-reserved_scratch_addr)
+ (addr = phyp_dump_info-reserved_scratch_addr +
+phyp_dump_info-reserved_scratch_size))
+ scratch_area_size += length;
+
+ if ((reserved_area_size == phyp_dump_info-init_reserve_size)
+ (scratch_area_size == phyp_dump_info-reserved_scratch_size)) {
+
+ invalidate_last_dump(phdr,
+ phyp_dump_info-reserved_scratch_addr);
+ register_dump_area(phdr,
+ phyp_dump_info-reserved_scratch_addr);
+ }
+}
+
/* - */
/**
* sysfs_release_region -- sysfs interface to release memory range.
@@ -285,6 +318,8 @@ static ssize_t store_release_region(stru
if (ret != 2)
return -EINVAL;
+ track_freed_range(start_addr, length);
+
/* Range-check - don't free any reserved memory that
* wasn't reserved for phyp-dump */
if (start_addr phyp_dump_info-init_reserve_start)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] pseries: phyp dump: config file
Add hypervisor-assisted dump to kernel config Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Signed-off-by: Manish Ahuja [EMAIL PROTECTED] --- arch/powerpc/Kconfig | 10 ++ 1 file changed, 10 insertions(+) Index: 2.6.25-rc1/arch/powerpc/Kconfig === --- 2.6.25-rc1.orig/arch/powerpc/Kconfig2008-03-20 20:53:33.0 -0500 +++ 2.6.25-rc1/arch/powerpc/Kconfig 2008-03-20 21:06:29.0 -0500 @@ -306,6 +306,16 @@ config CRASH_DUMP Don't change this unless you know what you are doing. +config PHYP_DUMP + bool Hypervisor-assisted dump (EXPERIMENTAL) + depends on PPC_PSERIES EXPERIMENTAL + help + Hypervisor-assisted dump is meant to be a kdump replacement + offering robustness and speed not possible without system + hypervisor assistence. + + If unsure, say N + config PPCBUG_NVRAM bool Enable reading PPCBUG NVRAM during boot if PPLUS || LOPEC default y if PPC_PREP ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] pseries: phyp dump: Disable phyp-dump through boot-var.
The goal of these 2 patches is to ensure that there is only one dumping
mechanism enabled at any given time. These patches depend upon phyp-dump
patches posted earlier.
Patch 1:
Addition of boot-variable phyp_dump, which takes values [0/1] for disabling/
enabling phyp_dump at boot time. Kdump can use this on cmdline (phyp_dump=0)
to disable phyp-dump during boot when enabling itself. This will ensure only
one dumping mechanism is active at any given time.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
---
arch/powerpc/kernel/prom.c |5 +
arch/powerpc/platforms/pseries/phyp_dump.c | 18 ++
include/asm-powerpc/phyp_dump.h|1 +
3 files changed, 24 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22
00:42:02.0 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22
01:07:43.0 -0500
@@ -460,3 +460,21 @@ int __init early_init_dt_scan_phyp_dump(
*((unsigned long *)sizes[4]);
return 1;
}
+
+/* Look for phyp_dump= cmdline option */
+static int __init early_phyp_dump_enabled(char *p)
+{
+ phyp_dump_info-phyp_dump_at_boot = 1;
+
+if (!p)
+return 0;
+
+if (strncmp(p, 1, 1) == 0)
+ phyp_dump_info-phyp_dump_at_boot = 1;
+else if (strncmp(p, 0, 1) == 0)
+ phyp_dump_info-phyp_dump_at_boot = 0;
+
+return 0;
+}
+early_param(phyp_dump, early_phyp_dump_enabled);
+
Index: 2.6.25-rc1/include/asm-powerpc/phyp_dump.h
===
--- 2.6.25-rc1.orig/include/asm-powerpc/phyp_dump.h 2008-03-22
00:42:02.0 -0500
+++ 2.6.25-rc1/include/asm-powerpc/phyp_dump.h 2008-03-22 00:42:08.0
-0500
@@ -25,6 +25,7 @@ struct phyp_dump {
unsigned long init_reserve_start;
unsigned long init_reserve_size;
/* Check status during boot if dump supported, active present*/
+ unsigned long phyp_dump_at_boot;
unsigned long phyp_dump_configured;
unsigned long phyp_dump_is_active;
/* store cpu hpte size */
Index: 2.6.25-rc1/arch/powerpc/kernel/prom.c
===
--- 2.6.25-rc1.orig/arch/powerpc/kernel/prom.c 2008-03-22 00:42:02.0
-0500
+++ 2.6.25-rc1/arch/powerpc/kernel/prom.c 2008-03-22 00:42:54.0
-0500
@@ -1059,6 +1059,11 @@ static void __init phyp_dump_reserve_mem
return;
}
+ if (!phyp_dump_info-phyp_dump_at_boot) {
+ printk(KERN_INFO Phyp-dump disabled at boot time\n);
+ return;
+ }
+
if (phyp_dump_info-phyp_dump_is_active) {
/* Reserve *everything* above RMR.Area freed by userland tools*/
base = PHYP_DUMP_RMR_END;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] pseries: phyp dump: inform kdump, phyp-dump is loaded.
Patch 2:
Addition of /sys/kernel/phyp_dump_active so that kdump init scripts may
look for it and take appropriate action if this file is found. This
file is only loaded when phyp_dump has been registered.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/phyp_dump.c | 18 ++
1 file changed, 18 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22
01:07:43.0 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22
01:08:56.0 -0500
@@ -182,6 +182,18 @@ static void print_dump_header(const stru
#endif
}
+static ssize_t show_phyp_dump_active(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+
+ /* create filesystem entry so kdump is phyp-dump aware */
+ return sprintf(buf, %lx\n, phyp_dump_info-phyp_dump_at_boot);
+}
+
+static struct kobj_attribute pdl = __ATTR(phyp_dump_active, 0600,
+ show_phyp_dump_active,
+ NULL);
+
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
@@ -204,7 +216,13 @@ static void register_dump_area(struct ph
printk(KERN_ERR phyp-dump: unexpected error (%d) on
register\n, rc);
print_dump_header(ph);
+ return;
}
+
+ rc = sysfs_create_file(kernel_kobj, pdl.attr);
+ if (rc)
+ printk(KERN_ERR phyp-dump: unable to create sysfs
+file (%d)\n, rc);
}
static
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
Bartlomiej Sieka wrote:
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with few
other updates, in particluar one posted by Anatolij Gustschin, which fixes
an Oops during boot.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
Anatolij, would you like to add your S-O-B?
Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..8b2e8e4 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -159,6 +159,7 @@
};
[EMAIL PROTECTED] {
+ device_type = dma-controller;
compatible =
fsl,mpc5200b-bestcomm,fsl,mpc5200-bestcomm;
reg = 1200 80;
interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
@@ -212,13 +213,31 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
+ compatible = fsl,mpc5200b-mdio;
+ reg = 3000 400; // fec range, since we need to
setup fec interrupts
+ interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
};
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible =
fsl,mpc5200b-i2c,fsl,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
@@ -231,4 +250,22 @@
reg = 8000 4000;
};
};
+
+ lpb {
+ model = fsl,lpb;
+ compatible = fsl,lpb;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 fc00 200;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 200;
+ bank-width = 2;
+ device-width = 2;
+ #size-cells = 1;
+ #address-cells = 1;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..9ca81ff 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -127,6 +127,13 @@
interrupt-parent = mpc5200_pic;
};
+ [EMAIL PROTECTED] {
+ compatible = mpc5200b-mscan\0mpc5200-mscan;
+ interrupts = 2 11 0;
+ interrupt-parent = mpc5200_pic;
+ reg = 900 80;
+ };
+
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-mscan,fsl,mpc5200-mscan;
interrupts = 2 12 0;
@@ -148,7 +155,6 @@
interrupt-parent = mpc5200_pic;
};
-
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-spi,fsl,mpc5200-spi;
reg = f00 20;
@@ -164,6 +170,7 @@
};
[EMAIL PROTECTED] {
+ device_type = dma-controller;
compatible =
fsl,mpc5200b-bestcomm,fsl,mpc5200-bestcomm;
reg = 1200 80;
interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
@@ -209,10 +216,26 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
+ compatible = fsl,mpc5200b-mdio;
+ reg =
Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts
On Fri, 21 Mar 2008 18:28:38 +0100 Segher Boessenkool [EMAIL PROTECTED] wrote: As for the DTS, maybe a compatible property in the CPU might make some sense with a content along the lines of ppc440x6 or whatever rev of the 440 core it is. What do you think ? Good idea. I'll try to come up with a list for all existing 4xx SoC's and it's core versions. I don't really care either way, but what does that buy us? Merely documentation? Obviously, as long as the kernel doesn't use the device tree for probing the CPUs available, additions to the device tree here don't affect the kernel at all ;-P Yes, of course. I meant were there other plans for it. Ben and I had a brief discussion of some of the possible uses and it seems pretty sane. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
On Fri, Mar 21, 2008 at 5:56 PM, Bartlomiej Sieka [EMAIL PROTECTED] wrote:
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with few
other updates, in particluar one posted by Anatolij Gustschin, which fixes
an Oops during boot.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
Comments below.
---
Anatolij, would you like to add your S-O-B?
diff --git a/arch/powerpc/boot/dts/cm5200.dts
b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..8b2e8e4 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -159,6 +159,7 @@
};
[EMAIL PROTECTED] {
+ device_type = dma-controller;
compatible =
fsl,mpc5200b-bestcomm,fsl,mpc5200-bestcomm;
reg = 1200 80;
interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
@@ -212,13 +213,31 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
Drop device type; it's unneeded and unused.
+ compatible = fsl,mpc5200b-mdio;
Should technically be fsl,mpc5200b-mdio, fsl,mpc5200-mdio; (I
know the lite5200b.dts doesn't have this either, but I'll write a
patch right now to fix it so that it's correct in .25)
I regret introducing fsl,mpc5200b-* at all since the 5200b is really
just a bug fix of the 5200 except for a very few incompatible device
changes. Just the nodes for specific incompatible devices need to
claim 5200b-blah in their compatible string (without claiming
5200-blah). It seems to me that specific silicon revision
differences by conventional is too fine grained for the compatible
field and if really needed can be discovered from the SVR.
I may even drop it in the .26 series. All device trees in the wild
claim compatibility with both so it won't break any existing boards.
heh; I guess that's just a long winded way to say make sure
fsl,mpc5200-mdio is in there so it remains possible to drop
mpc5200b-mdio in the future.
+ reg = 3000 400; // fec range, since we need
to setup fec interrupts
+ interrupts = 2 5 0; // these are for mii
command finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
};
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
inconsistent indentation?
compatible =
fsl,mpc5200b-i2c,fsl,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
@@ -231,4 +250,22 @@
reg = 8000 4000;
};
};
+
+ lpb {
+ model = fsl,lpb;
+ compatible = fsl,lpb;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 fc00 200;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 200;
+ bank-width = 2;
+ device-width = 2;
+ #size-cells = 1;
+ #address-cells = 1;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..9ca81ff 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -127,6 +127,13 @@
interrupt-parent = mpc5200_pic;
};
+ [EMAIL PROTECTED] {
+ compatible = mpc5200b-mscan\0mpc5200-mscan;
mpc5200b-mscan, mpc5200-mscan; The '\0' is depreciated.
+ interrupts = 2 11 0;
+ interrupt-parent = mpc5200_pic;
+ reg = 900 80;
+ };
+
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-mscan,fsl,mpc5200-mscan;
interrupts = 2 12 0;
@@ -148,7 +155,6 @@
[PATCH] [POWERPC] mpc5200-fec: Fix possible NULL dereference in mdio driver
If the reg property is missing from the phy node (unlikely, but possible),
then the kernel will oops with a NULL pointer dereference.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
This one is a bugfix that should go in for 2.6.25. Paul, can you please
pick it up?
Thanks,
g.
drivers/net/fec_mpc52xx_phy.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 1837584..6a3ac4e 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -109,7 +109,8 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
const struct of_device_i
int irq = irq_of_parse_and_map(child, 0);
if (irq != NO_IRQ) {
const u32 *id = of_get_property(child, reg, NULL);
- bus-irq[*id] = irq;
+ if (id)
+ bus-irq[*id] = irq;
}
}
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] mpc5200: fix incorrect compatible string for the mdio node
The MDIO node in the lite5200b.dts file needs to also claim compatibility
with the older mpc5200 chip.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Paul, this one should also go in for .26
arch/powerpc/boot/dts/lite5200b.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200b.dts
b/arch/powerpc/boot/dts/lite5200b.dts
index 30eaeab..001c955 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -270,7 +270,7 @@
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
- compatible = fsl,mpc5200b-mdio;
+ compatible = fsl,mpc5200b-mdio, fsl,mpc5200-mdio;
reg = 0x3000 0x400; // fec range, since we need to
setup fec interrupts
interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
interrupt-parent = mpc5200_pic;
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] mpc5200: fix null dereference if bestcomm fails to initialize
If the bestcomm initialization fails, calls to the task allocate function should fail gracefully instead of oopsing with a NULL deref. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- Paul, here's another bug fix that I'd like picked up for .25 arch/powerpc/sysdev/bestcomm/bestcomm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c b/arch/powerpc/sysdev/bestcomm/bestcomm.c index f58..f9cd04e 100644 --- a/arch/powerpc/sysdev/bestcomm/bestcomm.c +++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c @@ -52,6 +52,10 @@ bcom_task_alloc(int bd_count, int bd_size, int priv_size) int i, tasknum = -1; struct bcom_task *tsk; + /* Don't try to do anything is bestcomm init failed */ + if (!bcom_eng) + return NULL; + /* Get and reserve a task num */ spin_lock(bcom_eng-lock); -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
On Sat, Mar 22, 2008 at 12:56:35AM +0100, Bartlomiej Sieka wrote:
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with few
other updates, in particluar one posted by Anatolij Gustschin, which fixes
an Oops during boot.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
Anatolij, would you like to add your S-O-B?
diff --git a/arch/powerpc/boot/dts/cm5200.dts
b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..8b2e8e4 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -159,6 +159,7 @@
};
[EMAIL PROTECTED] {
+ device_type = dma-controller;
This is not right. If adding device_type here fixes something, then
the driver is wrong and should be fixed instead.
[snip]
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ device_type = mdio;
Likewise device_type should not appear here.
[snip]
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
Looks like incorrect indentation here.
[snip]
+ [EMAIL PROTECTED] {
+ compatible = mpc5200b-mscan\0mpc5200-mscan;
Use mpc5200b-mscan, mpc5200-mscan instead of the embedded \0.
[snip]
[EMAIL PROTECTED] {
+ device_type = dma-controller;
As above.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
On Fri, Mar 21, 2008 at 6:12 PM, David Gibson
[EMAIL PROTECTED] wrote:
On Sat, Mar 22, 2008 at 12:56:35AM +0100, Bartlomiej Sieka wrote:
diff --git a/arch/powerpc/boot/dts/cm5200.dts
b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..8b2e8e4 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -159,6 +159,7 @@
};
[EMAIL PROTECTED] {
+ device_type = dma-controller;
This is not right. If adding device_type here fixes something, then
the driver is wrong and should be fixed instead.
I just sent a patch that fixes the driver bug.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
