Convert PWM period and duty cycle to u64

Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend.

To: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: "Ville Syrjälä" <[email protected]>
Cc: [email protected]
Cc: [email protected]

Signed-off-by Guru Das Srinagesh <[email protected]>

---
 drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/i915/display/intel_panel.c +1 -1

index 276f438..81547a0 100644
@@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
 		return retval;
 	}
 
-	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
+	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 			     CRC_PMIC_PWM_PERIOD_NS);
 	panel->backlight.level =
 		intel_panel_compute_brightness(connector, level);

Quoted 4 lines · Guru Das Srinagesh

Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend.

Quoted 9 lines

To: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: "Ville Syrjälä" <[email protected]>
Cc: [email protected]
Cc: [email protected]

Superfluous blank line.

Anyway, please preserve the existing acks and reviews [1] so people don't have to do it again.

BR,
Jani.

[1] http://lore.kernel.org/r/[email protected]

Quoted 15 lines · Jani Nikula

Quoted 4 lines · Guru Das Srinagesh

Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend.

Quoted 9 lines

To: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: "Ville Syrjälä" <[email protected]>
Cc: [email protected]
Cc: [email protected]

Quoted 1 line

Superfluous blank line.

Will remove.

Quoted 4 lines

Anyway, please preserve the existing acks and reviews [1] so people don't have to do it again.

Quoted 4 lines

BR,
Jani.

[1] http://lore.kernel.org/r/[email protected]

I dropped your Acked-by as the patch had to changed to resolve a merge conflict when I rebased to tip. Could you please re-review this patch?

Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by typecasting it to u32.

Also, since the dividend is still a 32-bit number, any divisor greater than the numerator will cause the quotient to be zero, so return 0 in that case to efficiently skip the division.

Cc Alexander Shiyan <[email protected]>

Cc Arnd Bergmann <[email protected]>

Signed-off-by Guru Das Srinagesh <[email protected]>

---
 drivers/pwm/pwm-clps711x.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/pwm/pwm-clps711x.c +0 -0

index 924d39a..0d368ac 100644

Quoted 15 lines · Guru Das Srinagesh

Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by typecasting it to u32.

Also, since the dividend is still a 32-bit number, any divisor greater than the numerator will cause the quotient to be zero, so return 0 in that case to efficiently skip the division.

Cc Alexander Shiyan <[email protected]>

Cc Arnd Bergmann <[email protected]>

Signed-off-by Guru Das Srinagesh <[email protected]>

---
 drivers/pwm/pwm-clps711x.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/pwm/pwm-clps711x.c static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v) · line 46

Quoted 10 lines

drivers/pwm/pwm-clps711x.c +1 -1

