linux-stable.git/drivers/base, branch v3.16.45

PM / QoS: Fix memory leak on resume_latency.notifiers

2017-06-05T20:17:11+00:00

commit e84b4a84e52d4cd8770b4242cd09df0133333f63 upstream.

Since commit 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device
PM QoS type) we reassign "c" to point at qos->latency_tolerance before
freeing c->notifiers, but the notifiers field of latency_tolerance is
never used.

Restore the original behaviour of freeing the notifiers pointer on
qos->resume_latency, which is used, and fix the following kmemleak
warning.

unreferenced object 0xed9dba00 (size 64):
  comm "kworker/0:1", pid 36, jiffies 4294670128 (age 15202.983s)
  hex dump (first 32 bytes):
    00 00 00 00 04 ba 9d ed 04 ba 9d ed 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x74/0xb8
    [] kmem_cache_alloc_trace+0x170/0x25c
    [] dev_pm_qos_constraints_allocate+0x3c/0xe4
    [] __dev_pm_qos_add_request+0x84/0x1a0
    [] dev_pm_qos_add_request+0x3c/0x54
    [] usb_hub_create_port_device+0x110/0x2b8
    [] hub_probe+0xadc/0xc80
    [] usb_probe_interface+0x1b4/0x260
    [] driver_probe_device+0x198/0x40c
    [] __device_attach_driver+0x8c/0x98
    [] bus_for_each_drv+0x8c/0x9c
    [] __device_attach+0x98/0x138
    [] device_initial_probe+0x14/0x18
    [] bus_probe_device+0x30/0x88
    [] device_add+0x430/0x554
    [] usb_set_configuration+0x660/0x6fc

Fixes: 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type)
Signed-off-by: John Keeping 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

drivers: base: dma-mapping: Fix typo in dmam_alloc_non_coherent comments

2017-03-16T02:26:27+00:00

commit cd74da957ba2d03787ede1c22bbb183d9c728aad upstream.

The function we are wrapping is named dma_alloc_noncoherent, and
not dma_alloc_non_coherent.

Fixes: 9ac7849e35f70 ("devres: device resource management")
Signed-off-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

regmap: cache: Remove unused 'blksize' variable

2017-03-16T02:26:25+00:00

commit daaadbf07433b15c452b2ff411a293b2ccd98e03 upstream.

Commit 2cbbb579bcbe ("regmap: Add the LZO cache support") introduced
'blksize' in  regcache_lzo_read() and regcache_lzo_write(), that is
set but not used. Compiling with W=1 gives the following warnings,
fix them.

drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_read’:
drivers/base/regmap/regcache-lzo.c:239:9: warning: variable ‘blksize’ set but not used [-Wunused-but-set-variable]
  size_t blksize, tmp_dst_len;
         ^
drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_write’:
drivers/base/regmap/regcache-lzo.c:278:9: warning: variable ‘blksize’ set but not used [-Wunused-but-set-variable]
  size_t blksize, tmp_dst_len;
         ^

These are harmless warnings and are only being fixed to reduce the
noise with W=1 in the kernel.

Fixes: 2cbbb579bcbe ("regmap: Add the LZO cache support")
Cc: Dimitris Papastamos 
Cc: Mark Brown 
Signed-off-by: Kirtika Ruchandani 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

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

2017-02-23T03:54:32+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: Ben Hutchings

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

2017-02-23T03:53:56+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 
Signed-off-by: Ben Hutchings

isa: Call isa_bus_init before dependent ISA bus drivers register

2016-08-22T21:38:16+00:00

commit 32a5a0c047343b11f581f663a2309cf43d13466f upstream.

The isa_bus_init function must be called before drivers which utilize
the ISA bus driver are registered. A race condition for initilization
exists if device_initcall is used (the isa_bus_init callback is placed
in the same initcall level as dependent drivers which use module_init).
This patch ensures that isa_bus_init is called first by utilizing
postcore_initcall in favor of device_initcall.

Fixes: a5117ba7da37 ("[PATCH] Driver model: add ISA bus")
Cc: Rene Herman 
Signed-off-by: William Breathitt Gray 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

base: make module_create_drivers_dir race-free

2016-08-22T21:38:16+00:00

commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 upstream.

Modules which register drivers via standard path (driver_register) in
parallel can cause a warning:
WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
sysfs: cannot create duplicate filename '/module/saa7146/drivers'
Modules linked in: hexium_gemini(+) mxb(+) ...
...
Call Trace:
...
 [] sysfs_warn_dup+0x62/0x80
 [] sysfs_create_dir_ns+0x77/0x90
 [] kobject_add_internal+0xb4/0x340
 [] kobject_add+0x68/0xb0
 [] kobject_create_and_add+0x31/0x70
 [] module_add_driver+0xc3/0xd0
 [] bus_add_driver+0x154/0x280
 [] driver_register+0x60/0xe0
 [] __pci_register_driver+0x60/0x70
 [] saa7146_register_extension+0x64/0x90 [saa7146]
 [] hexium_init_module+0x11/0x1000 [hexium_gemini]
...

As can be (mostly) seen, driver_register causes this call sequence:
  -> bus_add_driver
    -> module_add_driver
      -> module_create_drivers_dir
The last one creates "drivers" directory in /sys/module/<...>. When
this is done in parallel, the directory is attempted to be created
twice at the same time.

This can be easily reproduced by loading mxb and hexium_gemini in
parallel:
while :; do
  modprobe mxb &
  modprobe hexium_gemini
  wait
  rmmod mxb hexium_gemini saa7146_vv saa7146
done

saa7146 calls pci_register_driver for both mxb and hexium_gemini,
which means /sys/module/saa7146/drivers is to be created for both of
them.

Fix this by a new mutex in module_create_drivers_dir which makes the
test-and-create "drivers" dir atomic.

I inverted the condition and removed 'return' to avoid multiple
unlocks or a goto.

Signed-off-by: Jiri Slaby 
Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed)
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

PM / sleep: Handle failures in device_suspend_late() consistently

2016-08-22T21:38:03+00:00

commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream.

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Tested-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-08-22T21:37:51+00:00

commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f upstream.

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the ->runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

regmap: cache: Fix typo in cache_bypass parameter description

2016-08-22T21:37:47+00:00

commit 267c85860308d36bc163c5573308cd024f659d7c upstream.

Setting the flag 'cache_bypass' will bypass the cache not the hardware.
Fix this comment here.

Fixes: 0eef6b0415f5 ("regmap: Fix doc comment")
Signed-off-by: Andrew F. Davis 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings