All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>
To: "Uwe Kleine-König" <ukleinek@kernel.org>
Cc: "Lee Jones" <lee@kernel.org>, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Kamel Bouhara" <kamel.bouhara@bootlin.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Michael Walle" <mwalle@kernel.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-input@vger.kernel.org,
	linux-pwm@vger.kernel.org, andriy.shevchenko@intel.com,
	"Grégory Clement" <gregory.clement@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v12 04/10] pwm: max7360: Add MAX7360 PWM support
Date: Wed, 06 Aug 2025 14:07:15 +0200	[thread overview]
Message-ID: <DBVBZ48R7DNR.850O5X7MLMEF@bootlin.com> (raw)
In-Reply-To: <2msg7e7q42ocjewv35rytdtxwrfqrndpm2y5ustqeaeodencsd@nfdufgtevxte>

On Fri Aug 1, 2025 at 12:11 PM CEST, Uwe Kleine-König wrote:
> On Tue, Jul 22, 2025 at 06:23:48PM +0200, Mathieu Dubois-Briand wrote:
>> +static int max7360_pwm_round_waveform_tohw(struct pwm_chip *chip,
>> +					   struct pwm_device *pwm,
>> +					   const struct pwm_waveform *wf,
>> +					   void *_wfhw)
>> +{
>> +	struct max7360_pwm_waveform *wfhw = _wfhw;
>> +	u64 duty_steps;
>> +
>> +	/*
>> +	 * Ignore user provided values for period_length_ns and duty_offset_ns:
>> +	 * we only support fixed period of MAX7360_PWM_PERIOD_NS and offset of 0.
>> +	 * Values from 0 to 254 as duty_steps will provide duty cycles of 0/256
>> +	 * to 254/256, while value 255 will provide a duty cycle of 100%.
>> +	 */
>> +	if (wf->duty_length_ns >= MAX7360_PWM_PERIOD_NS) {
>> +		duty_steps = MAX7360_PWM_MAX;
>> +	} else {
>> +		duty_steps = (u32)wf->duty_length_ns * MAX7360_PWM_STEPS / MAX7360_PWM_PERIOD_NS;
>> +		if (duty_steps == MAX7360_PWM_MAX)
>> +			duty_steps = MAX7360_PWM_MAX - 1;
>> +	}
>> +
>> +	wfhw->duty_steps = min(MAX7360_PWM_MAX, duty_steps);
>> +	wfhw->enabled = !!wf->period_length_ns;
>> +
>> +	return 0;
>
> The unconditional return 0 is wrong and testing with PWM_DEBUG enabled
> should tell you that.
>

When you say should, does that mean the current version of PWM core will
tell me that with PWM_DEBUG enabled, or does that mean we should modify
the code so it does show a warning? As I did not see any warning when
specifying a wf->period_length_ns > MAX7360_PWM_PERIOD_NS, even with
PWM_DEBUG enabled.

On the other hand, if I specify a wf->period_length_ns value below
MAX7360_PWM_PERIOD_NS, I indeed get an error:
pwm pwmchip0: Wrong rounding: requested 1000000/1000000 [+0], result 1000000/2000000 [+0]

> I think the right thing to do here is:
>
> 	if (wf->period_length_ns > MAX7360_PWM_PERIOD_NS)
> 		return 1;
> 	else
> 		return 0;

I can definitely do that, but now I'm a bit confused by the meaning of
this return value: is it 0 on success, 1 if some rounding was made,
-errno on error? So I believe I should only return 0 if
wf->period_length_ns == MAX7360_PWM_PERIOD_NS, no?

Or reading this comment on pwm_round_waveform_might_sleep(), maybe we
only have to return 1 if some value is rounded UP. So I believe the test
should be (wf->period_length_ns < MAX7360_PWM_PERIOD_NS).

>  * Returns: 0 on success, 1 if at least one value had to be rounded up or a
>  * negative errno.

This is kinda confirmed by this other comment, in the code checking the
above returned value in __pwm_apply(), even its just typical examples:

> if (err > 0)
> 	/*
> 	 * This signals an invalid request, typically
> 	 * the requested period (or duty_offset) is
> 	 * smaller than possible with the hardware.
> 	 */
> 	return -EINVAL;

So, yeah, sorry, but I'm really confused about what is the correct
return value here.

>
> Otherwise looks fine.
>
> Best regards
> Uwe

Thanks again for your time.

Best regards,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  reply	other threads:[~2025-08-06 12:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-22 16:23 [PATCH v12 00/10] Add support for MAX7360 Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 01/10] dt-bindings: mfd: gpio: Add MAX7360 Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 02/10] mfd: Add max7360 support Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 03/10] pinctrl: Add MAX7360 pinctrl driver Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 04/10] pwm: max7360: Add MAX7360 PWM support Mathieu Dubois-Briand
2025-08-01 10:11   ` Uwe Kleine-König
2025-08-06 12:07     ` Mathieu Dubois-Briand [this message]
2025-08-06 14:02       ` Uwe Kleine-König
2025-08-06 14:36         ` Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 05/10] gpio: regmap: Allow to allocate regmap-irq device Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 06/10] gpio: regmap: Allow to provide init_valid_mask callback Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 07/10] gpio: max7360: Add MAX7360 gpio support Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 08/10] input: keyboard: Add support for MAX7360 keypad Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 09/10] input: misc: Add support for MAX7360 rotary Mathieu Dubois-Briand
2025-07-22 16:23 ` [PATCH v12 10/10] MAINTAINERS: Add entry on MAX7360 driver Mathieu Dubois-Briand
2025-07-31 10:02 ` [PATCH v12 00/10] Add support for MAX7360 Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DBVBZ48R7DNR.850O5X7MLMEF@bootlin.com \
    --to=mathieu.dubois-briand@bootlin.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.clement@bootlin.com \
    --cc=kamel.bouhara@bootlin.com \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=mwalle@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=ukleinek@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.