index 924d39a..0d368ac 100644
@@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
 static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
 {
        /* Duty cycle 0..15 max */
-       return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
+       if ((u32)pwm->args.period > (v * 0xf))

Shouldn't the cast be removed from the expression above?
Else a period larger than or equal to 2^32 may be accepted, but truncated silently. And even cause a division by zero error.

Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using div_u64 to handle a 64-bit dividend instead of a straight division operation.

Cc Lee Jones <[email protected]>

Cc Daniel Thompson <[email protected]>

Cc Jingoo Han <[email protected]>

Cc Bartlomiej Zolnierkiewicz <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Signed-off-by Guru Das Srinagesh <[email protected]>

Reviewed-by Daniel Thompson <[email protected]>

Since the PWM framework is switching struct pwm_args.period's datatype to u64, prepare for this transition by using div64_u64 to handle a

64-bit divisor.

Also ensure that divide-by-zero (with fixed_rate as denominator) does not happen with an explicit check with probe failure as a consequence.

To: David Laight <[email protected]>
To: Arnd Bergmann <[email protected]>
Cc: Michael Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Cc: [email protected]

Signed-off-by Guru Das Srinagesh <[email protected]>

---

Because period and duty cycle are defined as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Change their definitions to u64 in the structs of the PWM framework so that higher durations may be set.

Also use the right format specifiers in debug prints in both core.c as well as pwm-stm32-lp.c.

Cc Fabrice Gasnier <[email protected]>

Cc Maxime Coquelin <[email protected]>

Cc Alexandre Torgue <[email protected]>

Cc Joe Perches <[email protected]>

Reported-by kbuild test robot <[email protected]>

Signed-off-by Guru Das Srinagesh <[email protected]>

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in this series to be accepted and applied to the tree? I lost an Acked-by (in intel-panel.c) because it had a merge conflict with a new change that came in after I rebased to tip. I wasn't sure earlier about accepting single patches as opposed to the entire series en masse, but this event has got me thinking.

Quoted 7 lines · Guru Das Srinagesh

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in this series to be accepted and applied to the tree? I lost an Acked-by (in intel-panel.c) because it had a merge conflict with a new change that came in after I rebased to tip. I wasn't sure earlier about accepting single patches as opposed to the entire series en masse, but this event has got me thinking.

Has there been a positive maintainer review of patch 11 at any point in the thread (most of the people you are asking to commit patches have not been able to see the discussion about the actual feature these patches are preparing for)?

Quoted 9 lines · Daniel Thompson

Quoted 7 lines · Guru Das Srinagesh

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in this series to be accepted and applied to the tree? I lost an Acked-by (in intel-panel.c) because it had a merge conflict with a new change that came in after I rebased to tip. I wasn't sure earlier about accepting single patches as opposed to the entire series en masse, but this event has got me thinking.

Quoted 4 lines

Has there been a positive maintainer review of patch 11 at any point in the thread (most of the people you are asking to commit patches have not been able to see the discussion about the actual feature these patches are preparing for)?

Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11 which is essentially unchanged in this patchset save the dropping of the pwm_capture change.

[1] https://www.spinics.net/lists/linux-pwm/msg11536.html

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in this series to be accepted and applied to the tree? I lost an Acked-by (in intel-panel.c) because it had a merge conflict with a new change that came in after I rebased to tip. I wasn't sure earlier about accepting single patches as opposed to the entire series en masse, but this event has got me thinking.

[COVER LETTER]

Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds.

Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors.

This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors.

What's the merge plan for this set?

FYI, it's better to send all patches to all parties. That way maintainers and interested persons can follow the discussion and progress, or lack there of.

Quoted 1 line · Lee Jones

What's the merge plan for this set?

I'm not sure what you mean. My assumption is that first all the patches need to get an Acked-by and only then will the series get applied by Thierry... Could Thierry or Uwe weigh in on this point please?

Quoted 3 lines

FYI, it's better to send all patches to all parties. That way maintainers and interested persons can follow the discussion and progress, or lack there of.

Something I noticed with adding all the various mailing lists to the CC list for this cover letter is that it is causing this cover letter email and all its replies to not be archived properly on spinics or lore - it's probably getting rejected by email filters somehow. Compare with v12 [1] where I'd pruned the list considerably as an experiment - that got archived correctly.

Any ideas on what might be going wrong? Once I fix this I can add all parties to all patches knowing that there would be no issues in mail archival.

[1] https://www.spinics.net/lists/linux-pwm/msg12131.html

Thank you.

Guru Das.

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Quoted 6 lines · Lee Jones

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

Quoted 8 lines

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

Thank you for the detailed reply. I did this in the first few patchsets and then when a few patches didn't get any attention, expanded the audience thus. Still, around 50% of the patches in this series remain unreviewed by anyone.

Quoted 4 lines

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Thank you, will prune the list and remove past contributors from the Cc-list and add all parties to all patches.

Quoted 16 lines · Guru Das Srinagesh

Quoted 6 lines · Lee Jones

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

Quoted 8 lines

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

Quoted 4 lines

Thank you for the detailed reply. I did this in the first few patchsets and then when a few patches didn't get any attention, expanded the audience thus. Still, around 50% of the patches in this series remain unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care even less than your original group). However it *is* a good argument for including all of the specified maintainers/reviewers in on all of the patches.

Quoted 5 lines

Quoted 4 lines

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Quoted 2 lines

Thank you, will prune the list and remove past contributors from the Cc-list and add all parties to all patches.

Great. Once you've done that, we can start to help you acquire the Acks you need on your remaining patches.

Quoted 33 lines · Lee Jones

Quoted 16 lines · Guru Das Srinagesh

Quoted 6 lines · Lee Jones

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

Quoted 8 lines

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

Quoted 4 lines

Thank you for the detailed reply. I did this in the first few patchsets and then when a few patches didn't get any attention, expanded the audience thus. Still, around 50% of the patches in this series remain unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care even less than your original group). However it *is* a good argument for including all of the specified maintainers/reviewers in on all of the patches.

Quoted 5 lines

Quoted 4 lines

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Quoted 5 lines

Quoted 2 lines

Thank you, will prune the list and remove past contributors from the Cc-list and add all parties to all patches.

Great. Once you've done that, we can start to help you acquire the Acks you need on your remaining patches.

Hi Lee, Thierry, Uwe,

In v14 of this patchset I've pruned the list of contributors, removed past contributors from the cc-list, and added all parties to all patches (except for the patches that are yet to reviewed, for which I've added what get_maintainer.pl showed me). I've also resent v14 a couple of times already, with around a week's time interval between resends, and somehow it seems like this set has lost traction.

