linux-stable.git/include/linux/pwm.h, branch v3.16.75

pwm: Fix deadlock warning when removing PWM device

2019-09-23T20:11:34+00:00

commit 347ab9480313737c0f1aaa08e8f2e1a791235535 upstream.

This patch fixes deadlock warning if removing PWM device
when CONFIG_PROVE_LOCKING is enabled.

This issue can be reproceduced by the following steps on
the R-Car H3 Salvator-X board if the backlight is disabled:

 # cd /sys/class/pwm/pwmchip0
 # echo 0 > export
 # ls
 device  export  npwm  power  pwm0  subsystem  uevent  unexport
 # cd device/driver
 # ls
 bind  e6e31000.pwm  uevent  unbind
 # echo e6e31000.pwm > unbind

[   87.659974] ======================================================
[   87.666149] WARNING: possible circular locking dependency detected
[   87.672327] 5.0.0 #7 Not tainted
[   87.675549] ------------------------------------------------------
[   87.681723] bash/2986 is trying to acquire lock:
[   87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
[   87.694528]
[   87.694528] but task is already holding lock:
[   87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[   87.707405]
[   87.707405] which lock already depends on the new lock.
[   87.707405]
[   87.715574]
[   87.715574] the existing dependency chain (in reverse order) is:
[   87.723048]
[   87.723048] -> #1 (pwm_lock){+.+.}:
[   87.728017]        __mutex_lock+0x70/0x7e4
[   87.732108]        mutex_lock_nested+0x1c/0x24
[   87.736547]        pwm_request_from_chip.part.6+0x34/0x74
[   87.741940]        pwm_request_from_chip+0x20/0x40
[   87.746725]        export_store+0x6c/0x1f4
[   87.750820]        dev_attr_store+0x18/0x28
[   87.754998]        sysfs_kf_write+0x54/0x64
[   87.759175]        kernfs_fop_write+0xe4/0x1e8
[   87.763615]        __vfs_write+0x40/0x184
[   87.767619]        vfs_write+0xa8/0x19c
[   87.771448]        ksys_write+0x58/0xbc
[   87.775278]        __arm64_sys_write+0x18/0x20
[   87.779721]        el0_svc_common+0xd0/0x124
[   87.783986]        el0_svc_compat_handler+0x1c/0x24
[   87.788858]        el0_svc_compat+0x8/0x18
[   87.792947]
[   87.792947] -> #0 (kn->count#58){++++}:
[   87.798260]        lock_acquire+0xc4/0x22c
[   87.802353]        __kernfs_remove+0x258/0x2c4
[   87.806790]        kernfs_remove_by_name_ns+0x50/0xa0
[   87.811836]        remove_files.isra.1+0x38/0x78
[   87.816447]        sysfs_remove_group+0x48/0x98
[   87.820971]        sysfs_remove_groups+0x34/0x4c
[   87.825583]        device_remove_attrs+0x6c/0x7c
[   87.830197]        device_del+0x11c/0x33c
[   87.834201]        device_unregister+0x14/0x2c
[   87.838638]        pwmchip_sysfs_unexport+0x40/0x4c
[   87.843509]        pwmchip_remove+0xf4/0x13c
[   87.847773]        rcar_pwm_remove+0x28/0x34
[   87.852039]        platform_drv_remove+0x24/0x64
[   87.856651]        device_release_driver_internal+0x18c/0x21c
[   87.862391]        device_release_driver+0x14/0x1c
[   87.867175]        unbind_store+0xe0/0x124
[   87.871265]        drv_attr_store+0x20/0x30
[   87.875442]        sysfs_kf_write+0x54/0x64
[   87.879618]        kernfs_fop_write+0xe4/0x1e8
[   87.884055]        __vfs_write+0x40/0x184
[   87.888057]        vfs_write+0xa8/0x19c
[   87.891887]        ksys_write+0x58/0xbc
[   87.895716]        __arm64_sys_write+0x18/0x20
[   87.900154]        el0_svc_common+0xd0/0x124
[   87.904417]        el0_svc_compat_handler+0x1c/0x24
[   87.909289]        el0_svc_compat+0x8/0x18
[   87.913378]
[   87.913378] other info that might help us debug this:
[   87.913378]
[   87.921374]  Possible unsafe locking scenario:
[   87.921374]
[   87.927286]        CPU0                    CPU1
[   87.931808]        ----                    ----
[   87.936331]   lock(pwm_lock);
[   87.939293]                                lock(kn->count#58);
[   87.945120]                                lock(pwm_lock);
[   87.950599]   lock(kn->count#58);
[   87.953908]
[   87.953908]  *** DEADLOCK ***
[   87.953908]
[   87.959821] 4 locks held by bash/2986:
[   87.963563]  #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
[   87.971044]  #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
[   87.978872]  #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
[   87.988001]  #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[   87.995481]
[   87.995481] stack backtrace:
[   87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
[   88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
[   88.012791] Call trace:
[   88.015235]  dump_backtrace+0x0/0x190
[   88.018891]  show_stack+0x14/0x1c
[   88.022204]  dump_stack+0xb0/0xec
[   88.025514]  print_circular_bug.isra.32+0x1d0/0x2e0
[   88.030385]  __lock_acquire+0x1318/0x1864
[   88.034388]  lock_acquire+0xc4/0x22c
[   88.037958]  __kernfs_remove+0x258/0x2c4
[   88.041874]  kernfs_remove_by_name_ns+0x50/0xa0
[   88.046398]  remove_files.isra.1+0x38/0x78
[   88.050487]  sysfs_remove_group+0x48/0x98
[   88.054490]  sysfs_remove_groups+0x34/0x4c
[   88.058580]  device_remove_attrs+0x6c/0x7c
[   88.062671]  device_del+0x11c/0x33c
[   88.066154]  device_unregister+0x14/0x2c
[   88.070070]  pwmchip_sysfs_unexport+0x40/0x4c
[   88.074421]  pwmchip_remove+0xf4/0x13c
[   88.078163]  rcar_pwm_remove+0x28/0x34
[   88.081906]  platform_drv_remove+0x24/0x64
[   88.085996]  device_release_driver_internal+0x18c/0x21c
[   88.091215]  device_release_driver+0x14/0x1c
[   88.095478]  unbind_store+0xe0/0x124
[   88.099048]  drv_attr_store+0x20/0x30
[   88.102704]  sysfs_kf_write+0x54/0x64
[   88.106359]  kernfs_fop_write+0xe4/0x1e8
[   88.110275]  __vfs_write+0x40/0x184
[   88.113757]  vfs_write+0xa8/0x19c
[   88.117065]  ksys_write+0x58/0xbc
[   88.120374]  __arm64_sys_write+0x18/0x20
[   88.124291]  el0_svc_common+0xd0/0x124
[   88.128034]  el0_svc_compat_handler+0x1c/0x24
[   88.132384]  el0_svc_compat+0x8/0x18

The sysfs unexport in pwmchip_remove() is completely asymmetric
to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9
("pwm: Unexport children before chip removal") is a strong indication
that this was wrong to begin with. We should just move
pwmchip_sysfs_unexport() where it belongs, which is right after
pwmchip_sysfs_unexport_children(). In that case, we do not need
separate functions anymore either.

We also really want to remove sysfs irrespective of whether or not
the chip will be removed as a result of pwmchip_remove(). We can only
assume that the driver will be gone after that, so we shouldn't leave
any dangling sysfs files around.

This warning disappears if we move pwmchip_sysfs_unexport() to
the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
That way it is also outside of the pwm_lock section, which indeed
doesn't seem to be needed.

Moving the pwmchip_sysfs_export() call outside of that section also
seems fine and it'd be perfectly symmetric with pwmchip_remove() again.

So, this patch fixes them.

Signed-off-by: Phong Hoang 
[shimoda: revise the commit log and code]
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Fixes: 0733424c9ba9 ("pwm: Unexport children before chip removal")
Signed-off-by: Yoshihiro Shimoda 
Tested-by: Hoan Nguyen An 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
Reviewed-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Ben Hutchings

pwm: Unexport children before chip removal

2017-02-23T03:53:57+00:00

commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.

Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.

Signed-off-by: David Hsu 
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding 
Signed-off-by: Ben Hutchings

pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members

2014-05-21T09:19:36+00:00

Now that PWM_LOOKUP is not used anymore, modify it to initialize all the
members of struct pwm_lookup.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Thierry Reding

pwm: add period and polarity to struct pwm_lookup

2014-05-21T07:03:07+00:00

Add period and polarity members to struct pwm_lookup so that platforms
using the lookup table can be treated the same way as those using the
device tree.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Thierry Reding

pwm: Remove obsolete HAVE_PWM Kconfig symbol

2014-02-10T10:16:39+00:00

Before we had the PWM framework we used to have a barebone PWM api. The
HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify
the PWM API is present in the kernel. Since the last legacy driver is gone
the HAVE_PWM symbol can go aswell.

Signed-off-by: Sascha Hauer 
Cc: Dmitry Torokhov 
Cc: Eric Miao 
Cc: Haojian Zhuang 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Thierry Reding 
Cc: linux-pwm@vger.kernel.orig
Cc: Russell King 
Cc: Ralf Baechle 
Signed-off-by: Thierry Reding

pwm: Add sysfs interface

2013-06-21T09:32:51+00:00

Add a simple sysfs interface to the generic PWM framework.

  /sys/class/pwm/
  `-- pwmchipN/           for each PWM chip
      |-- export          (w/o) ask the kernel to export a PWM channel
      |-- npwm            (r/o) number of PWM channels in this PWM chip
      |-- pwmX/           for each exported PWM channel
      |   |-- duty_cycle  (r/w) duty cycle (in nanoseconds)
      |   |-- enable      (r/w) enable/disable PWM
      |   |-- period      (r/w) period (in nanoseconds)
      |   `-- polarity    (r/w) polarity of PWM (normal/inversed)
      `-- unexport        (w/o) return a PWM channel to the kernel

Based on work by Lars Poeschel.

Signed-off-by: H Hartley Sweeten 
Cc: Thierry Reding 
Cc: Lars Poeschel 
Cc: Ryan Mallon 
Cc: Rob Landley 
Signed-off-by: Thierry Reding

Merge tag 'for-3.9-rc1' of git://gitorious.org/linux-pwm/linux-pwm

2013-02-26T17:34:29+00:00

Pull PWM changes from Thierry Reding:
 "A new driver has been added to support the PWM mode of the timer
  counter blocks found on Atmel AT91 SoCs.  The VT8500 driver now
  supports changing the PWM signal polarity and the TI drivers (EHRPWM
  and ECAP) gained suspend and resume functionality.

  User drivers can now query the core for whether access to a PWM device
  will sleep (if the PWM chip is on a slow bus such as I2C or SPI).

  The pwm-backlight driver now handles the backlight BL_CORE_FBBLANK
  state in addition to the FB layer's blanking states.

  To round things off, a few fixes and cleanups are also included"

* tag 'for-3.9-rc1' of git://gitorious.org/linux-pwm/linux-pwm:
  pwm: twl: Use to_twl() instead of container_of()
  pwm: tegra: assume CONFIG_OF
  pwm_backlight: Validate dft_brightness in main probe function
  pwm: Export pwm_{set,get}_chip_data()
  pwm: Make Kconfig entries more consistent
  pwm: Add can_sleep property to drivers
  pwm: Add pwm_can_sleep() as exported API to users
  pwm-backlight: handle BL_CORE_FBBLANK state
  pwm: pwm-tiecap: Low power sleep support
  pwm: pwm-tiehrpwm: Low power sleep support
  pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
  pwm: vt8500: Add polarity support
  pwm: vt8500: Register write busy test performed incorrectly
  pwm: atmel: add Timer Counter Block PWM driver

pwm: Add devm_of_pwm_get() as exported API for users

2013-02-02T01:47:05+00:00

When booted with DT users can use devm version of of_pwm_get() to benefit
from automatic resource release.

Signed-off-by: Peter Ujfalusi 
Acked-by: Thierry Reding 
Signed-off-by: Bryan Wu

pwm: core: Rename of_pwm_request() to of_pwm_get() and export it

2013-02-02T01:47:05+00:00

Allow client driver to use of_pwm_get() to get the PWM they need. This
is needed for drivers which handle more than one PWM separately, like
leds-pwm driver, which have:

pwmleds {
	compatible = "pwm-leds";
	kpad {
		label = "omap4::keypad";
		pwms = <&twl_pwm 0 7812500>;
		max-brightness = <127>;
	};

	charging {
		label = "omap4:green:chrg";
		pwms = <&twl_pwmled 0 7812500>;
		max-brightness = <255>;
	};
};

in the dts files.

Signed-off-by: Peter Ujfalusi 
Acked-by: Thierry Reding 
Signed-off-by: Bryan Wu

pwm: Correct parameter name in header for *pwm_get() functions

2013-02-02T01:47:05+00:00

To synchronize the header file definition and the actual code. In the code
the consumer parameter is named as con_id, change the header file and replace
consumer -> con_id in the parameter list.

Signed-off-by: Peter Ujfalusi 
Ackedy-by: Thierry Reding 
Signed-off-by: Bryan Wu