linux-kernel - Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <70fde2ba-b38f-a0d6-bc2d-89c074afd466@linux.intel.com>
Date:   Mon, 27 Jul 2020 15:30:16 +0800
From:   "Tanwar, Rahul" <rahul.tanwar@...ux.intel.com>
To:     Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     linux-pwm@...r.kernel.org, thierry.reding@...il.com,
        p.zabel@...gutronix.de, robh+dt@...nel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        andriy.shevchenko@...el.com, songjun.Wu@...el.com,
        cheol.yong.kim@...el.com, qi-ming.wu@...el.com,
        rahul.tanwar.linux@...il.com
Subject: Re: [PATCH v5 2/2] Add PWM fan controller driver for LGM SoC


Hi Uwe,

On 27/7/2020 3:01 pm, Uwe Kleine-König wrote:
> On Mon, Jul 27, 2020 at 02:04:56PM +0800, Tanwar, Rahul wrote:
>> Hi Uwe,
>>
>> On 24/7/2020 12:15 am, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Thu, Jul 23, 2020 at 03:44:18PM +0800, Rahul Tanwar wrote:
>>>> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>>>> +			 const struct pwm_state *state)
>>>> +{
>>>> +	struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
>>>> +	u32 duty_cycle, val;
>>>> +	int ret;
>>>> +
>>>> +	if (!state->enabled) {
>>>> +		ret = lgm_pwm_enable(chip, 0);
>>>> +		return ret;
>>>> +	}
>>>> +
>>>> +	/*
>>>> +	 * HW only supports NORMAL polarity
>>>> +	 * HW supports fixed period which can not be changed/configured by user
>>>> +	 */
>>>> +	if (state->polarity != PWM_POLARITY_NORMAL ||
>>>> +	    state->period != pc->period)
>>>> +		return -EINVAL;
>>> At least for state->polarity you have to check before state->enabled, as
>>> the expectation on
>>>
>>>         .enabled = false
>>>         .polarity = PWM_POLARITY_INVERSED
>>>
>>> is that the output becomes constant high. Also as confirmed at the end
>>> of v4, state->period < pc->period was the right check to do.
>> For below case:
>>
>> .enabled = false
>> .polarity = PWM_POLARITY_INVERSED
>>
>> Since our HW does not support inversed polarity, the output for above case
>> is expected to be constant low. And if we disable PWM before checking for
>> polarity, the output becomes constant low. The code just does that. Sorry,
>> i could not understand what is wrong with the code. It looks correct to me.
> As your hardware can only support normal polarity, the code must have:
>
> 	if (state->polarity != PWM_POLARITY_NORMAL)
> 		return -EINVAL;
>
> 	if (!state->enabled) {
> 		ret = lgm_pwm_enable(chip, 0);
> 		return ret;
> 	}
>
> That's what I meant writing: "At least for state->polarity you have to
> check before state->enabled".

Ok, i understand your point now.

>> Given the fact that we support fixed period, if we allow
>> state->period < pc->period case then the duty cycle will be evaluated as
>> higher than the requested one because the state->period is lesser than
>> the actual fixed period supported by the HW. Can you please elaborate
>> on why you think we should allow state->period < pc->period case?
> You should not allow it. In v4 you had:
>
> 	if (state->polarity != PWM_POLARITY_NORMAL ||
> 	    state->period < pc->period)
> 		return -EINVAL;
>
> That's the right thing to do (even though I was unsettled at one point
> and wrote it was wrong). The check in v5 with state->period !=
> pc->period is wrong.
>

Does that mean we should allow state->period >= pc->period cases?
If the state->period is greater than HW supported pc->period and
if we allow it then the duty cycle will again be evaluated to be
incorrect/higher than requested duty cycle. Am i missing something
else? Thanks.

Regards,
Rahul