Could you please indicate what next steps I should take to have more eyes on the unreviewed patches? Only 4 out of 11 patches remain unreviewed.

Quoted 49 lines · Guru Das Srinagesh

Quoted 33 lines · Lee Jones

Quoted 16 lines · Guru Das Srinagesh

Quoted 6 lines · Lee Jones

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

Quoted 8 lines

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

Quoted 4 lines

Thank you for the detailed reply. I did this in the first few patchsets and then when a few patches didn't get any attention, expanded the audience thus. Still, around 50% of the patches in this series remain unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care even less than your original group). However it *is* a good argument for including all of the specified maintainers/reviewers in on all of the patches.

Quoted 5 lines

Quoted 4 lines

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Quoted 5 lines

Quoted 2 lines

Thank you, will prune the list and remove past contributors from the Cc-list and add all parties to all patches.

Great. Once you've done that, we can start to help you acquire the Acks you need on your remaining patches.

Hi Lee, Thierry, Uwe,

In v14 of this patchset I've pruned the list of contributors, removed past contributors from the cc-list, and added all parties to all patches (except for the patches that are yet to reviewed, for which I've added what get_maintainer.pl showed me). I've also resent v14 a couple of times already, with around a week's time interval between resends, and somehow it seems like this set has lost traction.

Quoted 3 lines

Could you please indicate what next steps I should take to have more eyes on the unreviewed patches? Only 4 out of 11 patches remain unreviewed.

Looks like we're waiting on Thierry (again).

This has been a common theme over the past few months.

Perhaps he has changed employer/project?

Quoted 57 lines · Lee Jones

Quoted 49 lines · Guru Das Srinagesh

Quoted 33 lines · Lee Jones

Quoted 16 lines · Guru Das Srinagesh

Quoted 6 lines · Lee Jones

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

Quoted 8 lines

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

Quoted 4 lines

Thank you for the detailed reply. I did this in the first few patchsets and then when a few patches didn't get any attention, expanded the audience thus. Still, around 50% of the patches in this series remain unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care even less than your original group). However it *is* a good argument for including all of the specified maintainers/reviewers in on all of the patches.

Quoted 5 lines

Quoted 4 lines

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Quoted 5 lines

Quoted 2 lines

Thank you, will prune the list and remove past contributors from the Cc-list and add all parties to all patches.

Great. Once you've done that, we can start to help you acquire the Acks you need on your remaining patches.

Hi Lee, Thierry, Uwe,

In v14 of this patchset I've pruned the list of contributors, removed past contributors from the cc-list, and added all parties to all patches (except for the patches that are yet to reviewed, for which I've added what get_maintainer.pl showed me). I've also resent v14 a couple of times already, with around a week's time interval between resends, and somehow it seems like this set has lost traction.

Quoted 3 lines

Could you please indicate what next steps I should take to have more eyes on the unreviewed patches? Only 4 out of 11 patches remain unreviewed.

Looks like we're waiting on Thierry (again).

Quoted 3 lines

This has been a common theme over the past few months.

Perhaps he has changed employer/project?

My work on PWM is purely done in my spare time. I don't get paid for any of it. I currently have two kids that need home-schooling, as many others probably do, and I have a full time job doing non-PWM related things. As a result my spare time is close to nil these days.

I very much appreciate all the effort that others have spent in getting this reviewed. I haven't been able to keep a very close eye on this, but even the latest versions have some comments, so I didn't consider this ready yet. If that's changed and everybody's okay with the changes, then I can apply this to for-next. We haven't got all that much time left before the merge window and I had hoped this would be ready earlier so that we'd have more time for this in linux-next. But I'd be willing to at least give it a try. If it starts to look like there are going to be issues with this I can always back them out and we can have another go next release.

Quoted 62 lines · Thierry Reding

Quoted 60 lines · Lee Jones

Quoted 49 lines · Guru Das Srinagesh

Quoted 33 lines · Lee Jones

Quoted 16 lines · Guru Das Srinagesh

Quoted 6 lines · Lee Jones

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

Quoted 8 lines

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

Quoted 4 lines

Thank you for the detailed reply. I did this in the first few patchsets and then when a few patches didn't get any attention, expanded the audience thus. Still, around 50% of the patches in this series remain unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care even less than your original group). However it *is* a good argument for including all of the specified maintainers/reviewers in on all of the patches.

Quoted 5 lines

Quoted 4 lines

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Quoted 5 lines

Quoted 2 lines

Thank you, will prune the list and remove past contributors from the Cc-list and add all parties to all patches.

Great. Once you've done that, we can start to help you acquire the Acks you need on your remaining patches.

Hi Lee, Thierry, Uwe,

In v14 of this patchset I've pruned the list of contributors, removed past contributors from the cc-list, and added all parties to all patches (except for the patches that are yet to reviewed, for which I've added what get_maintainer.pl showed me). I've also resent v14 a couple of times already, with around a week's time interval between resends, and somehow it seems like this set has lost traction.

Quoted 3 lines

Could you please indicate what next steps I should take to have more eyes on the unreviewed patches? Only 4 out of 11 patches remain unreviewed.

Looks like we're waiting on Thierry (again).

This has been a common theme over the past few months.

Perhaps he has changed employer/project?

Quoted 4 lines

My work on PWM is purely done in my spare time. I don't get paid for any of it. I currently have two kids that need home-schooling, as many others probably do, and I have a full time job doing non-PWM related things. As a result my spare time is close to nil these days.

This is no different to many others. I too am not paid for this work, but it's still my responsibly to ensure a reply within a reasonable amount of time.

We can all appreciate that the latest situation has exacerbated issues, but a reasonable level of PWM participation, blocking various patch-sets has been lacking for months before we'd even heard of Covid-19 [0].

If you need help, just ask for it.

I am willing to step up and review patches if you're overloaded. Uwe is already listed as a designated reviewer. Perhaps between the 3 of us we can work something out in order to reduce the latency.

[0] https://patchwork.ozlabs.org/project/linux-pwm/list/

Quoted 10 lines

I very much appreciate all the effort that others have spent in getting this reviewed. I haven't been able to keep a very close eye on this, but even the latest versions have some comments, so I didn't consider this ready yet. If that's changed and everybody's okay with the changes, then I can apply this to for-next. We haven't got all that much time left before the merge window and I had hoped this would be ready earlier so that we'd have more time for this in linux-next. But I'd be willing to at least give it a try. If it starts to look like there are going to be issues with this I can always back them out and we can have another go next release.

If you would be so kind as to review the PWM patches, I can take them in but I can't do anything without your Ack.

Looking at v14 I think there are no longer any discussions (looks like the last comment I thought was from v14 was actually on v13 and it seems to have been solved in v14 now) and there are Acked-bys for all the non- PWM patches, so there's nothing in the way of me applying this to the PWM tree. I can let it soak there for a few days and send out a stable branch if anyone needs it if there aren't any huge issues.

Does that sound like a plan?

Quoted 64 lines · Lee Jones

Quoted 62 lines · Thierry Reding

Quoted 60 lines · Lee Jones

Quoted 49 lines · Guru Das Srinagesh

Quoted 33 lines · Lee Jones

Quoted 16 lines · Guru Das Srinagesh

Quoted 6 lines · Lee Jones

A great deal of mailing lists contain numerous protections against things like flooding and spamming. One of those protections is a check for "Too many recipients to the message". Most of the time this simply requires moderator intervention by way of review and approval, but this ultimately depends on the ML's configuration.

Quoted 8 lines

The first thing to ascertain is why your recipients list is so large. Have you added every reviewer, subsystem-maintainer, maintainer and contributor suggested by get-maintainer.pl? If so, consider pruning that a little. Contributors do not tend to care about subsequent changes to a file. As someone who receives a lot of patches, I tend to get fed-up when receiving patches simply because I made a change X years ago. Stick to listed maintainers/reviewers in the first instance and see how far that takes you.

