| Message ID | cover.1584650604.git.gurus@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Convert PWM period and duty cycle to u64 | expand |
This is a giant CC list. There was one version where you CC'd me on patch 6/12 but after that you just CC'd me on the cover page. Something is messed up in your scripts because Cc'ing me on just the cover is pointless. regards, dan carpenter
On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote: > This is a giant CC list. Yes, this is because I received feedback [1] on an earlier patchset directing me to add the reviewers of patches to the cover letter as well so that they get some context for the patch. > There was one version where you CC'd me on patch 6/12 but after that you Yes, that would be v9 [2]. > just CC'd me on the cover page. Something is messed up in your scripts > because Cc'ing me on just the cover is pointless. Sorry about that - was initially adding reviewers only to the final email being sent out instead of listing them in the commit message directly, which I now realize is untenable and have subsequently fixed. [1] https://www.spinics.net/lists/linux-pwm/msg11735.html [2] https://www.spinics.net/lists/linux-pwm/msg11852.html Thank you. Guru Das.
On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote: > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote: > > This is a giant CC list. > > Yes, this is because I received feedback [1] on an earlier patchset > directing me to add the reviewers of patches to the cover letter as > well so that they get some context for the patch. > ... > [1] https://www.spinics.net/lists/linux-pwm/msg11735.html Strictly speaking I only asked for backlight maintainers to be Cc:ed. I was fairly careful to be specific since I'm aware there are a variety of differing habits when putting together the Cc: list for covering letters. With the original patch header the purpose of the patch I was Cc:ed on was impossible to determine without the covering letter. Daniel.
On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote: > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote: > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote: > > > This is a giant CC list. > > > > Yes, this is because I received feedback [1] on an earlier patchset > > directing me to add the reviewers of patches to the cover letter as > > well so that they get some context for the patch. > > ... > > [1] https://www.spinics.net/lists/linux-pwm/msg11735.html > > Strictly speaking I only asked for backlight maintainers to be Cc:ed. > I was fairly careful to be specific since I'm aware there are a variety > of differing habits when putting together the Cc: list for covering > letters. > > With the original patch header the purpose of the patch I was Cc:ed on > was impossible to determine without the covering letter. I suspect this might be the case for all the other reviewers as well - that they also would appreciate context for the specific patch they are being added to review. I wasn't entirely sure what the convention was, so I applied your suggestion to all the files. How do you suggest I handle this in my next patchset? I fully agree that such a large CC list does look really ungainly. Thank you. Guru Das.
On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote: > On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote: > > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote: > > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote: > > > > This is a giant CC list. > > > > > > Yes, this is because I received feedback [1] on an earlier patchset > > > directing me to add the reviewers of patches to the cover letter as > > > well so that they get some context for the patch. > > > ... > > > [1] https://www.spinics.net/lists/linux-pwm/msg11735.html > > > > Strictly speaking I only asked for backlight maintainers to be Cc:ed. > > I was fairly careful to be specific since I'm aware there are a variety > > of differing habits when putting together the Cc: list for covering > > letters. > > > > With the original patch header the purpose of the patch I was Cc:ed on > > was impossible to determine without the covering letter. > > I suspect this might be the case for all the other reviewers as well - > that they also would appreciate context for the specific patch they are > being added to review. > > I wasn't entirely sure what the convention was, so I applied your > suggestion to all the files. How do you suggest I handle this in my next > patchset? I fully agree that such a large CC list does look really > ungainly. IHMO there should not be a mechanical convention. Instead your goal needs to be how to make it as easy as possible to review your patches. Think about it this way: Each person in the To: of a patch (and maybe also Cc: depending on how you construct things) is a person you are asking to review and comment on the patch. If that person will find it easier to review the patch if they are included in the cover letter then either they should be included or you should improve the patch description of the patch itself (sometimes both). Either way it is about optimizing the patchset for readability. More people read them than write them. Daniel.
On Tue, Mar 31, 2020 at 02:48:04PM +0100, Daniel Thompson wrote: > On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote: > > On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote: > > > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote: > > > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote: > > > > > This is a giant CC list. > > > > > > > > Yes, this is because I received feedback [1] on an earlier patchset > > > > directing me to add the reviewers of patches to the cover letter as > > > > well so that they get some context for the patch. > > > > ... > > > > [1] https://www.spinics.net/lists/linux-pwm/msg11735.html > > > > > > Strictly speaking I only asked for backlight maintainers to be Cc:ed. > > > I was fairly careful to be specific since I'm aware there are a variety > > > of differing habits when putting together the Cc: list for covering > > > letters. > > > > > > With the original patch header the purpose of the patch I was Cc:ed on > > > was impossible to determine without the covering letter. > > > > I suspect this might be the case for all the other reviewers as well - > > that they also would appreciate context for the specific patch they are > > being added to review. > > > > I wasn't entirely sure what the convention was, so I applied your > > suggestion to all the files. How do you suggest I handle this in my next > > patchset? I fully agree that such a large CC list does look really > > ungainly. > > IHMO there should not be a mechanical convention. Instead your goal > needs to be how to make it as easy as possible to review your patches. > > Think about it this way: Each person in the To: of a patch (and maybe > also Cc: depending on how you construct things) is a person you are > asking to review and comment on the patch. If that person will find it > easier to review the patch if they are included in the cover letter then > either they should be included or you should improve the patch > description of the patch itself (sometimes both). > > Either way it is about optimizing the patchset for readability. More > people read them than write them. Thank you for the explanation! I shall keep your suggestions in mind while sending out future patchsets. Thank you. Guru Das.
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 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/20200312190859.GA19605@codeaurora.org/ [3] https://www.spinics.net/lists/linux-pwm/msg11906.html Guru Das Srinagesh (12): 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: stm32-lp: Use %llu format specifier for period pwm: sun4i: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function clk: pwm: Assign u64 divisor to unsigned int before use pwm: core: Convert period and duty cycle to u64 drivers/clk/clk-pwm.c | 4 +++- 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 | 4 ++-- drivers/pwm/pwm-clps711x.c | 5 ++++- drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c | 5 ++--- 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, 31 insertions(+), 25 deletions(-) Cc: Lee Jones <lee.jones@linaro.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-fbdev@vger.kernel.org Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Fabrice Gasnier <fabrice.gasnier@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: linux-riscv@lists.infradead.org Cc: Yash Shah <yash.shah@sifive.com> Cc: Atish Patra <atish.patra@wdc.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Richard Fontana <rfontana@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Allison Randal <allison@lohutok.net> Cc: linux-media@vger.kernel.org Cc: Kamil Debski <kamil@wypas.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-hwmon@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mukesh Ojha <mojha@codeaurora.org> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Anson Huang <Anson.Huang@nxp.com> Cc: Gerald Baeza <gerald.baeza@st.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Axel Lin <axel.lin@ingics.com> Cc: Ding Xiang <dingxiang@cmss.chinamobile.com> Cc: Wesley W. Terpstra <wesley@sifive.com>