[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220819080748.c2qprsddcvjb7vkx@pengutronix.de>
Date: Fri, 19 Aug 2022 10:07:48 +0200
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Tamseel Shams <m.shams@...sung.com>
Cc: thierry.reding@...il.com, lee.jones@...aro.org,
linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org,
alim.akhtar@...sung.com
Subject: Re: [PATCH v2] pwm: Fixes dpm_run_callback() error in
pwm_apply_state()
On Fri, Aug 19, 2022 at 10:04:59AM +0530, Tamseel Shams wrote:
> Return invalid argument error from pwm_apply_state()
> call when 'period is not set' or 'duty_cycle is greater
> than period' only when PWM is enabled, so as to fix the
> dpm_run_callback() error seen on exynos SoC during
> Suspend
>
> There may be situation when PWM is exported using sysfs,
> but at that point period is not set for PWM. At this
> point if we do suspend, then during pwm_apply_state
> function call from pwm_class_suspend, it checks whether
> period is set or not. It is not set now, so it returns
> an invalid argument error which issues dpm_run_callback()
> error
>
> Suggested-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> Signed-off-by: Tamseel Shams <m.shams@...sung.com>
I still consider this a band aid and I think there is need for prudence
here. Did you verify that all lowlevel drivers handle a state that is
now allowed in a sane way? If you did, you missed at least
pwm-bcm2835.c, I guess there are more but I stopped checking.
So while this change might make sense in the future, I think it's wrong
to do it now.
I stand to the request to find out why pwm->state is strange. Maybe you
just have to fix your .get_state() callback.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists