aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-06-26cgroup: always use RCU accessors for protected accessesTejun Heo1-9/+12
kernel/cgroup.c still has places where a RCU pointer is set and accessed directly without going through RCU_INIT_POINTER() or rcu_dereference_protected(). They're all properly protected accesses so nothing is broken but it leads to spurious sparse RCU address space warnings. Substitute direct accesses with RCU_INIT_POINTER() and rcu_dereference_protected(). Note that %true is specified as the extra condition for all derference updates. This isn't ideal as all it does is suppressing warning without actually policing synchronization rules; however, most are scheduled to be removed pretty soon along with css_id itself, so no reason to be more elaborate. Combined with the previous changes, this removes all RCU related sparse warnings from cgroup. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Fengguang Wu <[email protected]> Acked-by; Li Zefan <[email protected]>
2013-06-26cgroup: fix RCU accesses around task->cgroupsTejun Heo1-11/+13
There are several places in kernel/cgroup.c where task->cgroups is accessed and modified without going through proper RCU accessors. None is broken as they're all lock protected accesses; however, this still triggers sparse RCU address space warnings. * Consistently use task_css_set() for task->cgroups dereferencing. * Use RCU_INIT_POINTER() to clear task->cgroups to &init_css_set on exit. * Remove unnecessary rcu_dereference_raw() from cset->subsys[] dereference in cgroup_exit(). Signed-off-by: Tejun Heo <[email protected]> Reported-by: Fengguang Wu <[email protected]> Acked-by: Li Zefan <[email protected]>
2013-06-26cgroup: fix RCU accesses to task->cgroupsTejun Heo1-10/+48
task->cgroups is a RCU pointer pointing to struct css_set. A task switches to a different css_set on cgroup migration but a css_set doesn't change once created and its pointers to cgroup_subsys_states aren't RCU protected. task_subsys_state[_check]() is the macro to acquire css given a task and subsys_id pair. It RCU-dereferences task->cgroups->subsys[] not task->cgroups, so the RCU pointer task->cgroups ends up being dereferenced without read_barrier_depends() after it. It's broken. Fix it by introducing task_css_set[_check]() which does RCU-dereference on task->cgroups. task_subsys_state[_check]() is reimplemented to directly dereference ->subsys[] of the css_set returned from task_css_set[_check](). This removes some of sparse RCU warnings in cgroup. v2: Fixed unbalanced parenthsis and there's no need to use rcu_dereference_raw() when !CONFIG_PROVE_RCU. Both spotted by Li. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Fengguang Wu <[email protected]> Acked-by: Li Zefan <[email protected]> Cc: [email protected]
2013-06-26cgroup: grab cgroup_mutex in drop_parsed_module_refcounts()Tejun Heo1-5/+5
This isn't strictly necessary as all subsystems specified in @subsys_mask are guaranteed to be pinned; however, it does spuriously trigger lockdep warning. Let's grab cgroup_mutex around it. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Li Zefan <[email protected]>
2013-06-26cgroup: fix cgroupfs_root early destruction pathTejun Heo2-3/+20
cgroupfs_root used to have ->actual_subsys_mask in addition to ->subsys_mask. a8a648c4ac ("cgroup: remove cgroup->actual_subsys_mask") removed it noting that the subsys_mask is essentially temporary and doesn't belong in cgroupfs_root; however, the patch made it impossible to tell whether a cgroupfs_root actually has the subsystems bound or just have the bits set leading to the following BUG when trying to mount with subsystems which are already mounted elsewhere. kernel BUG at kernel/cgroup.c:1038! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ... CPU: 1 PID: 7973 Comm: mount Tainted: G W 3.10.0-rc7-next-20130625-sasha-00011-g1c1dc0e #1105 task: ffff880fc0ae8000 ti: ffff880fc0b9a000 task.ti: ffff880fc0b9a000 RIP: 0010:[<ffffffff81249b29>] [<ffffffff81249b29>] rebind_subsystems+0x409/0x5f0 ... Call Trace: [<ffffffff8124bd4f>] cgroup_kill_sb+0xff/0x210 [<ffffffff813d21af>] deactivate_locked_super+0x4f/0x90 [<ffffffff8124f3b3>] cgroup_mount+0x673/0x6e0 [<ffffffff81257169>] cpuset_mount+0xd9/0x110 [<ffffffff813d2580>] mount_fs+0xb0/0x2d0 [<ffffffff81404afd>] vfs_kern_mount+0xbd/0x180 [<ffffffff814070b5>] do_new_mount+0x145/0x2c0 [<ffffffff814085d6>] do_mount+0x356/0x3c0 [<ffffffff8140873d>] SyS_mount+0xfd/0x140 [<ffffffff854eb600>] tracesys+0xdd/0xe2 We still want rebind_subsystems() to take added/removed masks, so let's fix it by marking whether a cgroupfs_root has finished binding or not. Also, document what's going on around ->subsys_mask initialization so that similar mistakes aren't repeated. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Sasha Levin <[email protected]> Acked-by: Li Zefan <[email protected]>
2013-06-26Revert "char: misc: assign file->private_data in all cases"Greg Kroah-Hartman1-1/+1
This reverts commit 585d98e00ba7a5e2abe65f7a1eff631cb612289b, as it breaks the FUSE misc driver. Reported-by: Sedat Dilek <[email protected]> Cc: Thomas Petazzoni <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-26dlm: Avoid LVB truncationBart Van Assche1-4/+4
For lockspaces with an LVB length above 64 bytes, avoid truncating the LVB while exchanging it with another node in the cluster. Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: David Teigland <[email protected]>
2013-06-26Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into next/dtArnd Bergmann4-2/+44
From Nicolas Ferre: - more SPI DT activation for rm9200 - SPI DMA for at91sam9n12/sama5d3 And one little fix for SPI compatibility string * tag 'at91-dt' of git://github.com/at91linux/linux-at91: ARM: at91: dt: rm9200ek: add spi support ARM: at91: dt: rm9200: add spi support ARM: at91/DT: at91sam9n12: add SPI DMA client infos ARM: at91/DT: sama5d3: add SPI DMA client infos ARM: at91/DT: fix SPI compatibility string Conflicts: arch/arm/boot/dts/sama5d3.dtsi Signed-off-by: Arnd Bergmann <[email protected]>
2013-06-26Merge tag 'omap-pm-v3.11/fixes/omap5-voltdm' of ↵Arnd Bergmann1-10/+0
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into next/soc From Kevin Hilman: OMAP5: PM: fix boot by removing unneeded dummy voltage domain data * tag 'omap-pm-v3.11/fixes/omap5-voltdm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm: ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data Signed-off-by: Arnd Bergmann <[email protected]>
2013-06-26ARM: at91/PMC: use at91_usb_rate() for UTMI PLLNicolas Ferre1-2/+1
We are using this function, now that we have introduced the support for UTMI clock for computing the USB host rate. Signed-off-by: Nicolas Ferre <[email protected]> Tested-by: Bo Shen <[email protected]>
2013-06-26ARM: at91/PMC: fix at91sam9n12 USB FS initNicolas Ferre2-4/+24
at91sam9n12 has Full-speed only USB. So we should add it to the list in at91_pllb_usbfs_clock_init() function. Moreover, at91sam9n12 has an unusual PMC in the sense that it has a PLLB but also has a USB clock register. Signed-off-by: Nicolas Ferre <[email protected]> Tested-by: Bo Shen <[email protected]>
2013-06-26ARM: at91/PMC: at91sam9n12 family has a PLLBNicolas Ferre1-1/+0
Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Bo Shen <[email protected]>
2013-06-26ARM: at91/PMC: sama5d3 family doesn't have a PLLBNicolas Ferre1-1/+2
Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Ludovic Desroches <[email protected]>
2013-06-26x86/platform: Make X86_GOLDFISH depend on X86_EXTENDED_PLATFORMBen Hutchings1-0/+2
All non-PC platforms are supposed to be dependent on this option. Signed-off-by: Ben Hutchings <[email protected]> Cc: Jun Nakajima <[email protected]> Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26locking-selftests: Handle unexpected failures more strictlyMaarten Lankhorst1-3/+5
When CONFIG_PROVE_LOCKING is not enabled, more tests are expected to pass unexpectedly, but there no tests that should start to fail that pass with CONFIG_PROVE_LOCKING enabled. Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/20130620113151.4001.77963.stgit@patser Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26mutex: Add more w/w tests to test EDEADLK path handlingMaarten Lankhorst1-3/+261
Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/20130620113141.4001.54331.stgit@patser Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26mutex: Add more tests to lib/locking-selftest.cMaarten Lankhorst1-0/+62
None of the ww_mutex codepaths should be taken in the 'normal' mutex calls. The easiest way to verify this is by using the normal mutex calls, and making sure o.ctx is unmodified. Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/20130620113130.4001.45423.stgit@patser Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26mutex: Add w/w tests to lib/locking-selftest.cMaarten Lankhorst1-19/+381
This stresses the lockdep code in some ways specifically useful to ww_mutexes. It adds checks for most of the common locking errors. Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/20130620113124.4001.23186.stgit@patser Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26mutex: Add w/w mutex slowpath debuggingDaniel Vetter3-3/+62
Injects EDEADLK conditions at pseudo-random interval, with exponential backoff up to UINT_MAX (to ensure that every lock operation still completes in a reasonable time). This way we can test the wound slowpath even for ww mutex users where contention is never expected, and the ww deadlock avoidance algorithm is only needed for correctness against malicious userspace. An example would be protecting kernel modesetting properties, which thanks to single-threaded X isn't really expected to contend, ever. I've looked into using the CONFIG_FAULT_INJECTION infrastructure, but decided against it for two reasons: - EDEADLK handling is mandatory for ww mutex users and should never affect the outcome of a syscall. This is in contrast to -ENOMEM injection. So fine configurability isn't required. - The fault injection framework only allows to set a simple probability for failure. Now the probability that a ww mutex acquire stage with N locks will never complete (due to too many injected EDEADLK backoffs) is zero. But the expected number of ww_mutex_lock operations for the completely uncontended case would be O(exp(N)). The per-acuiqire ctx exponential backoff solution choosen here only results in O(log N) overhead due to injection and so O(log N * N) lock operations. This way we can fail with high probability (and so have good test coverage even for fancy backoff and lock acquisition paths) without running into patalogical cases. Note that EDEADLK will only ever be injected when we managed to acquire the lock. This prevents any behaviour changes for users which rely on the EALREADY semantics. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/20130620113117.4001.21681.stgit@patser Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26mutex: Add support for wound/wait style locksMaarten Lankhorst5-17/+1003
Wound/wait mutexes are used when other multiple lock acquisitions of a similar type can be done in an arbitrary order. The deadlock handling used here is called wait/wound in the RDBMS literature: The older tasks waits until it can acquire the contended lock. The younger tasks needs to back off and drop all the locks it is currently holding, i.e. the younger task is wounded. For full documentation please read Documentation/ww-mutex-design.txt. References: https://lwn.net/Articles/548909/ Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Rob Clark <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26arch: Make __mutex_fastpath_lock_retval return whether fastpath succeeded or notMaarten Lankhorst9-59/+41
This will allow me to call functions that have multiple arguments if fastpath fails. This is required to support ticket mutexes, because they need to be able to pass an extra argument to the fail function. Originally I duplicated the functions, by adding __mutex_fastpath_lock_retval_arg. This ended up being just a duplication of the existing function, so a way to test if fastpath was called ended up being better. This also cleaned up the reservation mutex patch some by being able to call an atomic_set instead of atomic_xchg, and making it easier to detect if the wrong unlock function was previously used. Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/20130620113105.4001.83929.stgit@patser Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26ARC: Setup Vector Table Base in early bootVineet Gupta2-2/+2
Otherwise early boot exceptions such as instructions errors due to configuration mismatch between kernel and hardware go off to la-la land, as opposed to hitting the handler and panic()'ing properly. Signed-off-by: Vineet Gupta <[email protected]>
2013-06-26ARC: Remove explicit passing around of ECRVineet Gupta13-78/+59
With ECR now part of pt_regs * No need to propagate from lowest asm handlers as arg * No need to save it in tsk->thread.cause_code * Avoid bit chopping to access the bit-fields More code consolidation, cleanup Signed-off-by: Vineet Gupta <[email protected]>
2013-06-26perf/x86/intel: Support full width countingAndi Kleen3-0/+15
Recent Intel CPUs like Haswell and IvyBridge have a new alternative MSR range for perfctrs that allows writing the full counter width. Enable this range if the hardware reports it using a new capability bit. Currently the perf code queries CPUID to get the counter width, and sign extends the counter values as needed. The traditional PERFCTR MSRs always limit to 32bit, even though the counter internally is larger (usually 48 bits on recent CPUs) When the new capability is set use the alternative range which do not have these restrictions. This lowers the overhead of perf stat slightly because it has to do less interrupts to accumulate the counter value. On Haswell it also avoids some problems with TSX aborting when the end of the counter range is reached. ( See the patch "perf/x86/intel: Avoid checkpointed counters causing excessive TSX aborts" for more details. ) Signed-off-by: Andi Kleen <[email protected]> Reviewed-by: Stephane Eranian <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26perf: Disable monitoring on setuid processes for regular usersStephane Eranian1-7/+9
There was a a bug in setup_new_exec(), whereby the test to disabled perf monitoring was not correct because the new credentials for the process were not yet committed and therefore the get_dumpable() test was never firing. The patch fixes the problem by moving the perf_event test until after the credentials are committed. Signed-off-by: Stephane Eranian <[email protected]> Tested-by: Jiri Olsa <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26irqchip: Add support for ARMv7-M NVICUwe Kleine-König3-0/+123
This interrupt controller is integrated in all Cortex-M3 and Cortex-M4 machines. Support for this controller appeared in Catalin's Cortex tree based on 2.6.33 but was nearly completely rewritten. Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Catalin Marinas <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Grant Likely <[email protected]> Cc: [email protected] Cc: Jonathan Austin <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2013-06-26Merge tag 'please-pull-mce-bitmap-comment' of ↵Ingo Molnar112-531/+1005
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/ras Pull MCE updates from Tony Luck: "Better comments so we understand our existing machine check bank bitmaps - prelude to adding another bitmap soon." Signed-off-by: Ingo Molnar <[email protected]>
2013-06-26serial: sh-sci: Initialise variables before access in sci_set_termios()Simon Horman1-2/+2
This change addresses two warnings that are flagged by gcc relating to potential access to the ssr and cks variables while they are uninitialised. I have addressed this by initialising the values to the defaults present in sci_baud_calc_hscif(). It is my analysis that cks is always initialised if used but that without this change ssr may be accessed while uninitialised. The code altered by this patch was introduced by commit f303b364b41d3fc5bf879799128958400b7859aa ("serial: sh-sci: HSCIF support"). Reported-by: Arnd Bergmann <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Simon Horman <[email protected]>
2013-06-26ARC: pt_regs update #5: Use real ECR for pt_regs->event vs. synth valuesVineet Gupta8-57/+53
pt_regs->event was set with artificial values to identify the low level system event (syscall trap / breakpoint trap / exceptions / interrupts) With r8 saving out of the way, the full word can be used to save real ECR (Exception Cause Register) which helps idenify the event naturally, including additional info such as cause code, param. Only for Interrupts, where ECR is not applicable, do we resort to synthetic non ECR values. SAVE_ALL_TRAP/EXCEPTIONS can now be merged as they both use ECR with different runtime values. The ptrace helpers now use the sub-fields of ECR to distinguish the events (e.g. vector 0x25 is trap, param 0 is syscall...) The following benefits will follow: (1) This centralizes the location of where ECR is saved and will allow the cleanup of task->thread.cause_code ECR placeholder which is set in non-uniform way. Then ARC VM code can safely rely on it being there for purpose of finer grained VM_EXEC dcache flush (based on exec fault: I-TLB Miss) (2) Further, ECR being passed around from low level handlers as arg can be eliminated as it is part of standard reg-file in pt_regs Signed-off-by: Vineet Gupta <[email protected]>
2013-06-26ARM: at91: dt: rm9200ek: add spi supportJean-Christophe PLAGNIOL-VILLARD1-0/+10
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]>
2013-06-26ARM: at91: dt: rm9200: add spi supportJean-Christophe PLAGNIOL-VILLARD1-0/+20
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]>
2013-06-26ARM: at91/DT: at91sam9n12: add SPI DMA client infosNicolas Ferre1-0/+6
Signed-off-by: Nicolas Ferre <[email protected]>
2013-06-26ARM: at91/DT: sama5d3: add SPI DMA client infosNicolas Ferre1-0/+6
Signed-off-by: Nicolas Ferre <[email protected]> Tested-by: Wenyou Yang <[email protected]>
2013-06-26ARM: at91/DT: fix SPI compatibility stringNicolas Ferre1-2/+2
In previous version of SPI driver we where using different compatibility stings for finding SPI features. We are now using the IP revision information. So we stay with the unique compatibility string for this driver: "atmel,at91rm9200-spi". Signed-off-by: Nicolas Ferre <[email protected]> Tested-by: Wenyou Yang <[email protected]>
2013-06-25gpio/omap: don't use linear domain mapping for OMAP1Javier Martinez Canillas1-1/+21
Commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping") converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ domain instead of using a legacy mapping. Not using a legacy mapping has a number of benefits but it requires the platform to support SPARSE_IRQ which currently is not supported on OMAP1. So this change caused a regression on OMAP1 platforms [1]. Since this issue is not present on all OMAP2+ platforms, there is no need to revert the driver to use legacy domain mapping for all the platforms. [1]: http://www.mail-archive.com/[email protected]/msg89005.html Signed-off-by: Javier Martinez Canillas <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2013-06-25pch_uart: Add uart_clk selection for the MinnowBoardDarren Hart1-0/+5
Use DMI_BOARD_NAME to determine if we are running on a MinnowBoard and set the uart clock to 50MHz if so. This removes the need to pass the user_uartclk to the kernel at boot time. Signed-off-by: Darren Hart <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Peter Waskiewicz <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-25driver core: device.h: fix doc compilation warningsMichael Opdenacker1-0/+3
This patch fixes the below 3 warnings running "make htmldocs", by adding descriptions for recently added structure members: DOCPROC Documentation/DocBook/device-drivers.xml Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:116): No description found for parameter 'lock_key' Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:723): No description found for parameter 'cma_area' Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:723): No description found for parameter 'iommu_group' Don't hesitate to propose better descriptions! Signed-off-by: Michael Opdenacker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-25firmware loader: fix another compile warning with PM_SLEEP unsetMing Lei1-12/+12
This patch fixes another compiling warning with PM_SLEEP unset: drivers/base/firmware_class.c:221:29: warning: 'fw_lookup_buf' defined but not used [-Wunused-function] This time I do build kernel with both PM_SLEEP set and unset, and no warning found any more with the patch. Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-25drivers: uio_pdrv_genirq: Use of_match_ptr() macroSachin Kamat1-4/+1
This eliminates having an #ifdef returning NULL for the case when OF is disabled. Signed-off-by: Sachin Kamat <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-25ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage dataNishanth Menon1-10/+0
commit 20d49e9ccfece526db755940721aa13e331936d4 (ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data) Introduced dummy volt data for OMAP5 with OMAP4460 voltage information. However with the fixes introduced in later patches commit cd8abed1da91a3250aa4b3857479613a2b446f84 (ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm) We are no longer restricted in that respect. Further, OPP voltage information is supposed to be provided by dts information. This needs to be added in future patches as various voltage modules are converted to dts. This also fixes the build breakage for voltagedomains54xx_data.c when just OMAP5 SoC is enabled: https://patchwork.kernel.org/patch/2764191/ Reported-by: Arnd Bergmann <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Cc: Benoit Cousson <[email protected]> Cc: Santosh Shilimkar <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: [email protected] Signed-off-by: Kevin Hilman <[email protected]>
2013-06-25net/tg3: Avoid delay during MMIO accessGavin Shan1-0/+36
When the EEH error is the result of a fenced host bridge, MMIO accesses can be very slow (milliseconds) to timeout and return all 1's, thus causing the driver various timeout loops to take way too long and trigger soft-lockup warnings (in addition to taking minutes to recover). It might be worthwhile to check if for any of these cases, ffffffff is a valid possible value, and if not, bail early since that means the HW is either gone or isolated. In the meantime, checking that the PCI channel is offline would be workaround of the problem. Cc: <[email protected]> # v3.0+ Signed-off-by: Gavin Shan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-06-25usb: musb: omap2430: make it compile againSebastian Andrzej Siewior1-2/+2
it does not compile since 09fc7d ("usb: musb: fix incorrect usage of resource pointer"). What makes me wonder most is if source of the Tested-by tag :) Acked-by: Felipe Balbi <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-25usb: chipidea: ci_hdrc_imx: access phy via private dataFabio Estevam1-5/+4
commit ea1418b5f1a (usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to get phy) causes the USB host to miss the disconnect/connect events. In order to reproduce this problem: - Insert a USB thumb into the USB host port (connection is detected) - Remove it (no disconnect event will be reported) - Insert the USB thumb again (connection is not detected) Fix this problem by accessing the usb_phy structure using the private data instead of accessing a local structure. Tested on a mx28evk board. Signed-off-by: Fabio Estevam <[email protected]> Acked-by: Peter Chen <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-25xhci: Add missing unlocks on error pathsEmil Goode1-0/+2
This patch adds missing unlocks on error paths in the xhci_free_streams and xhci_configure_endpoint functions. Signed-off-by: Emil Goode <[email protected]> Signed-off-by: Sarah Sharp <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-06-25ipv6: check return value of ipv6_get_lladdrHannes Frederic Sowa1-5/+4
We should check the return value of ipv6_get_lladdr in inet6_set_iftoken. A possible situation, which could leave ll_addr unassigned is, when the user removed her link-local address but a global scoped address was already set. In this case the interface would still be IF_READY and not dead. In that case the RS source address is some value from the stack. v2: Daniel Borkmann noted a small indent inconstancy; no semantic changes. Cc: Daniel Borkmann <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Reviewed-by: Flavio Leitner <[email protected]> Signed-off-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-06-25x86, asm, cleanup: Replace open-coded control register values with symbolicH. Peter Anvin3-3/+3
Clean up an unnecessary open-coded control register values. Signed-off-by: H. Peter Anvin <[email protected]> Link: http://lkml.kernel.org/n/[email protected]
2013-06-25x86, processor-flags: Fix the datatypes and add bit number definesH. Peter Anvin1-50/+104
The control registers are unsigned long (32 bits on i386, 64 bits on x86-64), and so make that manifest in the data type for the various constants. Add defines with a _BIT suffix which defines the bit number, as opposed to the bit mask. This should resolve some issues with ~bitmask that Linus discovered. Reported-by: Linus Torvalds <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Link: http://lkml.kernel.org/n/[email protected]
2013-06-25x86: Rename X86_CR4_RDWRGSFS to X86_CR4_FSGSBASEH. Peter Anvin3-3/+3
Rename X86_CR4_RDWRGSFS to X86_CR4_FSGSBASE to match the SDM. Signed-off-by: H. Peter Anvin <[email protected]> Cc: Marcelo Tosatti <[email protected]> Cc: Gleb Natapov <[email protected]> Link: http://lkml.kernel.org/n/[email protected]
2013-06-25x86, flags: Rename X86_EFLAGS_BIT1 to X86_EFLAGS_FIXEDH. Peter Anvin6-6/+6
Bit 1 in the x86 EFLAGS is always set. Name the macro something that actually tries to explain what it is all about, rather than being a tautology. Signed-off-by: H. Peter Anvin <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Gleb Natapov <[email protected]> Cc: Paolo Bonzini <[email protected]> Link: http://lkml.kernel.org/n/[email protected]
2013-06-25macvtap: fix recovery from gup errorsMichael S. Tsirkin1-2/+4
get user pages might fail partially in macvtap zero copy mode. To recover we need to put all pages that we got, but code used a wrong index resulting in double-free errors. Reported-by: Brad Hubbard <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>