linux-stable.git/drivers/base, branch linux-4.8.y

firmware: fix usermode helper fallback loading

2017-01-09T07:21:55+00:00

commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.

When you use the firmware usermode helper fallback with a timeout value set to a
value greater than INT_MAX (2147483647) a cast overflow issue causes the
timeout value to go negative and breaks all usermode helper loading. This
regression was introduced through commit 68ff2a00dbf5 ("firmware_loader:
handle timeout via wait_for_completion_interruptible_timeout()") on kernel
v4.0.

The firmware_class drivers relies on the firmware usermode helper
fallback as a mechanism to look for firmware if the direct filesystem
search failed only if:

  a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):

  Then all of these callers will rely on the fallback mechanism in case
  the firmware is not found through an initial direct filesystem lookup:

  o request_firmware()
  o request_firmware_into_buf()
  o request_firmware_nowait()

  b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):

  Then only callers using request_firmware_nowait() with the second
  argument set to false, this explicitly is requesting the UMH firmware
  fallback to be relied on in case the first filesystem lookup fails.

  Using Coccinelle SmPL grammar we have identified only two drivers
  explicitly requesting the UMH firmware fallback mechanism:

  - drivers/firmware/dell_rbu.c
  - drivers/leds/leds-lp55xx-common.c

Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
biggest impact of this regression are users of the dell_rbu and
leds-lp55xx-common device driver which required the UMH to find their
respective needed firmwares.

The default timeout for the UMH is set to 60 seconds always, as of
commit 68ff2a00dbf5 ("firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()") the timeout was bumped
to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
value was also used if the timeout was configured by a user to 0.

The following works:

echo 2147483647 > /sys/class/firmware/timeout

But both of the following set the timeout to MAX_JIFFY_OFFSET even if
we display 0 back to userspace:

echo 2147483648 > /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

echo 0> /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
another cast with simple_strtol().

This fixes the secondary cast (the first one is simple_strtol() but its an
issue only by forcing an implicit limit) by re-using the timeout variable and
only setting retval in appropriate cases.

Lastly worth noting systemd had ripped out the UMH firmware fallback
mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
("udev: remove userspace firmware loading support"), so as of systemd v217.

Signed-off-by: Yves-Alexis Perez 
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez 
Cc: Ming Lei 
Cc: Bjorn Andersson 
Cc: Greg Kroah-Hartman 
Acked-by: Luis R. Rodriguez 
Reviewed-by: Bjorn Andersson 
[mcgrof@kernel.org: gave commit log a whole lot of love]
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

driver core: fix race between creating/querying glue dir and its cleanup

2017-01-06T10:16:25+00:00

commit cebf8fd16900fdfd58c0028617944f808f97fe50 upstream.

The global mutex of 'gdp_mutex' is used to serialize creating/querying
glue dir and its cleanup. Turns out it isn't a perfect way because
part(kobj_kset_leave()) of the actual cleanup action() is done inside
the release handler of the glue dir kobject. That means gdp_mutex has
to be held before releasing the last reference count of the glue dir
kobject.

This patch moves glue dir's cleanup after kobject_del() in device_del()
for avoiding the race.

Cc: Yijing Wang 
Reported-by: Chandra Sekhar Lingutla 
Signed-off-by: Ming Lei 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

2017-01-06T10:16:23+00:00

commit 91291d9ad92faa65a56a9a19d658d8049b78d3d4 upstream.

Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.

This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table->dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.

But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.

This patch attempts to fix this problem by returning a pointer to the
opp_table from dev_pm_opp_set_regulator() and using that as the
parameter to dev_pm_opp_put_regulator(). This ensures that the
dev_pm_opp_put_regulator() doesn't fail to find the opp table.

Note that similar design problem also exists with other
dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
so we don't need to update them for now.

