- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 18 3月, 2010 1 次提交
-
-
由 Grant Likely 提交于
mpc52xx_gpt_wdt_setup is defined as 0, which causes the following build failure with gcc 4.5, since it's built with -Werror. arch/powerpc/platforms/52xx/mpc52xx_gpt.c:761:3: error: statement with no effect Changing it to a static inline fixes the problem. Reported-by: NJeff Mahoney <jeffm@suse.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 09 3月, 2010 6 次提交
-
-
由 Vaidyanathan Srinivasan 提交于
Remove debug printks in pseries_mach_cpu_die(). These are noisy at runtime. Traceevents can be added to instrument this section of code. The following KERN_INFO printks are removed: cpu 62 (hwid 62) returned from cede. Decrementer value = b2802fff Timebase value = 2fa8f95035f4a cpu 62 (hwid 62) got prodded to go online cpu 58 (hwid 58) ceding for offline with hint 2 Signed-off-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Cc: Gautham R Shenoy <ego@in.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Vaidyanathan Srinivasan 提交于
Rearrange condition checks for better code readability and prevention of possible race conditions when preferred_offline_state can potentially change during the execution of pseries_mach_cpu_die(). The patch will make pseries_mach_cpu_die() put cpu in one of the consistent states and not hit the run over BUG() Signed-off-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Cc: Gautham R Shenoy <ego@in.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Vaidyanathan Srinivasan 提交于
Cpu hotplug (offline) without dlpar operation will place cpu in cede state and the extended_cede_processor() function will return when resumed. Kernel stack pointer needs to be reset before start_secondary() is called to continue the online operation. Added new function start_secondary_resume() to do the above steps. Signed-off-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Cc: Gautham R Shenoy <ego@in.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Mark Nelson 提交于
Now that we properly keep track of the CPPR value (since 49bd3647, "powerpc/pseries: Track previous CPPR values to correctly EOI interrupts") we can pass it to the H_XIRR hcall. This is needed because the Partition Adjunct Option of new versions of pHyp extend the H_XIRR hcall to include the CPPR as an input parameter. Earlier versions not supporting this option just disregard the extra input parameter, so this doesn't cause any problems for existing systems. The Partition Adjunct Option is required for future systems that will support SR-IOV capable devices. Signed-off-by: NMark Nelson <markn@au1.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Adam Lackorzynski 提交于
Compiling 2.6.33 with SMP enabled and HOTPLUG_CPU disabled gives me the following link errors: LD init/built-in.o LD .tmp_vmlinux1 arch/powerpc/platforms/built-in.o: In function `.smp_xics_setup_cpu': smp.c:(.devinit.text+0x88): undefined reference to `.set_cpu_current_state' smp.c:(.devinit.text+0x94): undefined reference to `.set_default_offline_state' arch/powerpc/platforms/built-in.o: In function `.smp_pSeries_kick_cpu': smp.c:(.devinit.text+0x13c): undefined reference to `.set_preferred_offline_state' smp.c:(.devinit.text+0x148): undefined reference to `.get_cpu_current_state' smp.c:(.devinit.text+0x1a8): undefined reference to `.get_cpu_current_state' make: *** [.tmp_vmlinux1] Error 1 The following change fixes that for me and seems to work as expected. Signed-off-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
On 64-bit kernels we currently have a 512 byte struct paca_struct for each cpu (usually just called "the paca"). Currently they are statically allocated, which means a kernel built for a large number of cpus will waste a lot of space if it's booted on a machine with few cpus. We can avoid that by only allocating the number of pacas we need at boot. However this is complicated by the fact that we need to access the paca before we know how many cpus there are in the system. The solution is to dynamically allocate enough space for NR_CPUS pacas, but then later in boot when we know how many cpus we have, we free any unused pacas. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 07 3月, 2010 1 次提交
-
-
由 Wim Van Sebroeck 提交于
make the watchdog_info struct const where possible. Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
-
- 05 3月, 2010 5 次提交
-
-
由 Scott Wood 提交于
This implements perf_event support for the Freescale embedded performance monitor, based on the existing perf_event.c that supports server/classic chips. Some limitations: - Performance monitor interrupts are regular EE interrupts, and thus you can't profile places with interrupts disabled. We may want to implement soft IRQ-disabling, with perfmon interrupts exempted and treated as NMIs. - When trying to schedule multiple event groups at once, and using restricted events, situations could arise where scheduling fails even though it would be possible. Consider three groups, each with two events. One group has restricted events, the others don't. The two non-restricted groups are scheduled, then one is removed, which happens to occupy the two counters that can't do restricted events. The remaining non-restricted group will not be moved to the non-restricted-capable counters to make room if the restricted group tries to be scheduled. Signed-off-by: NScott Wood <scottwood@freescale.com> Acked-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Martyn Welch 提交于
This patch renames GE Fanuc boards following the split-up of the GE Fanuc joint venture. These boards are now made by GE Intelligent platorms. Signed-off-by: NMartyn Welch <martyn.welch@gefanuc.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Anton Vorontsov 提交于
Interrupt controllers' hooks are executed in the atomic context, so they are not permitted to sleep (with RT kernels non-raw spinlocks are sleepable). So, gef_pic_lock has to be a real (non-sleepable) spinlock. Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Anton Vorontsov 提交于
Interrupt controllers' hooks are executed in the atomic context, so they are not permitted to sleep (with RT kernels non-raw spinlocks are sleepable). So, pci_pic_lock has to be a real (non-sleepable) spinlock. Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Anton Vorontsov 提交于
Interrupt controllers' hooks are executed in the atomic context, so they are not permitted to sleep (with RT kernels non-raw spinlocks are sleepable). So, socrates_fpga_pic_lock has to be a real (non-sleepable) spinlock. Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 24 2月, 2010 1 次提交
-
-
由 Bjorn Helgaas 提交于
No functional change; this converts loops that iterate from 0 to PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the pci_bus_for_each_resource() iterator instead. This doesn't change the way resources are stored; it merely removes dependencies on the fact that they're in a table. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 19 2月, 2010 6 次提交
-
-
由 Thomas Gleixner 提交于
pmac_pic_lock needs to be a real spinlock in RT. Convert it to raw_spinlock. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Thomas Gleixner 提交于
feature_lock needs to be a real spinlock in RT. Convert it to raw_spinlock. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Thomas Gleixner 提交于
beat_htab_lock needs to be a real spinlock in RT. Convert it to raw_spinlock. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Thomas Gleixner 提交于
confirm_error_lock needs to be a real spinlock in RT. Convert it to raw_spinlock. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Thomas Gleixner 提交于
beatic_irq_mask_lock needs to be a real spinlock in RT. Convert it to raw_spinlock. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Thomas Gleixner 提交于
nv_lock needs to be a real spinlock in RT. Convert it to raw_spinlock. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 18 2月, 2010 1 次提交
-
-
由 Anton Vorontsov 提交于
This patch adds NOR Flash, LEDs and PIB support for MPC8568E-MDS boards. Plus, move bcsr node into localbus node, and add bcsr5 gpio-controller node. Some platform code modifications were also needed. Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 17 2月, 2010 6 次提交
-
-
由 Anton Blanchard 提交于
Now we use printf style alignment there is no need to manually space these fields. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
Right now we allocate a cacheline sized NR_CPUS array for xics IPI communication. Use DECLARE_PER_CPU_SHARED_ALIGNED to put it in percpu data in its own cacheline since it is written to by other cpus. On a kernel with NR_CPUS=1024, this saves quite a lot of memory: text data bss dec hex filename 8767779 2944260 1505724 13217763 c9afe3 vmlinux.irq_cpustat 8767555 2813444 1505724 13086723 c7b003 vmlinux.xics A saving of around 128kB. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Breno Leitao 提交于
During a EEH recover, the pci_dev structure can be null, mainly if an eeh event is detected during cpi config operation. In this case, the pci_dev will not be known (and will be null) the kernel will crash with the following message: Unable to handle kernel paging request for data at address 0x000000a0 Faulting instruction address: 0xc00000000006b8b4 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c00000000006b8b4] .eeh_event_handler+0x10c/0x1a0 LR [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0 Call Trace: [c0000003a80dff00] [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0 [c0000003a80dff90] [c000000000031f1c] .kernel_thread+0x54/0x70 The bug occurs because pci_name() tries to access a null pointer. This patch just guarantee that pci_name() is not called on Null pointers. Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: NLinas Vepstas <linasvepstas@gmail.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anatolij Gustschin 提交于
Instantiate NAND Flash Controller device if it's description is found in the device tree. Signed-off-by: NAnatolij Gustschin <agust@denx.de> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Anatolij Gustschin 提交于
Add reset module registers representation and machine restart callback for mpc5121 platform. Signed-off-by: NPiotr Ziecik <kosmo@semihalf.com> Signed-off-by: NWolfgang Denk <wd@denx.de> Signed-off-by: NAnatolij Gustschin <agust@denx.de> Reviewed-by: NWolfram Sang <w.sang@pengutronix.de> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Anatolij Gustschin 提交于
Move mpc5121_clk_init() call to platform init code so it won't get called on non-5121 platforms on a multiplatform kernel. Signed-off-by: NAnatolij Gustschin <agust@denx.de> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 14 2月, 2010 2 次提交
-
-
由 Peter Tyser 提交于
Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused the "cpu-release-addr" device tree property to contain the physical RAM location that secondary cores were spinning at. Previously, the "cpu-release-addr" property contained a value referencing the boot page translation address range of 0xfffffxxx, which then indirectly accessed RAM. The "cpu-release-addr" is currently ioremapped and the secondary cores kicked. However, due to the recent change in "cpu-release-addr", it sometimes points to a memory location in low memory that cannot be ioremapped. For example on a P2020-based board with 512MB of RAM the following error occurs on bootup: <...> mpic: requesting IPIs ... __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0 Unable to handle kernel paging request for data at address 0x00000014 Faulting instruction address: 0xc05df9b0 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 P2020 RDB Modules linked in: <... eventual kernel panic> Adding logic to conditionally ioremap or access memory directly resolves the issue. Signed-off-by: NPeter Tyser <ptyser@xes-inc.com> Signed-off-by: NNate Case <ncase@xes-inc.com> Reported-by: NDipen Dudhat <B09055@freescale.com> Tested-by: NDipen Dudhat <B09055@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Anton Vorontsov 提交于
MPC85xx chips report the wrong value in feature reporting register, and that causes the following oops: Unable to handle kernel paging request for data at address 0x00000c00 Faulting instruction address: 0xc0019294 Oops: Kernel access of bad area, sig: 11 [#1] MPC8569 MDS Modules linked in: [...] NIP [c0019294] mpic_set_irq_type+0x2f0/0x368 LR [c0019124] mpic_set_irq_type+0x180/0x368 Call Trace: [ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable) [ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4 [ef851db0] [c007b550] set_irq_type+0x40/0x7c [ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114 [ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40 [ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328 [ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84 [...] This is because mpic_alloc() assigns wrong values to mpic->isu_{size,shift,mask}, and things eventually break when _mpic_irq_read() is trying to use them. This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk. Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 09 2月, 2010 5 次提交
-
-
由 Grant Likely 提交于
machine is compatible is an OF-specific call. It should have the of_ prefix to protect the global namespace. Signed-off-by: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NMichal Simek <monstr@monstr.eu>
-
由 Frans Pop 提交于
Signed-off-by: NFrans Pop <elendil@planet.nl> Cc: linuxppc-dev@ozlabs.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
The cede latency stuff is relatively new and we don't need to complain about it not working on older firmware. Signed-off-by: NAnton Blanchard <anton@samba.org> Acked-by: NBalbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Joe Perches 提交于
String constants that are continued on subsequent lines with \ are not good. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Will Schmidt 提交于
The tb_total and purr_total values reported via the hcall_stats code should be cumulative, rather than being replaced by the latest delta tb or purr value. Tested-by: NWill Schmidt <will_schmidt@vnet.ibm.com> Signed-off-by: NWill Schmidt <will_schmidt@vnet.ibm.com> Acked-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 08 2月, 2010 1 次提交
-
-
由 Mark Nelson 提交于
The code to track the CPPR values added by commit 49bd3647 ("powerpc/pseries: Track previous CPPR values to correctly EOI interrupts") broke kexec on pseries because the kexec code in xics.c calls xics_set_cpu_priority() before the IPI has been EOI'ed. This wasn't a problem previously but it now triggers a BUG_ON in xics_set_cpu_priority() because os_cppr->index isn't 0. Fix this problem by setting the index on the CPPR stack to 0 before calling xics_set_cpu_priority() in xics_teardown_cpu(). Also make it clear that we only want to set the priority when there's just one CPPR value in the stack, and enforce it by updating the value of os_cppr->stack[0] rather than os_cppr->stack[os_cppr->index]. While we're at it change the BUG_ON to a WARN_ON. Reported-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NMark Nelson <markn@au1.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 03 2月, 2010 1 次提交
-
-
由 Peter Tyser 提交于
Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused the "cpu-release-addr" device tree property to contain the physical RAM location that secondary cores were spinning at. Previously, the "cpu-release-addr" property contained a value referencing the boot page translation address range of 0xfffffxxx, which then indirectly accessed RAM. The "cpu-release-addr" is currently ioremapped and the secondary cores kicked. However, due to the recent change in "cpu-release-addr", it sometimes points to a memory location in low memory that cannot be ioremapped. For example on a P2020-based board with 512MB of RAM the following error occurs on bootup: <...> mpic: requesting IPIs ... __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0 Unable to handle kernel paging request for data at address 0x00000014 Faulting instruction address: 0xc05df9b0 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 P2020 RDB Modules linked in: <... eventual kernel panic> Adding logic to conditionally ioremap or access memory directly resolves the issue. Signed-off-by: NPeter Tyser <ptyser@xes-inc.com> Signed-off-by: NNate Case <ncase@xes-inc.com> Reported-by: NDipen Dudhat <B09055@freescale.com> Tested-by: NDipen Dudhat <B09055@freescale.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 01 2月, 2010 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
desc->affinity doesn't exit in that case. Let's use a macro for the UP variant of get_irq_server(), it's the easiest way, avoids evaluating arguments. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 29 1月, 2010 1 次提交
-
-
由 Grant Likely 提交于
In struct device_node, the phandle is named 'linux_phandle' for PowerPC and MicroBlaze, and 'node' for SPARC. There is no good reason for the difference, it is just an artifact of the code diverging over a couple of years. This patch renames both to simply .phandle. Note: the .node also existed in PowerPC/MicroBlaze, but the only user seems to be arch/powerpc/platforms/powermac/pfunc_core.c. It doesn't look like the assignment between .linux_phandle and .node is significantly different enough to warrant the separate code paths unless ibm,phandle properties actually appear in Apple device trees. I think it is safe to eliminate the old .node property and use phandle everywhere. Signed-off-by: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NDavid S. Miller <davem@davemloft.net> Tested-by: NWolfram Sang <w.sang@pengutronix.de> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 21 1月, 2010 1 次提交
-
-
由 Liu Yu-B13201 提交于
Signed-off-by: NLiu Yu <yu.liu@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-