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: <20210607185158.jweahkoa3cxwl2nh@pengutronix.de>
Date:   Mon, 7 Jun 2021 20:51:58 +0200
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Sven Van Asbroeck <TheSven73@...il.com>,
        Clemens Gruber <clemens.gruber@...ruber.com>,
        linux-kernel@...r.kernel.org, kernel@...gutronix.de,
        linux-pwm@...r.kernel.org
Subject: Re: [PATCH 1/4] pwm: core: Support new usage_power setting in PWM
 state

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/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