- 21 11月, 2007 1 次提交
-
-
由 Kim Phillips 提交于
Now the rtc class ds1374 driver has been added, remove the old rtc driver hookup code, add rtc node to device trees, and turn on the new driver in the defconfigs. Signed-off-by: NKim Phillips <kim.phillips@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 20 11月, 2007 12 次提交
-
-
由 Benjamin Herrenschmidt 提交于
My changes to _tlbie to fix 4xx unfortunately broke 8xx build in a couple of places. This fixes it. Spotted by Olof Johansson. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NVitaly Bordug <vitb@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Kumar Gala 提交于
The interrupt map for the PCI PHB that had the ULI1575 was not correct on the boards that have it. * 8544 DS: - Fix interrupt mask - Be explicit about use of INTA for on chip peripherals * 8572 DS/8641 HPCN: - Fix interrupt mask - Expand interrupt map for PCI slots to cover all functions - Be explicit about use of INTA for on chip peripherals Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Michael Neuling 提交于
If we get no user time and no system time allocated since the last account_system_vtime, the system to user time ratio estimate can end up dividing by zero. This was causing a problem noticed by Balbir Singh. Signed-off-by: NMichael Neuling <mikey@neuling.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Jeremy Kerr 提交于
We can currently cause an oops by repeatedly creating and destroying contexts, while doing getdents() calls on the "/spu" directory. This is due to the context's top-level dentry remaining hashed while the context is being destroyed. Fix this by unhashing the context's dentry with the dentry->d_inode->i_mutex held. This way, we'll hit the check for d_unhashed in dentry_readdir, and won't be included in the list of subdirs for /spu. test: spufs-testsuite:tests/01-spu_create/07-destroy-vs-readdir-race Signed-off-by: NJeremy Kerr <jk@ozlabs.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
The rtas_os_term() routine was being called at the wrong time. The actual rtas call "os-term" will not ever return, and so calling it from the panic notifier is too early. Instead, call it from the machine_reset() call. This splits the rtas_os_term() routine into two: one part to capture the kernel panic message, invoked during the panic notifier, and another part that is invoked during machine_reset(). Prior to this patch, the os-term call was never being made, because panic_timeout was always non-zero. Calling os-term helps keep the hypervisor happy! We have to keep the hypervisor happy to avoid service, dump and error reporting problems. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Kim Phillips 提交于
If on a rev. 2.1, adjust UCC clock and data timing characteristics as specified in the rev.2.1 erratum #2. Signed-off-by: NKim Phillips <kim.phillips@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Kim Phillips 提交于
correct the reg property, remove duplicate io port entry, whitespace fixes. Thanks to Peter Van Ackeren for pointing this out. Signed-off-by: NKim Phillips <kim.phillips@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Kim Phillips 提交于
currently the board-level PHY reset code for the mpc832x MDS messes with reset configuration words source settings which is plain wrong (it looks like this board code was cut-n-pasted from the mpc8360 mds code, which has the PHY reset bits in a different BCSR); this patch points the PHY reset code to the proper mpc832x mds PHY reset bits in the BCSR. Signed-off-by: NPeter Van Ackeren <peter.vanackeren@freescale.com> Signed-off-by: NKim Phillips <kim.phillips@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Cyrill Gorcunov 提交于
This patch does fix potential NULL pointer dereference that could take place inside of strcmp() if of_get_property() call failed. Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Olof Johansson 提交于
The current VDSO implementation is hardcoded to 128 byte cache blocks, which are only used on IBM's 64-bit processors. Convert it to get the cache block sizes out of vdso_data instead, similar to how the ppc64 in-kernel cache flush does it. Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Olof Johansson 提交于
Due to an erratum, we don't want to reset the mpic at boot time. It can sometimes cause problems with lost interrupts later on while running. Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Kamalesh Babulal 提交于
Include <asm/iseries/hv_call.h> in arch/powerpc/mm/stab.c to fix the following compile error (found with randconfig): CC arch/powerpc/mm/stab.o arch/powerpc/mm/stab.c: In function "stab_initialize": arch/powerpc/mm/stab.c:282: error: implicit declaration of function "HvCall1" arch/powerpc/mm/stab.c:282: error: "HvCallBaseSetASR" undeclared (first use in this function) arch/powerpc/mm/stab.c:282: error: (Each undeclared identifier is reported only once arch/powerpc/mm/stab.c:282: error: for each function it appears in.) make[1]: *** [arch/powerpc/mm/stab.o] Error 1 make: *** [arch/powerpc/mm] Error 2 Signed-off-by: NKamalesh Babulal <kamalesh@linux.vnet.ibm.com> Acked-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 19 11月, 2007 8 次提交
-
-
由 Josh Boyer 提交于
This fixes arch/ppc 440EP platforms to setup the FPU correctly. A virtual PVR is used, as 440GR platforms share an identical hardware PVR value and do not have an FPU. Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
-
由 Valentine Barshak 提交于
This adds uic_mask_ack_irq() callback to PowerPC 4xx uic code to avoid kernel crash. It is used for edge-triggered interrupts by handle_uic_irq(). Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
-
由 Roel Kluin 提交于
Call iounmap before returning from an error case. Signed-off-by: NRoel Kluin <12o3l@tiscali.nl> Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
-
由 Joachim Foerster 提交于
Add AC97 platform bus registration for Xilinx Virtex platforms. Signed-off-by: NJoachim Foerster <JOFT@gmx.de> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca> Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
-
由 Jon Loeliger 提交于
Signed-off-by: NJon Loeliger <jdl@freescale.com> Acked-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
-
由 Mark A. Greer 提交于
Turn on the L2 cache on the prpmc2800 platform. Signed-off-by: Mark A. Greer <mgreer@mvista.com Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stephen Rothwell 提交于
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Nathan Lynch 提交于
There are several issues with the rtas_ibm_suspend_me code, which enables platform-assisted suspension of an LPAR as covered in PAPR 2.2. 1.) rtas_ibm_suspend_me uses on_each_cpu() to invoke rtas_percpu_suspend_me on all cpus via IPI: if (on_each_cpu(rtas_percpu_suspend_me, &data, 1, 0)) ... 'data' is on the calling task's stack, but rtas_ibm_suspend_me takes no measures to ensure that all instances of rtas_percpu_suspend_me are finished accessing 'data' before returning. This can result in the IPI'd cpus accessing random stack data and getting stuck in H_JOIN. This is addressed by using an atomic count of workers and a completion on the stack. 2.) rtas_percpu_suspend_me is needlessly calling H_JOIN in a loop. The only event that can cause a cpu to return from H_JOIN is an H_PROD from another cpu or a NMI/system reset. Each cpu need call H_JOIN only once per suspend operation. Remove the loop and the now unnecessary 'waiting' state variable. 3.) H_JOIN must be called with MSR[EE] off, but lazy interrupt disabling may cause the caller of rtas_ibm_suspend_me to call H_JOIN with it on; the local_irq_disable() in on_each_cpu() is not sufficient. Fix this by explicitly saving the MSR and clearing the EE bit before calling H_JOIN. 4.) H_PROD is being called with the Linux logical cpu number as the parameter, not the platform interrupt server value. (It's also being called for all possible cpus, which is harmless, but unnecessary.) This is fixed by calling H_PROD for each online cpu using get_hard_smp_processor_id(cpu) for the argument. Signed-off-by: NNathan Lynch <ntl@pobox.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 18 11月, 2007 2 次提交
-
-
由 Sam Ravnborg 提交于
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: - 0f855aa6 ("kconfig: add helper to set config symbol from environment variable") - 2a113281 ("kconfig: use $K64BIT to set 64BIT with all*config targets") Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Herrmann <aherrman@arcor.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Sam Ravnborg 提交于
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: 0f855aa6 -> kconfig: add helper to set config symbol from environment variable 2a113281 -> kconfig: use $K64BIT to set 64BIT with all*config targets Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Herrmann <aherrman@arcor.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
- 17 11月, 2007 12 次提交
-
-
由 Denys 提交于
Needed to make the wireless board, WRAP2C reboot. Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Yinghai Lu 提交于
need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so info->bus->resource[info->res_num] = res will not beyond of bus resource array when acpi returns too many resource entries. Signed-off-by: NYinghai Lu <yinghai.lu@sun.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Gary Hade <gary.hade@us.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Thomas Gleixner 提交于
Some BIOSes advertise HPET at 0x0. We really do no want to allocate a resource there. Check for it and leave early. Other BIOSes tell us the HPET is at 0xfed0000000000000 instead of 0xfed00000. Add a check and fix it up with a warning on user request. Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 David P. Reed 提交于
Correct potentially unstable PC RTC time register reading in time_64.c Stop the use of an incorrect technique for reading the standard PC RTC timer, which is documented to "disconnect" time registers from the bus while updates are in progress. The use of UIP flag while interrupts are disabled to protect a 244 microsecond window is one of the Motorola spec sheet's documented ways to read the RTC time registers reliably. tglx: removed locking changes from original patch, as they gain nothing (read_persistent_clock is only called during boot, suspend, resume - so no hot path affected) and conflict with the paravirt locking scheme (see 32bit code), which we do not want to complicate for no benefit. Signed-off-by: NDavid P. Reed <dpreed@reed.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 David P. Reed 提交于
Fix hard freeze on x86_64 when the ntpd service calls update_persistent_clock() A repeatable but randomly timed freeze has been happening in Fedora 6 and 7 for the last year, whenever I run the ntpd service on my AMD64x2 HP Pavilion dv9000z laptop. This freeze is due to the use of spin_lock(&rtc_lock) under the assumption (per a bad comment) that set_rtc_mmss is called only with interrupts disabled. The call from ntp.c to update_persistent_clock is made with interrupts enabled. Signed-off-by: NDavid P. Reed <dpreed@reed.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Thomas Gleixner 提交于
92cb7612 sets cpu_info->cpu_index to zero for no reason. Referencing cpu_info->cpu_index now points always to CPU#0, which is apparently not what we want. Remove it. Spotted-by: NZou Nan hai <nanhai.zou@intel.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Andreas Herrmann 提交于
Fix regressions introduced with 92cb7612. It can happen that cpuinfo is displayed for CPUs that are not online or even worse for CPUs not present at all. As an example, following was shown for a "second" CPU of a single core K8 variant: processor : 0 vendor_id : unknown cpu family : 0 model : 0 model name : unknown stepping : 0 cache size : 0 KB fpu : yes fpu_exception : yes cpuid level : 0 wp : yes flags : bogomips : 0.00 clflush size : 0 cache_alignment : 0 address sizes : 0 bits physical, 0 bits virtual power management: Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Andreas Herrmann 提交于
Commit d435d862 ("cpu hotplug: mce: fix cpu hotplug error handling") changed the error handling in mce_cpu_callback. In cases where not all CPUs are brought up during boot (e.g. using maxcpus and additional_cpus parameters) mce_cpu_callback now returns NOTFIY_BAD because for such CPUs cpu_data is not completely filled when the notifier is called. Thus mce_create_device fails right at its beginning: if (!mce_available(&cpu_data[cpu])) return -EIO; As a quick fix I suggest to check boot_cpu_data for MCE. To reproduce this regression: (1) boot with maxcpus=2 addtional_cpus=2 on a 4 CPU x86-64 system (2) # echo 1 >/sys/devices/system/cpu/cpu2/online -bash: echo: write error: Invalid argument dmesg shows: _cpu_up: attempt to bring up CPU 2 failed Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Ingo Molnar 提交于
dont use the vgetcpu tcache - it's causing problems with tasks migrating, they'll see the old cache up to a jiffy after the migration, further increasing the costs of the migration. In the worst case they see a complete bogus information from the tcache, when a sys_getcpu() call "invalidated" the cache info by incrementing the jiffies _and_ the cpuid info in the cache and the following vdso_getcpu() call happens after vdso_jiffies have been incremented. Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NUlrich Drepper <drepper@redhat.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Randy Dunlap 提交于
Fix Voyager section mismatch due to using __devinit instead of __cpuinit. WARNING: vmlinux.o(.text+0xd943): Section mismatch: reference to .init.text:init_gdt (between 'voyager_smp_prepare_boot_cpu' and 'smp_vic_cmn_interrupt') Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Randy Dunlap 提交于
Fix Voyager section mismatches: voyager_cat_init() should be __init. WARNING: vmlinux.o(.text+0xee83): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeea6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeeac): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeeb2): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xef4c): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xef56): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf10f): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf13b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf14b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf159): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1b1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1bb): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1c1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1c7): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1e6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 eric miao 提交于
PXA3xx uses its own clk_pxa3xx_cken_ops, modify the code to use the PXA3xx specific macros to define its clocks Signed-off-by: Neric miao <eric.miao@marvell.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 16 11月, 2007 5 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
This matters to any sort of device that is wired to one of the CPU interrupt pins on an SMP system. Typically the scenario is most easily triggered with the count/compare timer interrupt where the same interrupt number and thus irq_desc is used on each processor. CPU A CPU B do_IRQ() generic_handle_irq() handle_level_irq() spin_lock(desc_lock) set IRQ_INPROGRESS spin_unlock(desc_lock) do_IRQ() generic_handle_irq() handle_level_irq() spin_lock(desc_lock) IRQ_INPROGRESS set => bail out spin_lock(desc_lock) clear IRQ_INPROGRESS spin_unlock(desc_lock) In case of the cp0 compare interrupt this means the interrupt will be acked and not handled or re-armed on CPU b, so there won't be any timer interrupt until the count register wraps around. With kernels 2.6.20 ... 2.6.23 we usually were lucky that things were just working right on VSMP because the count registers are synchronized on bootup so it takes something that disables interrupts for a long time on one processor to trigger this one. For scenarios where an interrupt is multicasted or broadcasted over several CPUs the existing code was safe and the fix will break it. There is no way to know in the interrupt controller code because it is abstracted from the platform code. I think we do not have such a setup currently, so this should be ok. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Maciej W. Rozycki 提交于
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Maciej W. Rozycki 提交于
The GNU `config.guess' uses "linux-gnu" as the canonical system name. Fix the list of compiler prefixes checked to spell it correctly. Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-