linux-toradex.git/drivers/base, branch v4.4.29

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

2016-10-28T07:01:26+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:26:55+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

base: make module_create_drivers_dir race-free

2016-07-27T16:47:32+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

PM / sleep: Handle failures in device_suspend_late() consistently

2016-06-08T01:14:37+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: Greg Kroah-Hartman

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-06-08T01:14:34+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: Greg Kroah-Hartman

regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case

2016-05-19T00:06:48+00:00

commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 upstream.

Specifically for the case of reads that use the Extended Register
Read Long command, a multi-byte read operation is broken up into
8-byte chunks.  However the call to spmi_ext_register_readl() is
incorrectly passing 'val_size', which if greater than 8 will
always fail.  The argument should instead be 'len'.

Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces")
Signed-off-by: Jack Pham 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

PM / Domains: Fix removal of a subdomain

2016-05-04T21:48:51+00:00

commit beda5fc1ff9b527059290a97b672d2ee0eb7b92f upstream.

Commit 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use
before removing) added a test to ensure that a subdomain is not a
master to another subdomain or if any devices are using the subdomain
before removing. This change incorrectly used the "slave_links" list to
determine if the subdomain is a master to another subdomain, where it
should have been using the "master_links" list instead. The
"slave_links" list will never be empty for a subdomain and so a
subdomain can never be removed. Fix this by testing if the
"master_links" list is empty instead.

Fixes: 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use before removing)
Signed-off-by: Jon Hunter 
Reviewed-by: Thierry Reding 
Acked-by: Ulf Hansson 
Acked-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / OPP: Initialize u_volt_min/max to a valid value

2016-05-04T21:48:51+00:00

commit c88c395f4a6485f23f81e385c79945d68bcd5c5d upstream.

We kept u_volt_min/max initialized to 0, when only the target voltage is
present in DT, instead of the target/min/max triplet.

This didn't go well with the regulator framework, as on few calls the
min voltage was set to target and max was set to 0 and so resulted in a
kernel crash like below:

kernel BUG at ../drivers/regulator/core.c:216!

[] (regulator_check_voltage) from [] (regulator_set_voltage_unlocked+0x58/0x230)
[] (regulator_set_voltage_unlocked) from [] (regulator_set_voltage+0x28/0x54)
[] (regulator_set_voltage) from [] (_set_opp_voltage+0x30/0x98)
[] (_set_opp_voltage) from [] (dev_pm_opp_set_rate+0xf0/0x28c)
[] (dev_pm_opp_set_rate) from [] (__cpufreq_driver_target+0x184/0x2b4)
[] (__cpufreq_driver_target) from [] (dbs_check_cpu+0x1b0/0x1f4)
[] (dbs_check_cpu) from [] (cpufreq_governor_dbs+0x324/0x5c4)
[] (cpufreq_governor_dbs) from [] (__cpufreq_governor+0xe4/0x1ec)
[] (__cpufreq_governor) from [] (cpufreq_init_policy+0x64/0x8c)
[] (cpufreq_init_policy) from [] (cpufreq_online+0x2fc/0x708)
[] (cpufreq_online) from [] (subsys_interface_register+0x94/0xd8)
[] (subsys_interface_register) from [] (cpufreq_register_driver+0x14c/0x19c)
[] (cpufreq_register_driver) from [] (dt_cpufreq_probe+0x70/0xec)
[] (dt_cpufreq_probe) from [] (platform_drv_probe+0x4c/0xb0)
[] (platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
[] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
[] (bus_add_driver) from [] (driver_register+0x78/0xf8)
[] (driver_register) from [] (do_one_initcall+0x90/0x1d8)
[] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2)

Fix that by initializing u_volt_min/max to the target voltage in such cases.

Reported-and-tested-by: Krzysztof Kozlowski 
Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings)
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

base/platform: Fix platform drivers with no probe callback

2016-02-17T20:30:55+00:00

commit 25cad69f21f5532d99e2ee73c8ab6512bcab614c upstream.

Since b8b2c7d845d5, platform_drv_probe() is called for all platform
devices. If drv->probe is NULL, and dev_pm_domain_attach() fails,
platform_drv_probe() will return the error code from dev_pm_domain_attach().

This causes real_probe() to enter the "probe_failed" path and set
dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume
success if both dev->bus->probe and drv->probe were missing. As a result,
a device and driver could be "bound" together just by matching their names;
this doesn't work any more after b8b2c7d845d5.

This may cause problems later for certain usage of platform_driver_register()
and platform_device_register_simple(). I observed a panic while loading
the tpm_tis driver with parameter "force=1" (i.e. registering tpm_tis as
a platform driver), because tpm_tis_init's assumption that the device
returned by platform_device_register_simple() was bound didn't hold any more
(tpmm_chip_alloc() dereferences chip->pdev->driver, causing panic).

This patch restores the previous (4.3.0 and earlier) behavior of
platform_drv_probe() in the case when the associated platform driver has
no "probe" function.

Fixes: b8b2c7d845d5 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally")
Signed-off-by: Martin Wilck 
Cc: Martin Fuzzey 
Acked-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

Merge branches 'powercap', 'pm-cpufreq' and 'pm-domains'

2015-12-14T21:58:57+00:00

* powercap:
  powercap / RAPL: fix BIOS lock check

* pm-cpufreq:
  cpufreq: intel_pstate: Minor cleanup for FRAC_BITS
  cpufreq: tegra: add regulator dependency for T124

* pm-domains:
  PM / Domains: Allow runtime PM callbacks to be re-used during system PM