- Mar 05, 2012
-
-
Paul Walmsley authored
ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set During system suspend, when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set on an omap_device, call the corresponding driver's ->suspend() and ->suspend_noirq() callbacks (if present). Similarly, during resume, the driver's ->resume() and ->resume_noirq() callbacks must both be called, if present. (The previous code only called ->suspend_noirq() and ->resume_noirq().) If all of these callbacks aren't called, some important driver suspend/resume code may not get executed. In current mainline, the bug fixed by this patch is only a problem under the following conditions: - the kernel is running on an OMAP4 - an OMAP UART is used as a console - the kernel command line parameter 'no_console_suspend' is specified - and the system enters suspend ("echo mem > /sys/power/state"). Under this combined circumstance, the system cannot be awakened via the serial port after commit be4b0281 ("tty: serial: OMAP: block idle while the UART is transferring data in PIO mode"). This is because the OMAP UART driver's ->suspend() callback is never called. The ->suspend() callback would have called uart_suspend_port() which in turn would call enable_irq_wake(). Since enable_irq_wake() isn't called for the UART's IRQ, check_wakeup_irqs() would mask off the UART IRQ in the GIC. On v3.3 kernels prior to the above commit, serial resume from suspend presumably occurred via the PRCM interrupt. The UART was in smart-idle mode, so it was able to send a PRCM wakeup which in turn would be converted into a PRCM interrupt to the GIC, waking up the kernel. But after the above commit, when the system is suspended in the middle of a UART transmit, the UART IP block would be in no-idle mode. In no-idle mode, the UART won't generate wakeups to the PRCM when incoming characters are received; only GIC interrupts. But since the UART driver's ->suspend() callback is never called, uart_suspend_port() and enable_irq_wake() is never called; so the UART interrupt is masked by check_wakeup_irqs() and the UART can't wake up the MPU. The remaining mechanism that could have awakened the system would have been I/O chain wakeups. These wouldn't be active because the console UART's clocks are never disabled when no_console_suspend is used, preventing the full chip from idling. Also, current mainline doesn't yet support full chip idle states for OMAP4, so I/O chain wakeups are not enabled. This patch is the result of a collaboration. John Stultz <johnstul@us.ibm.com> and Andy Green <andy.green@linaro.org> reported the serial wakeup problem that led to the discovery of this problem. Kevin Hilman <khilman@ti.com> narrowed the problem down to the use of no_console_suspend. Signed-off-by:Paul Walmsley <paul@pwsan.com> Cc: John Stultz <johnstul@us.ibm.com> Cc: Andy Green <andy.green@linaro.org> Reviewed-by:
Kevin Hilman <khilman@ti.com> Signed-off-by:
-
Kevin Hilman authored
Currently all omap_devices are forced to have the dummy device 'omap_device_parent' as a parent. This was used to distinguish omap_devices from "normal" platform_devices in the OMAP PM core code. Now that we implement the PM core using PM domains, this is no longer needed, and is removed. This also frees up omap_devices to have a more complex parent/child relationships that model actual device relationships. The only in-tree user of omap_device_parent was the OMAP PM layer to handle lost-context count for omap_devices. That is now converted to use the presence of the omap_device_pm_domain instead. Signed-off-by: -
Jean Pihet authored
Check the return code pointer value from debugfs_create_dir for error or NULL. Also added an additional check to prevent the creation of a 'suspend' entry at the debugfs root in case a power domain directory cannot be created. Signed-off-by:
Jean Pihet <j-pihet@ti.com> Signed-off-by:
-
Paul Walmsley authored
clkdms_setup() is identical across OMAP2, 3, and 4, so share it. Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Tested-by:
-
Paul Walmsley authored
Clean up a few different parts of omap_set_pwrdm_state(): - Remove a superfluous call to pwrdm_state_switch(). Not needed unless LOWPOWERSTATECHANGE is used, because the state switch code is called by either clkdm_sleep() or clkdm_allow_idle(). - Add code to wait for the power state transition in the OMAP4+ low power state change. This is speculative, so I would particularly appreciate feedback on this part. - Remove a superfluous call to pwrdm_read_pwrst(). - Update variable names to be more meaningful (hopefully) and precise. - Fix an error path bug that would not place the clockdomain back into hardware-supervised idle or sleep mode if the power state could not be programmed. The documentation for this function still needs major improvements; that's left for a later patch. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Acked-by:
-
Paul Walmsley authored
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst(). pwrdm_pre_transition(), which appears a few lines after these calls, invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no need to do it twice. N.B.: some of us have observed that accesses to the previous powerstate registers seem to be quite slow. Although the writes removed by this patch should be buffered by the write buffer, there is a read to a PRM register immediately afterwards. That will block the OMAP3 MPU until all of those writes complete. So this patch should result in a minor performance improvement during idle entry. Signed-off-by:
-
- Feb 29, 2012
-
-
Tony Lindgren authored
With the introduction of iomap changes platform init code fails for emu.c if CONFIG_OMAP3_EMU is selected: arch/arm/mach-omap2/emu.c:35:8: error: 'L4_EMU_34XX_BASE' undeclared here (not in a function) Signed-off-by:Tony Lindgren <tony@atomide.com>
-
- Feb 24, 2012
-
-
Kevin Hilman authored
Building omap_devices should only be done at init time, and since omap_device_build() is using early_platform calls which are also __init, this ensures that omap_device isn't trying to use functions that disappear. Signed-off-by:
-
Tony Lindgren authored
Now that omap hsmmc init is split into two functions, it's safe to mark omap_hsmmc_init and omap_mux related functions to __init. This basically reverts the following fixes for the case where TWL was compiled as a module: a98f77bb (ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()) 8930b4e3 (ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c) Additionally it fixes up the remaining section warnings for all callers of omap_mux functions. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Tony Lindgren authored
Drivers should no longer use omap_read/write functions but instead use ioremap + read/write functions. As some USB legacy code is still shared between omap1 and omap2420, let's limit the omap_read/write to plat/usb.h. Note that the long term fix is to update the drivers to use ioremap and read/write functions. That can now be done as a separate patch series that is limited to the USB drivers. Also make sure the legacy omap1-keypad.c driver builds if selected for 2420 based systems. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: -
Tony Lindgren authored
This is needed to minimize io.h so the SoC specific io.h for ARMs can removed. Note that minimal driver changes for DSS and RNG are needed to include cpu.h for SoC detection macros. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: -
Tony Lindgren authored
There's no need to have these defines in plat/io.h. Note that we now need to ifdef omap_read/write calls as they will be available for omap1 only. While at it, clean up the includes to group them like they typically are grouped. Signed-off-by: -
Tony Lindgren authored
There's no need to have these in plat/io.h. While at it, clean up the includes to group them like they typically are grouped. Signed-off-by: -
Tony Lindgren authored
This way we can remove omap_read/write call from the GPIO driver and remove include to linux/io.h. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: -
Tony Lindgren authored
We don't want to keep it in io.h as we want to remove io.h for omap2+ for the common zImage support. Signed-off-by: -
Tony Lindgren authored
These should be local to omap2/3/4. Signed-off-by: -
Paul Walmsley authored
Remove omap_{read,write}l() from the 24xx PM code. The clocksource code should now handle what this was supposed to do. Tested on N800 -- but it's hard to say whether this fixes anything. OMAP24xx static suspend path is currently broken, and this patch doesn't change that. Signed-off-by: -
Jarkko Nikula authored
Flag single_channel in struct omap2_mcspi_device_config is not used by drivers/spi/spi-omap2-mcspi.c so we may remove it from include/plat/mcspi.h and affected board files. Signed-off-by:
Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by:
-
- Feb 21, 2012
-
-
Rob Herring authored
Now that most platforms don't need disable_fiq and arch_ret_to_user macros, we can remove the empty macros or empty entry-macro.S files. Signed-off-by:
Rob Herring <rob.herring@calxeda.com> Acked-by:
Jamie Iles <jamie@jamieiles.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Ryan Mallon <rmallon@gmail.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by:
Shawn Guo <shawn.guo@linaro.org>
-
Rob Herring authored
With the removal of disable_fiq on rpc and addition MULTI_IRQ_HANDLER, entry-macro.S is no longer needed for platforms that select MULTI_IRQ_HANDLER and the include of it can be conditional. Signed-off-by:
-
Rob Herring authored
Only rpc uses disable_fiq macro. Change it to a run-time installed default FIQ handler. The handler is installed before FIQ is enabled so the behavior should be unchanged. Signed-off-by:
-
Rob Herring authored
Only 3 platforms need arch_ret_to_user macro, so add ARCH_HAS_RET_TO_USER kconfig option and make iop13xx, iop32x and iop33x select it. Signed-off-by:
-
- Feb 20, 2012
-
-
Tony Lindgren authored
Otherwise omap_device_build() and omap_mux related functions can't be marked as __init when twl is build as a module. If a board is using GPIO pins or regulators configured by an external chip, such as TWL PMIC on I2C bus, the board must mark those MMC controllers as deferred. Additionally both omap_hsmmc_init() and omap_hsmmc_late_init() must be called by the board. For MMC controllers using internal GPIO pins for card detect and regulators the slots don't need to be marked deferred. In this case calling omap_hsmmc_init() is sufficient. Only mark the MMC slots using gpio_cd or gpio_wd as deferred as noted by Igor Grinberg <grinberg@compulab.co.il>. Note that this patch does not change the behaviour for board-4430sdp.c board-omap4panda.c. These boards wrongly rely on the omap_hsmmc.c init function callback to configure the PMIC GPIO interrupt lines on external chip. If the PMIC interrupt lines are not configured during init, they will fail. Reported-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Rajendra Nayak <rnayak@ti.com> Signed-off-by:
-
Ohad Ben-Cohen authored
Expose omap_device_{alloc, delete, register} so we can use them outside of omap_device.c. This approach allows users, which need to manipulate an archdata member of a device before it is registered, to do so. This is also useful for users who have their devices created very early so they can be used at ->reserve() time to reserve CMA memory. The immediate use case for this is to set the private iommu archdata member, which binds a device to its associated iommu controller. This way, generic code will be able to attach omap devices to their iommus, without calling any omap-specific API. With this in hand, we can further clean the existing mainline OMAP iommu driver and its mainline users, and focus on generic IOMMU approaches for future users (rpmsg/remoteproc and the upcoming generic DMA API). This patch is still considered an interim solution until DT fully materializes for omap; at that point, this functionality will be removed as DT will take care of creating the devices and configuring them correctly. Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any omap-specific IOMMU API anymore. Signed-off-by:Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by:
-
Tony Lindgren authored
Otherwise we get the following error: arch/arm/mach-omap2/built-in.o: In function `n8x0_mmc_callback': twl-common.c:(.text+0x108a0): undefined reference to `omap_mmc_notify_cover_event' Fix this by warning about unusable MMC cover events. The long term fix needs to change the MMC drivers to register board specific callbacks directly with PMIC. Reported-by:
-
Tony Lindgren authored
On some omaps twl4030_gpio has a callback to try to initialize the MMC controller. If twl4030_gpio is compiled as a module, bad things can happen because the callback function starts calling functions that are supposed to be marked __init: Kernel panic - not syncing: Attempted to kill the idle task! twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules gpiochip_add: registered GPIOs 192 to 209 on device: twl4030 Unable to handle kernel paging request at virtual address b82a4c74 ... Additionally if this does not fail, warnings are produced about trying to register the MMC multiple times. Fix this by removing __init from omap_mux_get_by_name, and add checks if omap2_hsmmc_init() is getting called more than once. Note that this will get fixed properly later on by splitting omap2_hsmmc_init into two functions. Reported-by:
-
- Feb 18, 2012
-
-
Linus Torvalds authored
After all the FPU state cleanups and finally finding the problem that caused all our FPU save/restore problems, this re-introduces the preloading of FPU state that was removed in commit b3b0870e ("i387: do not preload FPU state at task switch time"). However, instead of simply reverting the removal, this reimplements preloading with several fixes, most notably - properly abstracted as a true FPU state switch, rather than as open-coded save and restore with various hacks. In particular, implementing it as a proper FPU state switch allows us to optimize the CR0.TS flag accesses: there is no reason to set the TS bit only to then almost immediately clear it again. CR0 accesses are quite slow and expensive, don't flip the bit back and forth for no good reason. - Make sure that the same model works for both x86-32 and x86-64, so that there are no gratuitous differences between the two due to the way they save and restore segment state differently due to architectural differences that really don't matter to the FPU state. - Avoid exposing the "preload" state to the context switch routines, and in particular allow the concept of lazy state restore: if nothing else has used the FPU in the meantime, and the process is still on the same CPU, we can avoid restoring state from memory entirely, just re-expose the state that is still in the FPU unit. That optimized lazy restore isn't actually implemented here, but the infrastructure is set up for it. Of course, older CPU's that use 'fnsave' to save the state cannot take advantage of this, since the state saving also trashes the state. In other words, there is now an actual _design_ to the FPU state saving, rather than just random historical baggage. Hopefully it's easier to follow as a result. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
This moves the bit that indicates whether a thread has ownership of the FPU from the TS_USEDFPU bit in thread_info->status to a word of its own (called 'has_fpu') in task_struct->thread.has_fpu. This fixes two independent bugs at the same time: - changing 'thread_info->status' from the scheduler causes nasty problems for the other users of that variable, since it is defined to be thread-synchronous (that's what the "TS_" part of the naming was supposed to indicate). So perfectly valid code could (and did) do ti->status |= TS_RESTORE_SIGMASK; and the compiler was free to do that as separate load, or and store instructions. Which can cause problems with preemption, since a task switch could happen in between, and change the TS_USEDFPU bit. The change to TS_USEDFPU would be overwritten by the final store. In practice, this seldom happened, though, because the 'status' field was seldom used more than once, so gcc would generally tend to generate code that used a read-modify-write instruction and thus happened to avoid this problem - RMW instructions are naturally low fat and preemption-safe. - On x86-32, the current_thread_info() pointer would, during interrupts and softirqs, point to a *copy* of the real thread_info, because x86-32 uses %esp to calculate the thread_info address, and thus the separate irq (and softirq) stacks would cause these kinds of odd thread_info copy aliases. This is normally not a problem, since interrupts aren't supposed to look at thread information anyway (what thread is running at interrupt time really isn't very well-defined), but it confused the heck out of irq_fpu_usable() and the code that tried to squirrel away the FPU state. (It also caused untold confusion for us poor kernel developers). It also turns out that using 'task_struct' is actually much more natural for most of the call sites that care about the FPU state, since they tend to work with the task struct for other reasons anyway (ie scheduling). And the FPU data that we are going to save/restore is found there too. Thanks to Arjan Van De Ven <arjan@linux.intel.com> for pointing us to the %esp issue. Cc: Arjan van de Ven <arjan@linux.intel.com> Reported-and-tested-by:
Raphael Prevost <raphael@buro.asia> Acked-and-tested-by:
Suresh Siddha <suresh.b.siddha@intel.com> Tested-by:
Peter Anvin <hpa@zytor.com> Signed-off-by:
-
- Feb 17, 2012
-
-
Linus Torvalds authored
The AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception is pending. In order to not leak FIP state from one process to another, we need to do a floating point load after the fxsave of the old process, and before the fxrstor of the new FPU state. That resets the state to the (uninteresting) kernel load, rather than some potentially sensitive user information. We used to do this directly after the FPU state save, but that is actually very inconvenient, since it (a) corrupts what is potentially perfectly good FPU state that we might want to lazy avoid restoring later and (b) on x86-64 it resulted in a very annoying ordering constraint, where "__unlazy_fpu()" in the task switch needs to be delayed until after the DS segment has been reloaded just to get the new DS value. Coupling it to the fxrstor instead of the fxsave automatically avoids both of these issues, and also ensures that we only do it when actually necessary (the FP state after a save may never actually get used). It's simply a much more natural place for the leaked state cleanup. Signed-off-by:
-
- Feb 16, 2012
-
-
Linus Torvalds authored
Yes, taking the trap to re-load the FPU/MMX state is expensive, but so is spending several days looking for a bug in the state save/restore code. And the preload code has some rather subtle interactions with both paravirtualization support and segment state restore, so it's not nearly as simple as it should be. Also, now that we no longer necessarily depend on a single bit (ie TS_USEDFPU) for keeping track of the state of the FPU, we migth be able to do better. If we are really switching between two processes that keep touching the FP state, save/restore is inevitable, but in the case of having one process that does most of the FPU usage, we may actually be able to do much better than the preloading. In particular, we may be able to keep track of which CPU the process ran on last, and also per CPU keep track of which process' FP state that CPU has. For modern CPU's that don't destroy the FPU contents on save time, that would allow us to do a lazy restore by just re-enabling the existing FPU state - with no restore cost at all! Signed-off-by: -
Linus Torvalds authored
This creates three helper functions that do the TS_USEDFPU accesses, and makes everybody that used to do it by hand use those helpers instead. In addition, there's a couple of helper functions for the "change both CR0.TS and TS_USEDFPU at the same time" case, and the places that do that together have been changed to use those. That means that we have fewer random places that open-code this situation. The intent is partly to clarify the code without actually changing any semantics yet (since we clearly still have some hard to reproduce bug in this area), but also to make it much easier to use another approach entirely to caching the CR0.TS bit for software accesses. Right now we use a bit in the thread-info 'status' variable (this patch does not change that), but we might want to make it a full field of its own or even make it a per-cpu variable. Signed-off-by: -
Linus Torvalds authored
Touching TS_USEDFPU without touching CR0.TS is confusing, so don't do it. By moving it into the callers, we always do the TS_USEDFPU next to the CR0.TS accesses in the source code, and it's much easier to see how the two go hand in hand. Signed-off-by: -
Linus Torvalds authored
Commit 5b1cbac3 ("i387: make irq_fpu_usable() tests more robust") added a sanity check to the #NM handler to verify that we never cause the "Device Not Available" exception in kernel mode. However, that check actually pinpointed a (fundamental) race where we do cause that exception as part of the signal stack FPU state save/restore code. Because we use the floating point instructions themselves to save and restore state directly from user mode, we cannot do that atomically with testing the TS_USEDFPU bit: the user mode access itself may cause a page fault, which causes a task switch, which saves and restores the FP/MMX state from the kernel buffers. This kind of "recursive" FP state save is fine per se, but it means that when the signal stack save/restore gets restarted, it will now take the '#NM' exception we originally tried to avoid. With preemption this can happen even without the page fault - but because of the user access, we cannot just disable preemption around the save/restore instruction. There are various ways to solve this, including using the "enable/disable_page_fault()" helpers to not allow page faults at all during the sequence, and fall back to copying things by hand without the use of the native FP state save/restore instructions. However, the simplest thing to do is to just allow the #NM from kernel space, but fix the race in setting and clearing CR0.TS that this all exposed: the TS bit changes and the TS_USEDFPU bit absolutely have to be atomic wrt scheduling, so while the actual state save/restore can be interrupted and restarted, the act of actually clearing/setting CR0.TS and the TS_USEDFPU bit together must not. Instead of just adding random "preempt_disable/enable()" calls to what is already excessively ugly code, this introduces some helper functions that mostly mirror the "kernel_fpu_begin/end()" functionality, just for the user state instead. Those helper functions should probably eventually replace the other ad-hoc CR0.TS and TS_USEDFPU tests too, but I'll need to think about it some more: the task switching functionality in particular needs to expose the difference between the 'prev' and 'next' threads, while the new helper functions intentionally were written to only work with 'current'. Signed-off-by:
-
Anton Blanchard authored
perf on POWER stopped working after commit e050e3f0 (perf: Fix broken interrupt rate throttling). That patch exposed a bug in the POWER perf_events code. Since the PMCs count upwards and take an exception when the top bit is set, we want to write 0x80000000 - left in power_pmu_start. We were instead programming in left which effectively disables the counter until we eventually hit 0x80000000. This could take seconds or longer. With the patch applied I get the expected number of samples: SAMPLE events: 9948 Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: <stable@kernel.org>
-
Benjamin Herrenschmidt authored
Program Check exceptions are the result of WARNs, BUGs, some type of breakpoints, kprobe, and other illegal instructions. We want interrupts (and thus preemption) to remain disabled while doing the initial stage of testing the reason and branching off to a debugger or kprobe, so we are still on the original CPU which makes debugging easier in various cases. This is how the code was intended, hence the local_irq_enable() right in the middle of program_check_exception(). However, the assembly exception prologue for that exception was incorrectly marked as enabling interrupts, which defeats that (and records a redundant enable with lockdep). Signed-off-by: -
Stephen Rothwell authored
Since we are heading towards removing the Legacy iSeries platform, start by no longer building it for ppc64_defconfig. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
Upstream changes to the way PHB resources are registered broke the resource fixup for FSL boards. We can no longer rely on the resource pointer array for the PHB's pci_bus structure, so let's leave it alone and go straight for the PHB resources instead. This also makes the code generally more readable. Signed-off-by: -
Ira Snyder authored
A kernel oops/panic prints an instruction dump showing several instructions before and after the instruction which caused the oops/panic. The code intended that the faulting instruction be enclosed in angle brackets, however a bug caused the faulting instruction to be interpreted by printk() as the message log level. To fix this, the KERN_CONT log level is added before the actual text of the printed message. === Before the patch === [ 1081.587266] Instruction dump: [ 1081.590236] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 [ 1081.598034] 3d20c03a 9009a114 7c0004ac 39200000 [ 1081.602500] 4e800020 3803ffd0 2b800009 <4>[ 1081.587266] Instruction dump: <4>[ 1081.590236] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 <4>[ 1081.598034] 3d20c03a 9009a114 7c0004ac 39200000 <98090000>[ 1081.602500] 4e800020 3803ffd0 2b800009 === After the patch === [ 51.385216] Instruction dump: [ 51.388186] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 [ 51.395986] 3d20c03a 9009a114 7c0004ac 39200000 <98090000> 4e800020 3803ffd0 2b800009 <4>[ 51.385216] Instruction dump: <4>[ 51.388186] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 <4>[ 51.395986] 3d20c03a 9009a114 7c0004ac 39200000 <98090000> 4e800020 3803ffd0 2b800009 Signed-off-by:
Ira W. Snyder <iws@ovro.caltech.edu> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
- Feb 15, 2012
-
-
Linus Torvalds authored
The check for save_init_fpu() (introduced in commit 5b1cbac3: "i387: make irq_fpu_usable() tests more robust") was the wrong way around, but I hadn't noticed, because my "tests" were bogus: the FPU exceptions are disabled by default, so even doing a divide by zero never actually triggers this code at all unless you do extra work to enable them. So if anybody did enable them, they'd get one spurious warning. Signed-off-by:
-
- Feb 14, 2012
-
-
Thadeu Lima de Souza Cascardo authored
EEH may happen during a PCI driver probe. If the driver is trying to access some register in a loop, the EEH code will try to print the driver name. But the driver pointer in struct pci_dev is not set until probe returns successfully. Use a function to test if the device and the driver pointer is NULL before accessing the driver's name. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
