summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-12-20nfsd: kill stale comment about simple_fill_super() requirementsAl Viro
That went into the tree back in 2005; the comment used to be true for predecessor of simple_fill_super() that happened to live in nfsd; that one didn't take care to skip the array entries with NULL ->name, so it could not tolerate any gaps. That had been fixed in 2003 when nfsd_fill_super() had been abstracted into simple_fill_super(); if Neil's patch lived out of tree during that time, he probably replaced the name of function when rebasing it and didn't notice that restriction in question was no longer there. Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-12-20bfs_add_entry(): get rid of pointless ->d_name.len checksAl Viro
First of all, any dentry getting here would have passed bfs_lookup(), so it it passed ENAMETOOLONG check there, there's no need to repeat it. And we are not going to get dentries with zero name length - that check ultimately comes from ext2 and it's as pointless here as it used to be there. Acked-by: Tigran Aivazian <aivazian.tigran@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-12-20nilfs2: d_obtain_alias(ERR_PTR(...)) will do the right thing...Al Viro
Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-12-20zonefs: d_splice_alias() will do the right thing on ERR_PTR() inodeAl Viro
Acked-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-12-20pwm: Drop two unused API functionsUwe Kleine-König
These functions are unused. Also I think there is no valid use case where these are correct to be called. So drop them. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputsUwe Kleine-König
Even though the hardware only supports a single period for all PWM outputs, modifying the other (disabled) outputs's period is strange and wrong. Only the pwm core is supposed to update these values. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20timers: Fix nextevt calculation when no timers are pendingAnna-Maria Behnsen
When no timer is queued into an empty timer base, the next_expiry will not be updated. It was originally calculated as base->clk + NEXT_TIMER_MAX_DELTA When the timer base stays empty long enough (> NEXT_TIMER_MAX_DELTA), the next_expiry value of the empty base suggests that there is a timer pending soon. This might be more a kind of a theoretical problem, but the fix doesn't hurt. Use only base->next_expiry value as nextevt when timers are pending. Otherwise nextevt will be jiffies + NEXT_TIMER_MAX_DELTA. As all information is in place, update base->next_expiry value of the empty timer base as well. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-13-anna-maria@linutronix.de
2023-12-20timers: Rework idle logicThomas Gleixner
To improve readability of the code, split base->idle calculation and expires calculation into separate parts. While at it, update the comment about timer base idle marking. Thereby the following subtle change happens if the next event is just one jiffy ahead and the tick was already stopped: Originally base->is_idle remains true in this situation. Now base->is_idle turns to false. This may spare an IPI if a timer is enqueued remotely to an idle CPU that is going to tick on the next jiffy. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-12-anna-maria@linutronix.de
2023-12-20timers: Use already existing function for forwarding timer baseAnna-Maria Behnsen
There is an already existing function for forwarding the timer base. Forwarding the timer base is implemented directly in get_next_timer_interrupt() as well. Remove the code duplication and invoke __forward_timer_base() instead. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-11-anna-maria@linutronix.de
2023-12-20timers: Split out forward timer base functionalityAnna-Maria Behnsen
Forwarding timer base is done when the next expiry value is calculated and when a new timer is enqueued. When the next expiry value is calculated the jiffies value is already available and does not need to be reread a second time. Splitting out the forward timer base functionality to make it executable via both contextes - those where jiffies are already known and those, where jiffies need to be read. No functional change. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-10-anna-maria@linutronix.de
2023-12-20timers: Clarify check in forward_timer_base()Anna-Maria Behnsen
The current check whether a forward of the timer base is required can be simplified by using an already existing comparison function which is easier to read. The related comment is outdated and was not updated when the check changed in commit 36cd28a4cdd0 ("timers: Lower base clock forwarding threshold"). Use time_before_eq() for the check and replace the comment by copying the comment from the same check inside get_next_timer_interrupt(). Move the precious information of the outdated comment to the proper place in __run_timers(). No functional change. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-9-anna-maria@linutronix.de
2023-12-20timers: Move store of next event into __next_timer_interrupt()Anna-Maria Behnsen
Both call sites of __next_timer_interrupt() store the return value directly in base->next_expiry. Move the store into __next_timer_interrupt() and to make its purpose more clear, rename the function to next_expiry_recalc(). No functional change. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-8-anna-maria@linutronix.de
2023-12-20timers: Do not IPI for deferrable timersAnna-Maria Behnsen
Deferrable timers do not prevent CPU from going idle and are not taken into account on idle path. Sending an IPI to a remote CPU when a new first deferrable timer was enqueued will wake up the remote CPU but nothing will be done regarding the deferrable timers. Drop IPI completely when a new first deferrable timer was enqueued. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-7-anna-maria@linutronix.de
2023-12-20tracing/timers: Add tracepoint for tracking timer base is_idle flagAnna-Maria Behnsen
When debugging timer code the timer tracepoints are very important. There is no tracepoint when the is_idle flag of the timer base changes. Instead of always adding manually trace_printk(), add tracepoints which can be easily enabled whenever required. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-6-anna-maria@linutronix.de
2023-12-20tracing/timers: Enhance timer_start tracepointAnna-Maria Behnsen
For starting a timer, the timer is enqueued into a bucket of the timer wheel. The bucket expiry is the defacto expiry of the timer but it is not equal the timer expiry because of increasing granularity when bucket is in a higher level of the wheel. To be able to figure out in a trace whether a timer expired in time or not, the bucket expiry time is required as well. Add bucket expiry time to the timer_start tracepoint and thereby simplify the arguments. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-5-anna-maria@linutronix.de
2023-12-20tick-sched: Warn when next tick seems to be in the pastAnna-Maria Behnsen
When the next tick is in the past, the delta between basemono and the next tick gets negativ. But the next tick should never be in the past. The negative effect of a wrong next tick might be a stop of the tick and timers might expire late. To prevent expensive debugging when changing underlying code, add a WARN_ON_ONCE into this code path. To prevent complete misbehaviour, also reset next_tick to basemono in this case. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-4-anna-maria@linutronix.de
2023-12-20tick/sched: Cleanup confusing variablesAnna-Maria Behnsen
tick_nohz_stop_tick() contains the expires (u64 variable) and tick (ktime_t) variable. In the beginning the value of expires is written to tick. Afterwards none of the variables is changed. They are only used for checks. Drop the not required variable tick and use always expires instead. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-3-anna-maria@linutronix.de
2023-12-20tick-sched: Fix function names in commentsAnna-Maria Behnsen
When referencing functions in comments, it might be helpful to use full function names (including the prefix) to be able to find it when grepping. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20231201092654.34614-2-anna-maria@linutronix.de
2023-12-20pwm: meson: Simplify using dev_err_probe()Uwe Kleine-König
Using dev_err_probe() emitting an error message mentioning a return value and returning that value can be done in a single statement. Make use of that to simplify the probe part of the driver. This has the additional advantage to emit the symbolic name for the error instead of the integer error value. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stmpe: Silence duplicate error messagesUwe Kleine-König
stmpe_reg_read() and stmpe_reg_write() already emit error messages when they fail. So the extra error messages in the pwm driver are only little useful. They are useful in some situation, as they give a bit of context to the failing register write. So don't remove them but degrade them to dev_dbg(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20cpu/hotplug: Increase the number of dynamic statesxiaoming Wang
The dynamically allocatable hotplug state space can be exhausted by the existing drivers and infrastructure which install CPU hotplug states dynamically. That prevents new drivers and infrastructure from installing dynamically allocated states. Increase the size of the CPUHP_AP_ONLINE_DYN state by 10 to make room. Signed-off-by: Xiaoming Wang <xiaoming.wang@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20231219033411.816100-1-xiaoming.wang@intel.com
2023-12-20pwm: Reduce number of pointer dereferences in pwm_device_request()Uwe Kleine-König
pwm->chip and pwm->chip->ops are used several times in this function. Introduce local variables for these. There is no semantical change, but with ARCH=arm, allmodconfig and gcc-13 bloat-o-meter reports a slight improvement: add/remove: 1/1 grow/shrink: 1/1 up/down: 8/-36 (-28) Function old new delta pwm_apply_state 476 480 +4 __initcall__kmod_core__307_1092_pwm_debugfs_init4 - 4 +4 __initcall__kmod_core__307_1090_pwm_debugfs_init4 4 - -4 pwm_request_from_chip 628 596 -32 Total: Before=15091, After=15063, chg -0.19% Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: crc: Use consistent variable naming for driver dataUwe Kleine-König
All but one local variable of type pointer to struct crystalcove_pwm are called "crc_pwm", the one outlier is called "pwm" which is usually reserved for variables of type pointer to struct pwm_device. So rename that one "pwm" to "crc_pwm" for consistency. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: omap-dmtimer: Drop lockingUwe Kleine-König
The pwm driver only provides a single PWM line, so there are no concurrent calls of the callbacks from different consumers. A single consumer is expected not to do concurrent calls into the pwm framework. So there is nothing to serialize and the lock can go away. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20dt-bindings: pwm: ti,pwm-omap-dmtimer: Update binding for yamlTony Lindgren
Update for yaml and remove the old txt binding. As we can replace most of the custom timer API with standard Linux frameworks such as clock framework, let's tag the properties for ti,prescaler and ti,clock-source as deprecated. Cc: <linux-pwm@vger.kernel.org> Cc: Nishanth Menon <nm@ti.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20media: pwm-ir-tx: Trigger edges from hrtimer interrupt contextSean Young
This makes the generated IR much more precise. Before this change, the driver is unreliable and many users opted to use gpio-ir-tx instead. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: bcm2835: Allow PWM driver to be used in atomic contextSean Young
clk_get_rate() may do a mutex lock. Fetch the clock rate once, and prevent rate changes using clk_rate_exclusive_get(). Signed-off-by: Sean Young <sean@mess.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Make it possible to apply PWM changes in atomic contextSean Young
Some PWM devices require sleeping, for example if the pwm device is connected over I2C. However, many PWM devices could be used from atomic context, e.g. memory mapped PWM. This is useful for, for example, the pwm-ir-tx driver which requires precise timing. Sleeping causes havoc with the generated IR signal. Since not all PWM devices can support atomic context, we also add a pwm_might_sleep() function to check if is not supported. Signed-off-by: Sean Young <sean@mess.org> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: renesas: Remove unused includeSean Young
No mutex is used in this driver. Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Replace ENOTSUPP with EOPNOTSUPPSean Young
According to Documentation/dev-tools/checkpatch.rst ENOTSUPP is not recommended and EOPNOTSUPP should be used instead. Signed-off-by: Sean Young <sean@mess.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()Sean Young
In order to introduce a pwm api which can be used from atomic context, we will need two functions for applying pwm changes: int pwm_apply_might_sleep(struct pwm *, struct pwm_state *); int pwm_apply_atomic(struct pwm *, struct pwm_state *); This commit just deals with renaming pwm_apply_state(), a following commit will introduce the pwm_apply_atomic() function. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Stop referencing pwm->chipThierry Reding
Drivers have access to the chip via a function argument already, so there is no need to reference it via the PWM device. Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Update kernel doc for struct pwm_chipUwe Kleine-König
Commit c572f3b9c8b7 ("pwm: Replace PWM chip unique base by unique ID") changed the members of struct pwm_chip, but failed to update the documentation accordingly. Catch up and document the new member and drop description for the two removed ones. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20dt-bindings: pwm: remove Xinlei's mailMichael Walle
Xinlei Lee's mail is bouncing: <xinlei.lee@mediatek.com>: host mailgw02.mediatek.com[216.200.240.185] said: 550 Relaying mail to xinlei.lee@mediatek.com is not allowed (in reply to RCPT TO command) Remove it. Signed-off-by: Michael Walle <mwalle@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stm32: Fix enable count for clk in .probe()Philipp Zabel
Make the driver take over hardware state without disabling in .probe() and enable the clock for each enabled channel. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> [ukleinek: split off from a patch that also implemented .get_state()] Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm") Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stm32: Implement .get_state()Philipp Zabel
Implement the &pwm_ops->get_state callback so drivers can inherit PWM state set by the bootloader. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> [ukl: split off from a patch that also fixes clk enable count in .probe()] Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stm32: Use hweight32 in stm32_pwm_detect_channelsPhilipp Zabel
Use hweight32() to count the CCxE bits in stm32_pwm_detect_channels(). Since the return value is assigned to chip.npwm, change it to unsigned int as well. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stm32: Make ch parameter unsignedPhilipp Zabel
The channel parameter is only ever set to pwm->hwpwm. Make it unsigned int as well. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stm32: Replace write_ccrx with regmap_writePhilipp Zabel
The TIM_CCR1...4 registers are consecutive, so replace the switch case with a simple calculation. Since ch is known to be in the 0...3 range (it is set to hwpwm < npwm <= 4), drop the unnecessary error handling. The return value was not checked anyway. What remains does not warrant keeping the write_ccrx() function around, so instead call regmap_write() directly at the singular call site. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Use device_get_match_data()Rob Herring
Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. As these drivers only do DT based matching, of_match_device() will never return NULL if we've gotten to probe(). Therefore, the NULL check and error returns can be dropped. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: Narrow scope of struct pwm_device pointerUwe Kleine-König
In the expression determining the size of the allocation for chip->pwms it's more natural to use sizeof(*chip->pwms) than sizeof(*pwm). With that changed, the variable pwm is only used in a for loop and its scope can be reduced accordingly. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: jz4740: Add trailing \n to error messagesUwe Kleine-König
Error messages are supposed to end in \n. Add the line terminator to the two error messages that lack this. Suggested-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: tiehrpwm: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: tiecap: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stm32: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding __maybe_unused can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: stm32-lp: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding __maybe_unused can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: samsung: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: imx-tpm: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding __maybe_unused can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: dwc: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-20pwm: brcmstb: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsUwe Kleine-König
This macro has the advantage over SIMPLE_DEV_PM_OPS that we don't have to care about when the functions are actually used, so the corresponding #ifdef can be dropped. Also make use of pm_ptr() to discard all PM related stuff if CONFIG_PM isn't enabled. Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>