Quoted 4 lines

Thank you for the detailed reply. I did this in the first few patchsets and then when a few patches didn't get any attention, expanded the audience thus. Still, around 50% of the patches in this series remain unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care even less than your original group). However it *is* a good argument for including all of the specified maintainers/reviewers in on all of the patches.

Quoted 5 lines

Quoted 4 lines

If your recipients list is as succinct as reasonably possible, maybe just accept that every version isn't going to be archived by every ML. It's still much more useful for the correct people to have visibility into the set than for it to be archived multiple times.

Quoted 5 lines

Quoted 2 lines

Thank you, will prune the list and remove past contributors from the Cc-list and add all parties to all patches.

Great. Once you've done that, we can start to help you acquire the Acks you need on your remaining patches.

Hi Lee, Thierry, Uwe,

In v14 of this patchset I've pruned the list of contributors, removed past contributors from the cc-list, and added all parties to all patches (except for the patches that are yet to reviewed, for which I've added what get_maintainer.pl showed me). I've also resent v14 a couple of times already, with around a week's time interval between resends, and somehow it seems like this set has lost traction.

Quoted 3 lines

Could you please indicate what next steps I should take to have more eyes on the unreviewed patches? Only 4 out of 11 patches remain unreviewed.

Looks like we're waiting on Thierry (again).

This has been a common theme over the past few months.

Perhaps he has changed employer/project?

Quoted 8 lines

Quoted 4 lines

My work on PWM is purely done in my spare time. I don't get paid for any of it. I currently have two kids that need home-schooling, as many others probably do, and I have a full time job doing non-PWM related things. As a result my spare time is close to nil these days.

This is no different to many others. I too am not paid for this work, but it's still my responsibly to ensure a reply within a reasonable amount of time.

I realize that this is the same for many others. Still, you seemed to suggest that the lack of time that I was able to spend on PWM was somehow related to me changing employers, so I wanted to clarify that this isn't

Quoted 4 lines

We can all appreciate that the latest situation has exacerbated issues, but a reasonable level of PWM participation, blocking various patch-sets has been lacking for months before we'd even heard of Covid-19 [0].

Covid-19 started to impact me around mid-March, and you'll see that that's about the time that I stopped maintaining patchwork.

Quoted 1 line

If you need help, just ask for it.

Hm... who do you go and ask for help? Every maintainer I know is already at least as busy as I am.

Quoted 3 lines

I am willing to step up and review patches if you're overloaded. Uwe is already listed as a designated reviewer. Perhaps between the 3 of us we can work something out in order to reduce the latency.

That's very kind of you. Yes, I'd be willing to do this as a sort of group maintenance, and perhaps even eventually step away from my role as maintainer entirely if I think somebody else will do a better job. I do still care about the PWM subsystem, having looked after it for a couple of years, so I do want any hand-off to be somewhat orderly.

Quoted 13 lines

[0] https://patchwork.ozlabs.org/project/linux-pwm/list/

Quoted 10 lines

I very much appreciate all the effort that others have spent in getting this reviewed. I haven't been able to keep a very close eye on this, but even the latest versions have some comments, so I didn't consider this ready yet. If that's changed and everybody's okay with the changes, then I can apply this to for-next. We haven't got all that much time left before the merge window and I had hoped this would be ready earlier so that we'd have more time for this in linux-next. But I'd be willing to at least give it a try. If it starts to look like there are going to be issues with this I can always back them out and we can have another go next release.

Quoted 2 lines

If you would be so kind as to review the PWM patches, I can take them in but I can't do anything without your Ack.

Looking at v14 I think there are no longer any discussions (looks like the last comment I thought was from v14 was actually on v13 and it seems to have been solved in v14 now) and there are Acked-bys for all the non- PWM patches, so there's nothing in the way of me applying this to the PWM tree. I can let it soak there for a few days and send out a stable branch if anyone needs it if there aren't any huge issues.

Does that sound like a plan?

Quoted 1 line · Lee Jones

What's the merge plan for this set?

I'm not sure what you mean. My assumption is that first all the patches need to get an Acked-by and only then will the series get applied by Thierry... Could Thierry or Uwe weigh in on this point please?

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in this series to be accepted and applied to the tree? I lost an Acked-by (in intel-panel.c) because it had a merge conflict with a new change that came in after I rebased to tip. I wasn't sure earlier about accepting single patches as opposed to the entire series en masse, but this event has got me thinking.