Reported-by: Joonyoung Shim 
Signed-off-by: Stephen Boyd 
Signed-off-by: Viresh Kumar 
[ Viresh: Wrote commit log and tested on exynos 5250 ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails

2016-11-26T08:56:57+00:00

commit 6f75c3fd56daf547d684127a7f83c283c3c160d1 upstream.

Consider two devices, A and B, where B is a child of A, and B utilizes
asynchronous suspend (it does not matter whether A is sync or async). If
B fails to suspend_noirq() or suspend_late(), or is interrupted by a
wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
variable. However, device A does not (immediately) check the async_error
variable; it may continue to run its own suspend_noirq()/suspend_late()
callback. This is bad.

We can resolve this problem by doing our error and wakeup checking
(particularly, for the async_error flag) after waiting for children to
suspend, instead of before. This also helps align the logic for the noirq and
late suspend cases with the logic in __device_suspend().

It's easy to observe this erroneous behavior by, for example, forcing a
device to sleep a bit in its suspend_noirq() (to ensure the parent is
waiting for the child to complete), then return an error, and watch the
parent suspend_noirq() still get called. (Or similarly, fake a wakeup
event at the right (or is it wrong?) time.)

Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
Fixes: 28b6fd6e3779 (PM / sleep: Asynchronous threads for suspend_noirq)
Reported-by: Jeffy Chen 
Signed-off-by: Brian Norris 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

platform: don't return 0 from platform_get_irq[_byname]() on error

2016-10-28T07:45:19+00:00

commit e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af upstream.

of_irq_get[_byname]() return 0 iff  irq_create_of_mapping() call fails.
Returning both  error code and 0 on failure is a sign of a misdesigned API,
it makes the failure check unnecessarily complex and error prone. We should
rely  on the platform IRQ resource in this case, not return 0,  especially
as 0 can be  a valid  IRQ resource too...

Fixes: aff008ad813c ("platform_get_irq: Revert to platform_get_resource if of_irq_get fails")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Greg Kroah-Hartman

drivers: base: dma-mapping: page align the size when unmap_kernel_range

2016-10-22T10:40:22+00:00

commit 85714108e673cdebf1b96abfd50fb02a29e37577 upstream.

When dma_common_free_remap, the input parameter 'size' may not
be page aligned. And, met kernel warning when doing iommu dma
for usb on i.MX8 platform:
"
WARNING: CPU: 0 PID: 869 at mm/vmalloc.c:70 vunmap_page_range+0x1cc/0x1d0()
Modules linked in:
CPU: 0 PID: 869 Comm: kworker/u8:2 Not tainted 4.1.12-00444-gc5f9d1d-dirty #147
Hardware name: Freescale i.MX8DV Sabreauto (DT)
Workqueue: ci_otg ci_otg_work
Call trace:
[] dump_backtrace+0x0/0x124
[] show_stack+0x10/0x1c
[] dump_stack+0x84/0xc8
[] warn_slowpath_common+0x98/0xd0
[] warn_slowpath_null+0x14/0x20
[] vunmap_page_range+0x1c8/0x1d0
[] unmap_kernel_range+0x20/0x88
[] dma_common_free_remap+0x74/0x84
[] __iommu_free_attrs+0x9c/0x178
[] ehci_mem_cleanup+0x140/0x194
[] ehci_stop+0x8c/0xdc
[] usb_remove_hcd+0xf0/0x1cc
[] host_stop+0x1c/0x58
[] ci_otg_work+0xdc/0x120
[] process_one_work+0x134/0x33c
[] worker_thread+0x13c/0x47c
[] kthread+0xd8/0xf0
"

For dma_common_pages_remap:
dma_common_pages_remap
   |->get_vm_area_caller
        |->__get_vm_area_node
            |->size = PAGE_ALIGN(size);   Round up to page aligned

So, in dma_common_free_remap, we also need a page aligned size,
pass 'PAGE_ALIGN(size)' to unmap_kernel_range.

Signed-off-by: Peng Fan 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'regmap-fix-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2016-09-23T18:50:49+00:00

Pull regmap fix from Mark Brown:
 "A fix for an issue with double locking that was introduced earlier
  this release.  I'd missed in review that we were already in a locked
  region when trying to drop part of the cache"

* tag 'regmap-fix-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: fix deadlock on _regmap_raw_write() error path

regmap: fix deadlock on _regmap_raw_write() error path

2016-09-22T10:24:22+00:00

Commit 815806e39bf6 ("regmap: drop cache if the bus transfer error")
added a call to regcache_drop_region() to error path in
_regmap_raw_write(). However that path runs with regmap lock taken,
and regcache_drop_region() tries to re-take it, causing a deadlock.
Fix that by calling map->cache_ops->drop() directly.

Signed-off-by: Nikita Yushchenko 
Signed-off-by: Mark Brown

PM / runtime: Use _rcuidle for runtime suspend tracepoints

2016-09-16T00:59:58+00:00

Further testing with false negatives suppressed by commit 293e2421fe25
("rcu: Remove superfluous versions of rcu_read_lock_sched_held()")
identified a few more unprotected uses of RCU from the idle loop.
Because RCU actively ignores idle-loop code (for energy-efficiency
reasons, among other things), using RCU from the idle loop can result
in too-short grace periods, in turn resulting in arbitrary misbehavior.

The affected function is rpm_suspend().

The resulting lockdep-RCU splat is as follows:

------------------------------------------------------------------------

Warning from omap3

===============================
[ INFO: suspicious RCU usage. ]
4.6.0-rc5-next-20160426+ #1112 Not tainted
-------------------------------
include/trace/events/rpm.h:63 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
 #0:  (&(&dev->power.lock)->rlock){-.-...}, at: [] __pm_runtime_suspend+0x54/0x84

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1112
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb0/0xe4)
[] (dump_stack) from [] (rpm_suspend+0x604/0x7e4)
[] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84)
[] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70)
[] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244)
[] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
[] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
[] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
[] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
[] (start_kernel) from [<8000807c>] (0x8000807c)

------------------------------------------------------------------------

Reported-by: Tony Lindgren 
Signed-off-by: Paul E. McKenney 
Tested-by: Tony Lindgren 
Tested-by: Guenter Roeck 
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki

Merge tag 'regmap-fix-v4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2016-09-06T18:02:36+00:00

Pull regmap fixes from Mark Brown:
 "Several fixes here, the main one being the change from Lars-Peter
  which I'd been letting soak in -next since the merge window in case it
  uncovered further issues as it's a minimal fix rather than a change
  addressing the root cause of the problems (which would've been too
  invasive for -rc):

   - The biggest change is a fix from Lars-Peter to ensure that we don't
     create overlapping rbtree nodes which in turn avoids returning
     corrupt cache values to users, fixing some issues that were exposed
     by some recent optimisations with certain access patterns but had
     been present for a long time.

   - A fix from Elaine Zhang to stop us updating the cache if we get an
     I/O error when writing to the hardware.

   - A fix fromm Maarten ter Huurne to avoid uninitialized defaults in
     cases where we have non-readable registers but are initializing the
     cache by reading from the device"

* tag 'regmap-fix-v4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: drop cache if the bus transfer error
  regmap: rbtree: Avoid overlapping nodes
  regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw