linux-kernel - Re: [PATCH] staging: greybus: introduce pwm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2a74f279-9fed-ac3e-da7d-521b3197c321@189.cn>
Date:   Fri, 11 Feb 2022 15:48:53 +0800
From:   Song Chen <chensong_2000@....cn>
To:     Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     johan@...nel.org, elder@...nel.org, gregkh@...uxfoundation.org,
        thierry.reding@...il.com, lee.jones@...aro.org,
        greybus-dev@...ts.linaro.org, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org
Subject: Re: [PATCH] staging: greybus: introduce pwm_ops::apply

Hello Uwe,

Thanks for the explain, now i can understand it better.

So, if redefining period and duty as u64 in gb_pwm_config_request is an 
acceptable solution, i will send patch v2.

BR

Song

在 2022/2/11 15:16, Uwe Kleine-König 写道:
> Hello ,
> 
> On Fri, Feb 11, 2022 at 11:06:33AM +0800, Song Chen wrote:
>> 在 2022/2/10 18:03, Uwe Kleine-König 写道:
>>> On Thu, Feb 10, 2022 at 05:05:02PM +0800, Song Chen wrote:
>>>> Introduce apply in pwm_ops to replace legacy operations,
>>>> like enable, disable, config and set_polarity.
>>>>
>>>> Signed-off-by: Song Chen <chensong_2000@....cn>
>>>> ---
>>>>    drivers/staging/greybus/pwm.c | 46 +++++++++++++++--------------------
>>>>    1 file changed, 19 insertions(+), 27 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
>>>> index 891a6a672378..e1889cf979b2 100644
>>>> --- a/drivers/staging/greybus/pwm.c
>>>> +++ b/drivers/staging/greybus/pwm.c
>>>> @@ -204,43 +204,35 @@ static void gb_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
>>>>    	gb_pwm_deactivate_operation(pwmc, pwm->hwpwm);
>>>>    }
>>>> -static int gb_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
>>>> -			 int duty_ns, int period_ns)
>>>> -{
>>>> -	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
>>>> -
>>>> -	return gb_pwm_config_operation(pwmc, pwm->hwpwm, duty_ns, period_ns);
>>>> -};
>>>> -
>>>> -static int gb_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
>>>> -			       enum pwm_polarity polarity)
>>>> +static int gb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>>>> +			const struct pwm_state *state)
>>>>    {
>>>> +	int ret;
>>>>    	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
>>>> -	return gb_pwm_set_polarity_operation(pwmc, pwm->hwpwm, polarity);
>>>> -};
>>>> -
>>>> -static int gb_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
>>>> -{
>>>> -	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
>>>> +	/* set period and duty cycle*/
>>>> +	ret = gb_pwm_config_operation(pwmc, pwm->hwpwm, state->duty_cycle, state->period);
>>>
>>> gb_pwm_config_operation's 3rd parameter is an u32, so you're loosing
>>> bits here as state->duty_cycle is a u64. Ditto for period.
>>
>> originally, pwm_apply_state --> pwm_apply_legacy --> gb_pwm_config -->
>> gb_pwm_config_operation is also loosing bits, does it mean greybus can live
>> with that?
> 
> This is true, I tried to address that, but Thierry had concerns.
> (https://lore.kernel.org/all/20210312212119.1342666-1-u.kleine-koenig@pengutronix.de/
> was the patch I suggested.)
> 
>> Or redefine gb_pwm_config_request, switch duty and period to __le64?
> 
> Don't use __le64, this is only for representing (little endian) register
> values. u64 would be the right one.
> 
>>> Also it would be nice if you go from
>>>
>>> 	.duty_cycle = A, .period = B, .enabled = 1
>>>
>>> to
>>>
>>> 	.duty_cycle = C, .period = D, .enabled = 0
>>>
>>> that C/D wasn't visible on the output pin. So please disable earlier
>>> (but keep enable at the end).
>>
>> sorry, i don't quite understand this part,
> 
> To reexplain: If your hardware is configured for
> 
> 	.duty_cycle = A, .period = B, .enabled = 1
> 
> and pwm_apply is called with
> 
> 	.duty_cycle = C, .period = D, .enabled = 0
> 
> you configured the registers for .duty_cycle and .period first and only
> then disable the PWM. This usually results in glitches because the
> hardware shortly runs with
> 
> 	.duty_cycle = C, .period = D, .enabled = 1
> 
> . So the idea is, to disable before configuring duty and period if the
> eventual goal is a disabled state.

understood, thanks.

> 
>> but is below code looking good to
>> you?
>>
>> static int gb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> 			const struct pwm_state *state)
>> {
>> 	int err;
>> 	bool enabled = pwm->state.enabled;
>> 	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
>>
>> 	/* set polarity */
>> 	if (state->polarity != pwm->state.polarity) {
>> 		if (enabled) {
>> 			gb_pwm_disable_operation(pwmc, pwm->hwpwm);
>> 			enabled = false;
>> 		}
>> 		err = gb_pwm_set_polarity_operation(pwmc, pwm->hwpwm, state->polarity);
>> 		if (err)
>> 			return err;
>> 	}
>>
>> 	if (!state->enabled) {
>> 		if (enabled)
>> 			gb_pwm_disable_operation(pwmc, pwm->hwpwm);
>> 		return 0;
>> 	}
>>
>> 	/* set period and duty cycle*/
>> 	err = gb_pwm_config_operation(pwmc, pwm->hwpwm, state->duty_cycle, state->period);
>> 	if (err)
>> 		return err;
>>
>> 	/* enable/disable */
>> 	if (!enabled)
>> 		return gb_pwm_enable_operation(pwmc, pwm->hwpwm);
>>
>> 	return 0;
>> }
> 
> This looks good.
> 
> Best regards
> Uwe
>