[COVER LETTER]

Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds.

Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors.

This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors.

Changes from v12:
- Rebased to tip of for-next
- Collected Acked-by for sun4i
- Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as a result

Changes from v11:
- Rebased to tip of for-next.
- Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
- Squished stm32-lp.c change with final patch in series
- sun4i: Used nsecs_to_jiffies()
- imx27: Added overflow handling logic
- clps711x: Corrected the if condition for skipping the division
- clk: pwm: Reverted to v8 version, added check to prevent division-by-zero

Changes from v10:
- Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received so far that had gotten missed in v9. No other changes.

Changes from v9:
- Gathered the received "Reviewed-by: " tag
- Added back the clk-pwm.c patch because kbuild test robot complained [3] and addressed received review comments.
- clps711x: Addressed review comments.

Changes from v8:
- Gathered all received "Acked-by: " and "Reviewed-by: " tags
- Dropped patch to clk-pwm.c for reasons mentiond in [2]
- Expanded audience of unreviewed patches

Changes from v7:
- Changed commit messages of all patches to be brief and to the point.
- Added explanation of change in cover letter.
- Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core.

Changes from v6:
- Split out the driver changes out into separate patches, one patch per file for ease of reviewing.

Changes from v5:
- Dropped the conversion of struct pwm_capture to u64 for reasons mentioned

    in https://www.spinics.net/lists/linux-pwm/msg11541.html

Changes from v4:
- Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise.
- Re-examined the patch and made the following corrections:
* intel_panel.c:
DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case).
* pwm-sti.c:
do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible).

Changes from v3:
- Rebased to current tip of for-next.

Changes from v2:
- Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c

Changes from v1:
- Fixed compilation errors seen when compiling for different archs.

v1:
- Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual.

[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/[email protected]/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.html

To: Arnd Bergmann <[email protected]>
To: David Laight <[email protected]>
To: Jani Nikula <[email protected]>
Cc: Alexander Shiyan <[email protected]>
Cc: Alexandre Torgue <[email protected]>
Cc: Allison Randal <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Atish Patra <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Chen-Yu Tsai <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Dan Carpenter <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: David Airlie <[email protected]>
Cc: David Collins <[email protected]>
Cc: [email protected]
Cc: Fabio Estevam <[email protected]>
Cc: Fabrice Gasnier <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: [email protected]
Cc: Jean Delvare <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Kamil Debski <[email protected]>
Cc: Kate Stewart <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Mark Brown <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Maxime Coquelin <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Michael Turquette <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Richard Fontana <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Stephen Boyd <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: "Ville Syrjälä" <[email protected]>
Cc: Yash Shah <[email protected]>

Guru Das Srinagesh (11):
drm/i915: Use 64-bit division macro
hwmon: pwm-fan: Use 64-bit division macro
ir-rx51: Use 64-bit division macro
pwm: clps711x: Cast period to u32 before use as divisor
pwm: pwm-imx-tpm: Use 64-bit division macro
pwm: imx27: Use 64-bit division macro and function
pwm: sifive: Use 64-bit division macro
pwm: sun4i: Use nsecs_to_jiffies to avoid a division
backlight: pwm_bl: Use 64-bit division function
clk: pwm: Use 64-bit division function
pwm: core: Convert period and duty cycle to u64

 drivers/clk/clk-pwm.c                      |  7 +++-
 drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
 drivers/hwmon/pwm-fan.c                    |  2 +-
 drivers/media/rc/ir-rx51.c                 |  3 +-
 drivers/pwm/core.c                         | 14 ++++----
 drivers/pwm/pwm-clps711x.c                 |  5 ++-
 drivers/pwm/pwm-imx-tpm.c                  |  2 +-
 drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
 drivers/pwm/pwm-sifive.c                   |  2 +-
 drivers/pwm/pwm-stm32-lp.c                 |  2 +-
 drivers/pwm/pwm-sun4i.c                    |  2 +-
 drivers/pwm/sysfs.c                        |  8 ++---

 drivers/video/backlight/pwm_bl.c           |  3 +-

 include/linux/pwm.h                        | 12 +++----
 14 files changed, 82 insertions(+), 35 deletions(-)