Linux kernel documentation tree maintained by Jonathan Corbet http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v4.6.7 2016-07-27T15:42:15+00:00 2016-07-27T15:42:15+00:00 Jiri Slaby jslaby@suse.cz 2016-06-10T08:54:32+00:00 urn:sha1:41fa543b014a75e71668177efc421da58728c414 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: ... [<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80 [<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90 [<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340 [<ffffffff8140f5b8>] kobject_add+0x68/0xb0 [<ffffffff8140f631>] kobject_create_and_add+0x31/0x70 [<ffffffff8157a703>] module_add_driver+0xc3/0xd0 [<ffffffff8155e5d4>] bus_add_driver+0x154/0x280 [<ffffffff815604c0>] driver_register+0x60/0xe0 [<ffffffff8145bed0>] __pci_register_driver+0x60/0x70 [<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146] [<ffffffffa0033011>] 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 <jslaby@suse.cz> Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2016-06-08T01:23:42+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-05-20T21:09:49+00:00 urn:sha1:41103c791d4af40643183825d61eb7bb34282ac3 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 <grygorii.strashko@ti.com> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2016-06-08T01:23:37+00:00 Ulf Hansson ulf.hansson@linaro.org 2016-04-08T11:10:23+00:00 urn:sha1:9a2a66b526e58a772b34da22af0075157cf9a7e4 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 <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2016-05-13T09:36:10+00:00 Mark Brown broonie@kernel.org 2016-05-13T09:36:10+00:00 urn:sha1:2a2cd5219023ea2e485c3e37486c24177a6da55a 2016-05-13T09:36:09+00:00 Mark Brown broonie@kernel.org 2016-05-13T09:36:09+00:00 urn:sha1:066a0e0b49afe9531f0e464a1ef05b24d0c95986 2016-05-06T11:16:22+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2016-05-06T11:16:22+00:00 urn:sha1:5f2f88e330e7ee2d2d7c5e0984b86108b00ac800 * pm-opp-fixes: PM / OPP: Remove useless check * pm-cpufreq-fixes: intel_pstate: Fix intel_pstate_get() cpufreq: intel_pstate: Fix HWP on boot CPU after system resume cpufreq: st: enable selective initialization based on the platform * pm-cpuidle-fixes: ARM: cpuidle: Pass on arm_cpuidle_suspend()'s return value 2016-05-04T23:42:19+00:00 Viresh Kumar viresh.kumar@linaro.org 2016-05-04T13:19:55+00:00 urn:sha1:21f8a99ce61b2d4b74bd425a5bf7e9efbe162788 Regulators are optional for devices using OPPs and the OPP core shouldn't be printing any errors for such missing regulators. It was fine before the commit 0c717d0f9cb4, but that failed to update this part of the code to remove an 'always true' check and an extra unwanted print message. Fix that now. Fixes: 0c717d0f9cb4 (PM / OPP: Initialize regulator pointer to an error value) Reported-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2016-04-27T21:40:02+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2016-04-27T11:04:20+00:00 urn:sha1:0224a4a30b57385a60065aa598181868881d8fc6 Since fwnode may hold ERR_PTR(-ENODEV) or it may be NULL, the fwnode type checks is_of_node(), is_acpi_node() and is is_pset_node() need to consider it. Using IS_ERR_OR_NULL() to check it. Fixes: 0d67e0fa1664 (device property: fix for a case of use-after-free) Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2016-04-15T09:11:45+00:00 Jack Pham jackp@codeaurora.org 2016-04-15T06:37:26+00:00 urn:sha1:dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 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 <jackp@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org 2016-04-07T20:23:47+00:00 Strashko, Grygorii grygorii.strashko@ti.com 2016-04-06T11:45:53+00:00 urn:sha1:16669befb0772eac6a76057b7010ba5b419c0e78 Now wakeirq stops working for device if wakeup option for this device will be reconfigured through sysfs, like: echo disabled > /sys/devices/platform/extcon_usb1/power/wakeup echo enabled > /sys/devices/platform/extcon_usb1/power/wakeup Once above set of commands is executed the device's wakeup_source opject will be recreated and dev->power.wakeup->wakeirq field will contain NULL. As result, device_wakeup_arm_wake_irqs() will not arm wakeirq for the affected device. Hece, lets try to fix it in the following way: check for dev->wakeirq field when device_wakeup_attach() is called and if !NULL re-attach wakeirq to the device Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>