From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Sven Van Asbroeck <TheSven73@gmail.com>,
Clemens Gruber <clemens.gruber@pqgruber.com>,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
linux-pwm@vger.kernel.org
Subject: Re: [PATCH 1/4] pwm: core: Support new usage_power setting in PWM state
Date: Mon, 7 Jun 2021 20:51:58 +0200 [thread overview]
Message-ID: <20210607185158.jweahkoa3cxwl2nh@pengutronix.de> (raw)
In-Reply-To: <YL4vzvznTzqih0pA@orome.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 3343 bytes --]
Hello Thierry,
On Mon, Jun 07, 2021 at 04:40:14PM +0200, Thierry Reding wrote:
> On Mon, Jun 07, 2021 at 08:08:27AM +0200, Uwe Kleine-König wrote:
> > Hello Thierry,
> >
> > On Fri, Jun 04, 2021 at 11:49:37AM +0200, Thierry Reding wrote:
> > > In the interest of making forward progress, I've applied this series.
> >
> > I proposed a different approach that in contrast to usage_power:
> >
> > - is well defined
> > (so driver authors and consumers know what to provide or expect resp.);
> > - has good name people understand without reading documentation;
> > - fully covers the problem Clemens want to address;
> > - fully covers what the only implementing lowlevel driver does; and
> > - is easy to implement based on the patches in this series
> >
> > This is not what I call "forward progress". I take it personal that
> > after I pointed out technical shortcomings with this patch set and even
> > suggested a better concept, you didn't even made the effort to argue
> > but instead simply went on applying the patches.
>
> Forward progress doesn't always mean that everybody gets their way.
Do you agree that the usage power flag introduced here isn't well
defined? If you think it is, tell me, what is the maximal and minimal
period a consumer has to expect when .period = 10000 ns is requested.
Assume you have a driver (think pwm-gpio) where a longer period means
more power savings. What is "the reasonable" period that the driver
should configure?
Do you agree that in contrast to usage-power allow-phase-shift is well
defined?
Did you ask people in your bubble what they expect from a usage power
flag for a PWM without first explaining what it does? Did you try to ask
an internet search engine what it suggests when searching for "PWM usage
power"?
Do you agree that allow-phase-shift is good enough to solve Clemens'
problem?
Either you give completely other answers than I do or you don't consider
it bad that consumers don't know what they can expect and that names are
unintuitive.
My problem is not that in the end a solution is picked that wasn't my
favourite. My problem is that I have the impression my arguments were
not considered but simply ignored.
> And this is nothing personal, so please don't take it that way.
If this isn't personal (which is great) then it's a decision that is (at
least for me) obviously wrong and ignoring the good arguments against
this choice without any relevant advantages compared to my suggested
solution. I have problems to not take this personal.
> I don't see where you pointed out technical shortcomings with this
> patch, you merely pointed out that you don't like this solution and that
> there might be a better way to implement it by expanding on the concepts
> introduced in this patch series.
Either you didn't read my mail at all, or you have a different idea
about what you consider a relevant argument. (Well, or you don't care
that your choice is bad. I hope this is only a theoretical possibility.)
Being well defined and having an intuitive name belong into this
"relevant" category in my book.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-06-07 18:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 13:18 [PATCH 1/4] pwm: core: Support new usage_power setting in PWM state Clemens Gruber
2021-05-07 13:18 ` [PATCH 2/4] pwm: pca9685: " Clemens Gruber
2021-05-07 13:18 ` [PATCH 3/4] pwm: pca9685: Restrict period change for enabled PWMs Clemens Gruber
2021-05-07 13:18 ` [PATCH 4/4] pwm: pca9685: Add error messages for failed regmap calls Clemens Gruber
2021-05-07 15:03 ` [PATCH 1/4] pwm: core: Support new usage_power setting in PWM state Uwe Kleine-König
2021-05-07 15:47 ` Clemens Gruber
2021-05-07 23:18 ` Uwe Kleine-König
2021-05-31 16:12 ` Clemens Gruber
2021-06-04 9:49 ` Thierry Reding
2021-06-07 6:08 ` Uwe Kleine-König
2021-06-07 14:40 ` Thierry Reding
2021-06-07 18:51 ` Uwe Kleine-König [this message]
2021-06-09 20:41 ` Uwe Kleine-König
2021-06-10 13:11 ` Thierry Reding
2021-06-21 6:47 ` PWM-Patches for next merge window [Was: Re: [PATCH 1/4] pwm: core: Support new usage_power setting in PWM] state Uwe Kleine-König
2021-06-25 9:55 ` PWM-Patches for next merge window Uwe Kleine-König
2021-06-04 9:44 ` [PATCH 1/4] pwm: core: Support new usage_power setting in PWM state Thierry Reding
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=20210607185158.jweahkoa3cxwl2nh@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=TheSven73@gmail.com \
--cc=clemens.gruber@pqgruber.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=thierry.reding@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).