aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pwm/core.c
Commit message (Collapse)AuthorAgeFilesLines
...
* pwm: Make of_pwm_xlate_with_flags() work with #pwm-cells = <2>Uwe Kleine-König2021-05-251-4/+5
| | | | | | | | | | | | | | | | | | | | The two functions of_pwm_simple_xlate() and of_pwm_xlate_with_flags() are quite similar. of_pwm_simple_xlate() only supports two-cell PWM specifiers while of_pwm_xlate_with_flags() only supports PWM specifiers with 3 or more cells. The latter can easily be modified to behave identically to of_pwm_simple_xlate() for two-cell PWM specifiers. This is implemented here and allows to drop of_pwm_simple_xlate() in the next commit. There is a small detail that is different now in the two-cell specifier case in of_pwm_xlate_with_flags(): pwm->args.polarity is unconditionally initialized to PWM_POLARITY_NORMAL in the latter. I didn't find a case where this matters and doing that explicitly is the more robust approach. Signed-off-by: Uwe Kleine-König <[email protected]> [[email protected]: fix up checkpatch warnings] Signed-off-by: Thierry Reding <[email protected]>
* pwm: Drop function pwmchip_add_with_polarity()Uwe Kleine-König2021-03-221-22/+3
| | | | | | | | | | | | pwmchip_add() only calls pwmchip_add_with_polarity() and nothing else. All other users of pwmchip_add_with_polarity() are gone. So drop pwmchip_add_with_polarity() and move the code instead to pwmchip_add(). The initial assignment to pwm->state.polarity is dropped. In every correct usage of the PWM API this value is overwritten later anyhow. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Return -EINVAL for old-style drivers without .set_polarity callbackUwe Kleine-König2021-03-221-1/+1
| | | | | | | | | | Since commit 2b1c1a5d5148 ("pwm: Use -EINVAL for unsupported polarity") all drivers implementing the apply callback are unified to return -EINVAL if an unsupported polarity is requested. Do the same in the compat code for old-style drivers. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Always allocate PWM chip base ID dynamicallyUwe Kleine-König2021-03-221-18/+7
| | | | | | | | | | Since commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") all drivers use dynamic ID allocation explicitly. New drivers are supposed to do the same, so remove support for driver specified base IDs and drop all assignments in the low-level drivers. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: core: Use octal permissionSoham Biswas2020-12-171-1/+1
| | | | | | | | | | | | | | | Permission bits are easier readable in octal than with using the symbolic names. Fixes the following warning generated by checkpatch: WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. #1341: FILE: drivers/pwm/core.c:1341: + debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL, Signed-off-by: Soham Biswas <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Convert to use DEFINE_SEQ_ATTRIBUTE macroLiu Shixin2020-09-241-14/+3
| | | | | | | | Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code. Signed-off-by: Liu Shixin <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Convert period and duty cycle to u64Guru Das Srinagesh2020-06-171-7/+7
| | | | | | | | | | | | | | | Because period and duty cycle are defined as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Change their definitions to u64 in the structs of the PWM framework so that higher durations may be set. Also use the right format specifiers in debug prints in both core.c, pwm-stm32-lp.c as well as video/fbdev/ssd1307fb.c. Reported-by: kbuild test robot <[email protected]> Signed-off-by: Guru Das Srinagesh <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Add missing "CONFIG_" prefixKees Cook2020-06-041-1/+1
| | | | | | | | | | The IS_ENABLED() use was missing the CONFIG_ prefix which would have lead to skipping this code. Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers") Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Add missing '\n' in log messagesChristophe JAILLET2020-04-141-1/+1
| | | | | | | | | Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'. Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers") Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Make pwm_apply_state_debug() staticJason Yan2020-04-031-2/+2
| | | | | | | | | | | | Fix the following gcc warning: drivers/pwm/core.c:467:6: warning: symbol 'pwm_apply_state_debug' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Jason Yan <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Implement some checks for lowlevel driversUwe Kleine-König2020-03-301-7/+128
| | | | | | | | | | There are some expectations which the callbacks provided by lowlevel drivers should fulfill. Implement checks that help driver authors to get these semantics right. As these have some overhead the checks can be disabled using a Kconfig setting. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Implement tracing for .get_state() and .apply_state()Uwe Kleine-König2020-01-201-1/+8
| | | | | | | | | This allows to log all calls to the driver's lowlevel functions which simplifies debugging in some cases. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Read initial hardware state at request timeThierry Reding2019-12-091-3/+3
| | | | | | | | | | | | | | | | | | Drivers that support reading the hardware state (using ->get_state()) may want to rely on per-PWM data to do so. Defer reading the hardware state for the first time until the PWM has been requested and after drivers have had a chance to allocate per-PWM data. Conceptually this is also a more natural place to read the hardware state because the PWM core doesn't need to know the hardware state of a PWM unless there is a user for it. This also ensures that the state is read everytime a user requests a PWM. If the PWM changes between users for some reason, the PWM core will reload the state from hardware and keep its copy of the state up-to-date. Tested-by: Enric Balletbo i Serra <[email protected]> Tested-by: Michal Vokáč <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* Revert "pwm: Let pwm_get_state() return the last implemented state"Thierry Reding2019-10-211-8/+1
| | | | | | | | | | | | | | | | | | | | It turns out that commit 01ccf903edd6 ("pwm: Let pwm_get_state() return the last implemented state") causes backlight failures on a number of boards. The reason is that some of the drivers do not write the full state through to the hardware registers, which means that ->get_state() subsequently does not return the correct state. Consumers which rely on pwm_get_state() returning the current state will therefore get confused and subsequently try to program a bad state. Before this change can be made, existing drivers need to be more carefully audited and fixed to behave as the framework expects. Until then, keep the original behaviour of returning the software state that was applied rather than reading the state back from hardware. Reviewed-by: Uwe Kleine-König <[email protected]> Tested-by: Enric Balletbo i Serra <[email protected]> Tested-by: Michal Vokáč <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Ensure pwm_apply_state() doesn't modify the state argumentUwe Kleine-König2019-09-211-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is surprising for a PWM consumer when the variable holding the requested state is modified by pwm_apply_state(). Consider for example a driver doing: #define PERIOD 5000000 #define DUTY_LITTLE 10 ... struct pwm_state state = { .period = PERIOD, .duty_cycle = DUTY_LITTLE, .polarity = PWM_POLARITY_NORMAL, .enabled = true, }; pwm_apply_state(mypwm, &state); ... state.duty_cycle = PERIOD / 2; pwm_apply_state(mypwm, &state); For sure the second call to pwm_apply_state() should still have state.period = PERIOD and not something the hardware driver chose for a reason that doesn't necessarily apply to the second call. So declare the state argument as a pointer to a const type and adapt all drivers' .apply callbacks. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Let pwm_get_state() return the last implemented stateUwe Kleine-König2019-09-201-1/+8
| | | | | | | | | | When pwm_apply_state() is called the lowlevel driver usually has to apply some rounding because the hardware doesn't support nanosecond resolution. So let pwm_get_state() return the actually implemented state instead of the last applied one if possible. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Introduce local struct pwm_chip in pwm_apply_state()Uwe Kleine-König2019-09-201-11/+14
| | | | | | | | | pwm->chip is dereferenced several times in the pwm_apply_state() function. Introducing a local variable for it helps keeping some lines a bit shorter. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Fallback to the static lookup-list when acpi_pwm_get failsHans de Goede2019-08-081-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") made pwm_get unconditionally return the acpi_pwm_get return value if the device passed to pwm_get has an ACPI fwnode. But even if the passed in device has an ACPI fwnode, it does not necessarily have the necessary ACPI package defining its pwm bindings, especially since the binding / API of this ACPI package has only been introduced very recently. Up until now X86/ACPI devices which use a separate pwm controller for controlling their LCD screen's backlight brightness have been relying on the static lookup-list to get their pwm. pwm_get unconditionally returning the acpi_pwm_get return value breaks this, breaking backlight control on these devices. This commit fixes this by making pwm_get fall back to the static lookup-list if acpi_pwm_get returns -ENOENT. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96571 Reported-by: [email protected] Fixes: 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") Cc: Nikolaus Voss <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Nikolaus Voss <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* Merge tag 'pwm/for-5.3-rc1' of ↵Linus Torvalds2019-07-091-3/+169
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This set of changes contains a new driver for SiFive SoCs as well as enhancements to the core (device links are used to track dependencies between PWM providers and consumers, support for PWM controllers via ACPI, sysfs will now suspend/resume PWMs that it has claimed) and various existing drivers" * tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (37 commits) pwm: fsl-ftm: Make sure to unlock mutex on failure pwm: fsl-ftm: Use write protection for prescaler & polarity pwm: fsl-ftm: More relaxed permissions for updating period pwm: atmel-hlcdc: Add compatible for SAM9X60 HLCDC's PWM pwm: bcm2835: Improve precision of PWM leds: pwm: Support ACPI via firmware-node framework pwm: Add support referencing PWMs from ACPI pwm: rcar: Remove suspend/resume support pwm: sysfs: Add suspend/resume support pwm: Add power management descriptions pwm: meson: Add documentation to the driver pwm: meson: Add support PWM_POLARITY_INVERSED when disabling pwm: meson: Don't cache struct pwm_state internally pwm: meson: Read the full hardware state in meson_pwm_get_state() pwm: meson: Simplify the calculation of the pre-divider and count pwm: meson: Move pwm_set_chip_data() to meson_pwm_request() pwm: meson: Add the per-channel register offsets and bits in a struct pwm: meson: Add the meson_pwm_channel data to struct meson_pwm pwm: meson: Pass struct pwm_device to meson_pwm_calc() pwm: meson: Don't duplicate the polarity internally ...
| * pwm: Add support referencing PWMs from ACPINikolaus Voss2019-06-261-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In analogy to referencing a GPIO using the "gpios" property from ACPI, support referencing a PWM using the "pwms" property. ACPI entries must look like Package () {"pwms", Package () { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}} In contrast to the DT implementation, only _one_ PWM entry in the "pwms" property is supported. As a consequence "pwm-names"-property and con_id lookup aren't supported. Support for ACPI is added via the firmware-node framework which is an abstraction layer on top of ACPI/DT. To keep this patch clean, DT and ACPI paths are kept separate. The firmware-node framework could be used to unify both paths in a future patch. To support leds-pwm driver, an additional method devm_fwnode_pwm_get() which supports both ACPI and DT configuration is exported. Signed-off-by: Nikolaus Voss <[email protected]> [[email protected]: fix build failures for !ACPI] Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Add consumer device linkFabrice Gasnier2019-06-251-3/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a device link between the PWM consumer and the PWM provider. This enforces the PWM user to get suspended before the PWM provider. It allows proper synchronization of suspend/resume sequences: the PWM user is responsible for properly stopping PWM, before the provider gets suspended: see [1]. Add the device link in: - of_pwm_get() - pwm_get() - devm_*pwm_get() variants as it requires a reference to the device for the PWM consumer. [1] https://lkml.org/lkml/2019/2/5/770 Suggested-by: Thierry Reding <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Fabrice Gasnier <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* | treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 18Thomas Gleixner2019-05-211-14/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program see the file copying if not write to the free software foundation 675 mass ave cambridge ma 02139 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 52 file(s). Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Jilayne Lovejoy <[email protected]> Reviewed-by: Steve Winslow <[email protected]> Reviewed-by: Kate Stewart <[email protected]> Reviewed-by: Allison Randal <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
* pwm: Clear chip_data in pwm_put()Uwe Kleine-König2019-05-091-0/+1
| | | | | | | | | | After a PWM is disposed by its user the per chip data becomes invalid. Clear the data in common code instead of the device drivers to get consistent behaviour. Before this patch only three of nine drivers cleaned up here. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Fix deadlock warning when removing PWM devicePhong Hoang2019-03-201-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> [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 <[email protected]> Tested-by: Hoan Nguyen An <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Drop per-chip dbg_show callbackUwe Kleine-König2019-01-101-4/+1
| | | | | | | | | | This callback was introduced in commit 62099abf67a2 ("pwm: Add debugfs interface") in 2012 and up to now there is not a single user. So drop this unused code. Signed-off-by: Uwe Kleine-König <[email protected]> [[email protected]: remove kerneldoc for ->dbg_show()] Signed-off-by: Thierry Reding <[email protected]>
* pwm: Don't use memcmp() to compare state variablesUwe Kleine-König2019-01-101-1/+4
| | | | | | | | | | | | | Given that struct pwm_state is sparse (at least on some platforms), variables of this type might represent the same state because all fields are pairwise identical but still memcmp() returns a difference because some of the unused bits are different. To prevent surprises compare member by member instead of the whole occupied memory. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Silently error out on EPROBE_DEFERJerome Brunet2017-07-061-1/+3
| | | | | | | | | In of_pwm_get(), if we fail to get the PWM chip due to probe deferal, we shouldn't print an error message. Just be silent in this case. Signed-off-by: Jerome Brunet <[email protected]> Reviewed-by: Andreas Färber <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Try to load modules during pwm_get()Hans de Goede2017-01-301-0/+14
| | | | | | | | | | | | | | Add a module name string to the pwm_lookup struct and if specified try to load the module using request_module() if pwmchip_find_by_name() is unable to find the PWM chip. This is a last resort to work around drivers that can't - and can't be made to - deal with deferred probe. Signed-off-by: Hans de Goede <[email protected]> [[email protected]: rename new macro, reword commit message] [[email protected]: add comment explaining use-case] Signed-off-by: Thierry Reding <[email protected]>
* pwm: Don't hold pwm_lookup_lock longer than necessaryHans de Goede2017-01-301-10/+8
| | | | | | | | There is no need to hold pwm_lookup_lock after we're done with looping over pwm_lookup_list, so release it earlier. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Make the PWM_POLARITY flag in DTB optionalLothar Wassmann2017-01-301-10/+12
| | | | | | | | | | | | | | | | Change the PWM chip driver registration so that a chip driver that supports polarity inversion can still be used with DTBs that don't provide the polarity flag as part of the specifier. This is done to provide polarity inversion support for the pwm-imx driver without having to modify all existing DTS files. Signed-off-by: Lothar Wassmann <[email protected]> Signed-off-by: Bhuvanchandra DV <[email protected]> Suggested-by: Sascha Hauer <[email protected]> Signed-off-by: Lukasz Majewski <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Print error messages with pr_err() instead of pr_debug()Lothar Wassmann2017-01-301-2/+2
| | | | | | | | | | | Make the messages that are printed in case of fatal errors actually visible to the user without having to recompile the driver with debugging enabled. Signed-off-by: Lothar Waßmann <[email protected]> Signed-off-by: Bhuvanchandra DV <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* pwm: Remove pwm_can_sleep()Thierry Reding2017-01-041-12/+0
| | | | | | | The last user of this function has been removed, so it is no longer needed. Signed-off-by: Thierry Reding <[email protected]>
* pwm: Unexport children before chip removalDavid Hsu2016-09-051-0/+2
| | | | | | | | | | 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 <[email protected]> Fixes: 76abbdde2d95 ("pwm: Add sysfs interface") Signed-off-by: Thierry Reding <[email protected]>
* Merge branch 'for-4.8/capture' into for-nextThierry Reding2016-07-251-0/+27
|\
| * pwm: Add PWM capture supportLee Jones2016-06-101-0/+27
| | | | | | | | | | | | | | | | | | | | | | Supply a PWM capture callback op in order to pass back information obtained by running analysis on a PWM signal. This would normally (at least during testing) be called from the sysfs routines with a view to printing out PWM capture data which has been encoded into a string. Signed-off-by: Lee Jones <[email protected]> [[email protected]: make capture data unsigned int for symmetry] Signed-off-by: Thierry Reding <[email protected]>
* | pwm: Improve args checking in pwm_apply_state()Brian Norris2016-06-101-1/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems like in the process of refactoring pwm_config() to utilize the newly-introduced pwm_apply_state() API, some args/bounds checking was dropped. In particular, I noted that we are now allowing invalid period selections, e.g.: # echo 1 > /sys/class/pwm/pwmchip0/export # cat /sys/class/pwm/pwmchip0/pwm1/period 100 # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle [... driver may or may not reject the value, or trigger some logic bug ...] It's better to see: # echo 1 > /sys/class/pwm/pwmchip0/export # cat /sys/class/pwm/pwmchip0/pwm1/period 100 # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle -bash: echo: write error: Invalid argument This patch reintroduces some bounds checks in both pwm_config() (for its signed parameters; we don't want to convert negative values into large unsigned values) and in pwm_apply_state() (which fix the above described behavior, as well as other potential API misuses). Fixes: 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic updates") Signed-off-by: Brian Norris <[email protected]> Acked-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* Merge branch 'for-4.7/pwm-atomic' into for-nextThierry Reding2016-05-171-88/+130
|\
| * pwm: Add information about polarity, duty cycle and period to debugfsHeiko Stübner2016-05-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | The PWM states make it possible to also output the polarity, duty cycle and period information in the debugfs summary output. This simplifies gathering information about PWMs without needing to walk through the sysfs attributes of every PWM. Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> [[email protected]: use more spaces in debugfs output] Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Switch to the atomic APIBoris Brezillon2016-05-171-1/+4
| | | | | | | | | | | | | | | | Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls by pwm_get/apply_state(). Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Add core infrastructure to allow atomic updatesBoris Brezillon2016-05-171-66/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an ->apply() method to the pwm_ops struct to allow PWM drivers to implement atomic updates. This method is preferred over the ->enable(), ->disable() and ->config() methods if available. Add the pwm_apply_state() function to the PWM user API. Note that the pwm_apply_state() does not guarantee the atomicity of the update operation, it all depends on the availability and implementation of the ->apply() method. pwm_enable/disable/set_polarity/config() are now implemented as wrappers around the pwm_apply_state() function. pwm_adjust_config() is allowing smooth handover between the bootloader and the kernel. This function tries to adapt the current PWM state to the PWM arguments coming from a PWM lookup table or a DT definition without changing the duty_cycle/period proportion. Signed-off-by: Boris Brezillon <[email protected]> [[email protected]: fix a couple of typos] Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Add hardware readout infrastructureBoris Brezillon2016-05-171-0/+3
| | | | | | | | | | | | | | | | Add a ->get_state() function to the pwm_ops struct to let PWM drivers initialize the PWM state attached to a PWM device. Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Move the enabled/disabled info into pwm_stateBoris Brezillon2016-05-171-4/+9
| | | | | | | | | | | | | | | | | | Prepare the transition to PWM atomic update by moving the enabled and disabled state into the pwm_state struct. This way we can easily update the whole PWM state by copying the new state in the ->state field. Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Introduce the pwm_state conceptBoris Brezillon2016-05-171-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The PWM state, represented by its period, duty_cycle and polarity is currently directly stored in the PWM device. Declare a pwm_state structure embedding those field so that we can later use this struct to atomically update all the PWM parameters at once. All pwm_get_xxx() helpers are now implemented as wrappers around pwm_get_state(). Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Keep PWM state in sync with hardware stateBoris Brezillon2016-05-171-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before the introduction of pwm_args, the core was resetting the PWM period and polarity states to the reference values (those provided through the DT, a PWM lookup table or hardcoded in the driver). Now that all PWM users are correctly using pwm_args to configure their PWM device, we can safely remove the pwm_apply_args() call in pwm_get() and of_pwm_get(). We can also get rid of the pwm_set_period() call in pwm_apply_args(), because PWM users are now directly using pargs->period instead of pwm_get_period(). By doing that we avoid messing with the current PWM period. The only remaining bit in pwm_apply_args() is the initial polarity setting, and it should go away when all PWM users have been patched to use the atomic API (with this API the polarity will be set along with other PWM arguments when configuring the PWM). Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Get rid of pwm->lockBoris BREZILLON2016-05-171-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PWM devices are not protected against concurrent accesses. The lock in struct pwm_device might let PWM users think it is, but it's actually only protecting the enabled state. Removing this lock should be fine as long as all PWM users are aware that accesses to the PWM device have to be serialized, which seems to be the case for all of them except the sysfs interface. Patch the sysfs code by adding a lock to the pwm_export struct and making sure it's taken for all relevant accesses to the exported PWM device. Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
* | Merge branch 'for-4.7/pwm-args' into for-nextThierry Reding2016-05-171-6/+20
|\|
| * pwm: Fix pwm_apply_args() call sitesBoris Brezillon2016-05-171-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pwm_apply_args() is supposed to initialize a PWM device according to the arguments provided by the DT or the PWM lookup, but this function was called inside pwm_device_request(), which in turn was called before the core had a chance to initialize the pwm->args fields. Fix that by calling pwm_apply_args directly in pwm_get() and of_pwm_get() after initializing pwm->args field. This commit also fixes an invalid pointer dereference introduced by commit e39c0df1be5a ("pwm: Introduce the pwm_args concept"). Signed-off-by: Boris Brezillon <[email protected]> Fixes: e39c0df1be5a ("pwm: Introduce the pwm_args concept") Signed-off-by: Thierry Reding <[email protected]>
| * pwm: Introduce the pwm_args conceptBoris Brezillon2016-05-031-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the PWM core mixes the current PWM state with the per-platform reference config (specified through the PWM lookup table, DT definition or directly hardcoded in PWM drivers). Create a struct pwm_args to store this reference configuration, so that PWM users can differentiate between the current and reference configurations. Patch all places where pwm->args should be initialized. We keep the pwm_set_polarity/period() calls until all PWM users are patched to use pwm_args instead of pwm_get_period/polarity(). Signed-off-by: Boris Brezillon <[email protected]> [[email protected]: reword kerneldoc comments] Signed-off-by: Thierry Reding <[email protected]>
* | pwm: Use kcalloc() instead of kzalloc()Thierry Reding2016-05-031-1/+1
| | | | | | | | | | | | | | kcalloc() should be preferred for allocations of arrays over kzalloc() with multiplication. Signed-off-by: Thierry Reding <[email protected]>
* | pwm: Add missing newlineThierry Reding2016-05-031-0/+1
|/ | | | | | | checkpatch requires that declarations be separated from code by a blank line. Add one for readability and to silence the warning. Signed-off-by: Thierry Reding <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-04 05:02:06 +0000