linux-stable.git/drivers/base, branch v4.9.2

firmware: fix usermode helper fallback loading

2017-01-09T07:32:22+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

PM / OPP: Don't use OPP structure outside of rcu protected section

2017-01-06T09:40:15+00:00

commit dc39d06fcd7a4a82d72eae7b71e94e888b96d29e upstream.

The OPP structure must not be used out of the rcu protected section.
Cache the values to be used in separate variables instead.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Tested-by: Dave Gerlach 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

2017-01-06T09:40:15+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

Merge tag 'driver-core-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2016-11-13T18:22:07+00:00

Pull driver core fixes from Greg KH:
 "Here are two driver core fixes for 4.9-rc5.

  The first resolves an issue with some drivers not liking to be unbound
  and bound again (if CONFIG_DEBUG_TEST_DRIVER_REMOVE is enabled), which
  solves some reported problems with graphics and storage drivers. The
  other resolves a smatch error with the 4.9-rc1 driver core changes
  around this feature.

  Both have been in linux-next with no reported issues"

* tag 'driver-core-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  driver core: fix smatch warning on dev->bus check
  driver core: skip removal test for non-removable drivers

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

2016-11-11T00:29:09+00:00

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

driver core: fix smatch warning on dev->bus check

2016-10-31T15:15:22+00:00

Commit d42a09802174 (driver core: skip removal test for non-removable
drivers) introduced a smatch warning:

drivers/base/dd.c:386 really_probe()
         warn: variable dereferenced before check 'dev->bus' (see line 373)

Fix the warning by removing the dev->bus NULL check. dev->bus will never
be NULL, so the check was unnecessary.

Reported-by: Dan Carpenter 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

driver core: skip removal test for non-removable drivers

2016-10-31T15:15:22+00:00

Some drivers do not support removal/unbinding. These drivers should have
drv->suppress_bind_attrs set to true, so use that to skip the removal
test.

This doesn't fix anything reported so far, but should prevent some other
cases. Some drivers will need fixes to set suppress_bind_attrs to avoid
this test.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177021
Fixes: bea5b158ff0d ("driver core: add test of driver remove calls during probe")
Reported-by: Laszlo Ersek 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman

driver core: Make Kconfig text for DEBUG_TEST_DRIVER_REMOVE stronger

2016-10-27T15:47:12+00:00

The current state of driver removal is not great.
CONFIG_DEBUG_TEST_DRIVER_REMOVE finds lots of errors. The help text
currently undersells exactly how many errors this option will find. Add
a bit more description to indicate this option shouldn't be turned on
unless you actually want to debug driver removal. The text can be
changed later when more drivers are fixed up.

Signed-off-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman

memory-hotplug: fix store_mem_state() return value

2016-10-08T01:46:28+00:00

If store_mem_state() is called to online memory which is already online,
it will return 1, the value it got from device_online().

This is wrong because store_mem_state() is a device_attribute .store
function.  Thus a non-negative return value represents input bytes read.

Set the return value to -EINVAL in this case.

Link: http://lkml.kernel.org/r/1472743777-24266-1-git-send-email-arbab@linux.vnet.ibm.com
Signed-off-by: Reza Arbab 
Cc: Greg Kroah-Hartman 
Cc: Vlastimil Babka 
Cc: Vitaly Kuznetsov 
Cc: David Rientjes 
Cc: Yaowei Bai 
Cc: Joonsoo Kim 
Cc: Dan Williams 
Cc: Xishi Qiu 
Cc: David Vrabel 
Cc: Chen Yucong 
Cc: Andrew Banman 
Cc: Seth Jennings 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'pinctrl-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2016-10-05T18:37:14+00:00

Pull pin control updates from Linus Walleij:
"This is the bulk of pin control changes for the v4.9 cycle.

General improvements:

- nicer debugfs output with one pin/config pair per line.

- continued efforts to strictify module vs bool.

- constification and similar from Coccinelle engineers.

- return error from pinctrl_bind_pins()

- pulling in the ability to selectively disable mapping of unusable
IRQs from the GPIO subsystem.

New drivers:

- new driver for the Aspeed pin controller family: AST2400 (G4) and
AST2500 (G5) are supported. These are used by OpenBMC on the IBM
Witherspoon platform.

- new subdriver for the Allwinner sunxi GR8.

Driver improvements:

- drop default IRQ trigger types assigned during IRQ mapping on AT91
and Nomadik. This error was identified by improvements in the IRQ
core by Marc Zyngier.

- active high/low types on the GPIO IRQs for the ST pin controller.

- IRQ support on GPIOs on the STM32 pin controller.

- Renesas Super-H/ARM sh-pfc: continued massive developments.

- misc MXC improvements.

- SPDIF on the Allwiner A31 SoC

- IR remote and SPI NOR flash, NAND flash, I2C pins on the AMLogic
SoC.

- PWM pins on the Meson.

- do not map unusable IRQs (taken by BIOS) on the Intel Cherryview.

- add GPIO IRQ wakeup support to the Intel driver so we can wake up
from button pushes.

Deprecation:

- delete the obsolete STiH415/6 SoC support"

* tag 'pinctrl-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (75 commits)
pinctrl: qcom: fix masking of pinmux functions
pinctrl: intel: Configure GPIO chip IRQ as wakeup interrupts
pinctrl: cherryview: Convert to use devm_gpiochip_add_data()
pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain
gpiolib: Make it possible to exclude GPIOs from IRQ domain
pinctrl: nomadik: don't default-flag IRQs as falling
pinctrl: st: Remove obsolete platforms from pinctrl-st dt doc
pinctrl: st: Remove STiH415/6 SoC pinctrl driver support.
pinctrl: amlogic: gxbb: add i2c pins
pinctrl: amlogic: gxbb: add nand pins
pinctrl: stm32: add IRQ_DOMAIN_HIERARCHY dependency
pinctrl: amlogic: gxbb: add spi nor pins
pinctrl: sh-pfc: r8a7794: Implement voltage switching for SDHI
pinctrl: sh-pfc: r8a7791: Implement voltage switching for SDHI
pinctrl: sh-pfc: Add PORT_GP_24 helper macro
pinctrl: Fix "st,syscfg" definition for STM32 pinctrl
driver: base: pinctrl: return error from pinctrl_bind_pins()
pinctrl: meson-gxbb: add the missing SDIO interrupt pin
pinctrl: aspeed: fix regmap error handling
pinctrl: mediatek: constify gpio_chip structures
...