- 24 Aug, 2009 8 commits
-
-
Pawel Moll authored
So far kernel command line arguments could be passed in by a bootloader or defined as CONFIG_CMDLINE, which completely overwriting the first one. This change allows a developer to declare selected kernel parameters in a kernel configuration (eg. project-specific defconfig), retaining possibility of passing others by a bootloader. The obvious examples of the first type are MTD partition or bigphysarea-like region definitions, while "debug" option or network configuration should be given by a bootloader or a JTAG boot script. Signed-off-by: Pawel Moll <pawel.moll@st.com> Signed-off-by: Stuart Menefy <stuart.menefy@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Jon Frosdick authored
This patches will trigger a reboot using the watchdog timer instead of double fault. Unlike the previous method, this one actually works in 32 bit mode. Reset should also be cleaner. Signed-off-by: Jon Frosdick <jon.frosdick@st.com> Signed-off-by: Carl Shaw <carl.shaw@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Giuseppe Cavallaro authored
Save the VBR allowing GDB to dump full registers set but do not reload it as soon as the kgdb_handle_exception is invoked. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Stuart Menefy <stuart.menefy@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
David McKay authored
The synopsys PCI cell used in the later STMicro chips requires code to be run in order to do IO cycles, rather than just memory mapping the IO space. Rather than extending the existing SH infrastructure to allow this, use the GENERIC_IOMAP implmentation to save re-inventing the wheel. This set of changes allows the SH to be built with GENERIC_IOMAP enabled, it just ifdef's out the functions provided by the GENERIC_IOMAP implementation, and provides a few required missing functions. Signed-off-by: David McKay <david.mckay@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Carl Shaw authored
GCC does not issue unwind information for function epilogues. Unfortunately we can catch a signal during an epilogue. The signal handler writes the current context and signal return code onto the stack overwriting previous contents. During unwinding, libgcc can try to restore registers from the stack and restores corrupted ones. This can lead to segmentation, misaligned access and sigbus faults. For example, consider the following code: mov.l r12,@-r15 mov.l r14,@-r15 sts.l pr,@-r15 mov r15,r14 <do stuff> mov r14, r15 lds.l @r15+, pr <<< SIGNAL HERE mov.l @r15+, r14 mov.l @r15+, r12 rts Unwind is aware that pr was pushed to stack in prolog, so tries to restore it. Unfortunately it restores the last word of the signal handler code placed on the stack by the kernel. This patch tries to avoid the problem by adding a guard region on the stack between where the function pushes data and where the signal handler pushes its return code. We probably don't see this problem often because exception handling unwinding in an epilogue only occurs due to a pthread cancel signal. Also the kernel signal stack handler alignment of 8 bytes could hide the occurance of this problem sometimes as the stack may not be trampled at a particular required word. This is not guaranteed to always work. It relies on a frame pointer existing for the function (so it can get the correct sp value) which is not always the case for the SH4. Modifications will also be made to libgcc for the case where there is no fp. Signed-off-by: Carl Shaw <carl.shaw@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Andre Draszik authored
This patch fixes a few problems with the existing code in do_address_error(). a) the variable used to printk()d the offending instruction wasn't initialized correctly. This is a fix to bug 5727 b) behaviour for CONFIG_CPU_SH2A wasn't correct c) the 'ignore address error' behaviour didn't update the PC, causing an infinite loop. Signed-off-by: Andre Draszik <andre.draszik@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Andre Draszik authored
This patch brings the SH4 misaligned trap handler in line with what happens on ARM: Add a /proc/cpu/alignment which can be read from to get alignment trap statistics and written to to influence the behaviour of the alignment trap handling. The value to write is a bitfield, which has the following meaning: 1 warn, 2 fixup, 4 signal In addition, we add a /proc/cpu/kernel_alignment, to enable or disable warnings in case of kernel code causing alignment errors. Signed-off by: Andre Draszik <andre.draszik@st.com> Signed-off-by: Stuart Menefy <stuart.menefy@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Andre Draszik authored
This patch makes sure we see messages about unaligned access fixups every now and then. Else especially userspace apps suffering from bad programming won't ever be noticed... Signed-off by: Andre Draszik <andre.draszik@st.com> Signed-off-by: Stuart Menefy <stuart.menefy@st.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
- 23 Aug, 2009 10 commits
-
-
Paul Mundt authored
-
Magnus Damm authored
The Runtime PM patch for UIO driver implements coarse grained dynamic power management for UIO devices. With that patch in place we can get rid of the static clock configuration. Which in turn makes it possible for cpuidle to enter deeper sleep. Signed-off-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Magnus Damm authored
With the Runtime PM driver changes in place, we must have Runtime PM support in place. Otherwise there is no way to enable clocks to the Runtime PM enabled hardware blocks. This patch makes Runtime PM mandatory on SuperH Mobile. Signed-off-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
The runtime PM for SH-Mobile code had platform_bus_notify() as __devinit, which is rather bogus. Kill off the annotation, which subsequently silences the section mismatch warnings. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Magnus Damm authored
This patch modifies the uio_pdrv_genirq driver to support Runtime PM. The power management implementation simply runtime resumes the device at open() time and runtime suspends it at release() time. The user space driver is responsible for re-initializing the hardware after open(). Signed-off-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Magnus Damm authored
This patch modifies the SuperH Mobile CEU driver to support Runtime PM. Driver callbacks for Runtime PM are empty because the device registers are always re-initialized after pm_runtime_get_sync(). The Runtime PM functions replaces the clock framework module stop bit handling in this driver. Signed-off-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Magnus Damm authored
This patch modifies the SuperH Mobile LCDC framebuffer driver to support Runtime PM. The driver is using the functions - pm_runtime_get_sync() - pm_runtime_put_sync() to inform the bus code if the hardware is idle or not. If the hardware is idle then the bus code may call the runtime dev_pm_ops callbacks to save and restore state. pm_runtime_resume() is used to allow the driver to access the hardware from probe(). Signed-off-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Magnus Damm authored
This patch modifies the SuperH Mobile I2C driver to support Runtime PM. These changes is all that is needed for proper Runtime PM support in this driver. Driver callbacks for Runtime PM are empty because the device registers are always re-initialized after pm_runtime_get_sync(). Signed-off-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Magnus Damm authored
This patch is V3 of the SuperH Mobile Runtime PM platform bus implentation matching Rafael's Runtime PM v16. The code gets invoked from the SuperH specific Runtime PM platform bus functions that override the weak symbols for: - platform_pm_runtime_suspend() - platform_pm_runtime_resume() - platform_pm_runtime_idle() This Runtime PM implementation performs two levels of power management. At the time of platform bus runtime suspend the clock to the device is stopped instantly. Later on if all devices within the power domain has their clocks stopped then the device driver ->runtime_suspend() callbacks are used to save hardware register state for each device. Device driver ->runtime_suspend() calls are scheduled from cpuidle context using platform_pm_runtime_suspend_idle(). When all devices have been fully suspended the processor is allowed to enter deep sleep from cpuidle. The runtime resume operation turns on clocks and also restores registers if needed. It is worth noting that the devices start in a suspended state and the device driver is responsible for calling runtime resume before accessing the actual hardware. In this particular platform bus implementation runtime resume is not allowed from interrupt context. Runtime suspend is however allowed from interrupt context as long as the synchronous functions are avoided. [ updated for v17 -- PFM. ] Signed-off-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
-
- 22 Aug, 2009 8 commits
-
-
Magnus Damm authored
This patch adds default Runtime PM callbacks to the dev_pm_ops belonging to the platform bus. The callbacks are weak symbols that architecture specific code can override. Allows Runtime PM even though CONFIG_PM_SLEEP=n. Signed-off-by: Magnus Damm <damm@igel.co.jp> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
-
Rafael J. Wysocki authored
Introduce a core framework for run-time power management of I/O devices. Add device run-time PM fields to 'struct dev_pm_info' and device run-time PM callbacks to 'struct dev_pm_ops'. Introduce a run-time PM workqueue and define some device run-time PM helper functions at the core level. Document all these things. Special thanks to Alan Stern for his help with the design and multiple detailed reviews of the pereceding versions of this patch and to Magnus Damm for testing feedback. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Magnus Damm <damm@igel.co.jp>
-
Rafael J. Wysocki authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: check saved state before restore
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] mpt2sas: fix config request and diag reset deadlock [SCSI] mpt2sas: Bump driver version 01.100.04.00 [SCSI] mpt2sas: fix oops because drv data points to NULL on resume from hibernate [SCSI] mpt2sas: fix crash due to Watchdog is active while OS in standby mode [SCSI] mpt2sas: fix infinite loop inside config request [SCSI] mpt2sas: Excessive log info causes sas iounit page time out [SCSI] mpt2sas: Raid 10 Value is showing as Raid 1E in /va/log/messages [SCSI] mpt2sas: Expander fix oops saying "Already part of another port" [SCSI] mpt2sas: Introduced check for enclosure_handle to avoid crash
-
Paul Mundt authored
The CIE and FDE structs are big enough and accessed regularly enough in certain configurations to make cacheline alignment useful. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Linus Torvalds authored
-
Linus Torvalds authored
In commit a8e7d49a ("Fix race in create_empty_buffers() vs __set_page_dirty_buffers()"), I removed a test for a NULL page mapping unintentionally when some of the code inside __set_page_dirty() was moved to the callers. That removal generally didn't matter, since a filesystem would serialize truncation (which clears the page mapping) against writing (which marks the buffer dirty), so locking at a higher level (either per-page or an inode at a time) should mean that the buffer page would be stable. And indeed, nothing bad seemed to happen. Except it turns out that apparently reiserfs does something odd when under load and writing out the journal, and we have a number of bugzilla entries that look similar: http://bugzilla.kernel.org/show_bug.cgi?id=13556 http://bugzilla.kernel.org/show_bug.cgi?id=13756 http://bugzilla.kernel.org/show_bug.cgi?id=13876 and it looks like reiserfs depended on that check (the common theme seems to be "data=journal", and a journal writeback during a truncate). I suspect reiserfs should have some additional locking, but in the meantime this should get us back to the pre-2.6.29 behavior. Pattern-pointed-out-by: Roland Kletzing <devzero@web.de> Cc: stable@kernel.org (2.6.29 and 2.6.30) Cc: Jeff Mahoney <jeffm@suse.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 21 Aug, 2009 14 commits
-
-
Paul Mundt authored
Conflicts: arch/sh/kernel/cpu/sh3/entry.S
-
Paul Mundt authored
sh64 does not yet support GENERIC_BUG, but still wants unwinder support. Alias UNWINDER_BUG and UNWINDER_BUG_ON to their BUG counterparts until the conversion to GENERIC_BUG is completed. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
Paul Mundt authored
This simplifies the unwinder trap handling, dropping the use of the special trapa vector and simply piggybacking on top of the BUG support. A new BUGFLAG_UNWINDER is added for flagging the unwinder fault, before continuing on with regular BUG dispatch. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
-
Paul Mundt authored
If the oprofile code is built as a module, unwind_stack() as used by the oprofile backtrace code is not available, causing build breakage. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm/radeon: add GET_PARAM/INFO support for Z pipes drm/radeon/kms: add r100/r200 OQ support. drm: Fix sysfs device confusion. drm/radeon/kms: implement the bo busy ioctl properly.
-
git://git.kernel.dk/linux-2.6-blockLinus Torvalds authored
* 'btrfs' of git://git.kernel.dk/linux-2.6-block: btrfs: fix inode rbtree corruption
-
Linus Torvalds authored
As noted in 83d349f3 ("x86: don't send an IPI to the empty set of CPU's"), some APIC's will be very unhappy with an empty destination mask. That commit added a WARN_ON() for that case, and avoided the resulting problem, but didn't fix the underlying reason for why those empty mask cases happened. This fixes that, by checking the result of 'cpumask_andnot()' of the current CPU actually has any other CPU's left in the set of CPU's to be sent a TLB flush, and not calling down to the IPI code if the mask is empty. The reason this started happening at all is that we started passing just the CPU mask pointers around in commit 4595f962 ("x86: change flush_tlb_others to take a const struct cpumask"), and when we did that, the cpumask was no longer thread-local. Before that commit, flush_tlb_mm() used to create it's own copy of 'mm->cpu_vm_mask' and pass that copy down to the low-level flush routines after having tested that it was not empty. But after changing it to just pass down the CPU mask pointer, the lower level TLB flush routines would now get a pointer to that 'mm->cpu_vm_mask', and that could still change - and become empty - after the test due to other CPU's having flushed their own TLB's. See http://bugzilla.kernel.org/show_bug.cgi?id=13933 for details. Tested-by: Thomas Björnell <thomas.bjornell@gmail.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
When 'and'ing two bitmasks (where 'andnot' is a variation on it), some cases want to know whether the result is the empty set or not. In particular, the TLB IPI sending code wants to do cpumask operations and determine if there are any CPU's left in the final set. So this just makes the bitmask (and cpumask) functions return a boolean for whether the result has any bits set. Cc: stable@kernel.org (2.6.30, needed by TLB shootdown fix) Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
The default_send_IPI_mask_logical() function uses the "flat" APIC mode to send an IPI to a set of CPU's at once, but if that set happens to be empty, some older local APIC's will apparently be rather unhappy. So just warn if a caller gives us an empty mask, and ignore it. This fixes a regression in 2.6.30.x, due to commit 4595f962 ("x86: change flush_tlb_others to take a const struct cpumask"), documented here: http://bugzilla.kernel.org/show_bug.cgi?id=13933 which causes a silent lock-up. It only seems to happen on PPro, P2, P3 and Athlon XP cores. Most developers sadly (or not so sadly, if you're a developer..) have more modern CPU's. Also, on x86-64 we don't use the flat APIC mode, so it would never trigger there even if the APIC didn't like sending an empty IPI mask. Reported-by: Pavel Vilim <wylda@volny.cz> Reported-and-tested-by: Thomas Björnell <thomas.bjornell@gmail.com> Reported-and-tested-by: Martin Rogge <marogge@onlinehome.de> Cc: Mike Travis <travis@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Matt Fleming authored
Allow a DWARF register to have an undefined value. When applied to the DWARF return address register this lets lets us label a function as having no direct caller, e.g. kernel_thread_helper(). Signed-off-by: Matt Fleming <matt@console-pimps.org>
-
Matt Fleming authored
The 'end' member of struct dwarf_fde denotes one byte past the end of the CFA instruction stream for an FDE. The value of 'end' was being calcualted incorrectly, it was being set too high. This resulted in dwarf_cfa_execute_insns() interpreting data past the end of valid instructions, thus causing all sorts of weird crashes. Signed-off-by: Matt Fleming <matt@console-pimps.org>
-
Matt Fleming authored
When CONFIG_DWARF_UNWINDER is enabled setup r14 in handle_interrupt, so that we can figure out what function was running when we were interrupted. Signed-off-by: Matt Fleming <matt@console-pimps.org>
-
Matt Fleming authored
We can't assume that if we execute the unwinder code and the unwinder was already running that it has faulted. Clearly two kernel threads can invoke the unwinder at the same time and may be running simultaneously. The previous approach used BUG() and BUG_ON() in the unwinder code to detect whether the unwinder was incapable of unwinding the stack, and that the next available unwinder should be used instead. A better approach is to explicitly invoke a trap handler to switch unwinders when the current unwinder cannot continue. Signed-off-by: Matt Fleming <matt@console-pimps.org>
-