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] [day] [month] [year] [list]
Date:   Wed, 18 Mar 2020 10:20:47 +0100
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Oleksandr Suvorov <oleksandr.suvorov@...adex.com>,
        devicetree@...r.kernel.org, linux-pwm@...r.kernel.org,
        Paul Barker <pbarker@...sulko.com>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Igor Opaniuk <igor.opaniuk@...adex.com>,
        Philippe Schenker <philippe.schenker@...adex.com>,
        Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 3/7] dt-bindings: pwm: add normal PWM polarity flag

Hello Laurent,

On Wed, Mar 18, 2020 at 12:56:56AM +0200, Laurent Pinchart wrote:
> On Tue, Mar 17, 2020 at 02:32:27PM +0200, Oleksandr Suvorov wrote:
> > PWM can have a normal polarity and a reverted one. The reverted polarity
> > value is defined.
> 
> I would squash this patch with 2/7, apart from that it looks fine.
> However, I also agree with Thierry that the PWM cell that contains this
> value is a bitmask, so once we get more flags it may get a bit awkward.

For me the usefulness of PWM_POLARITY_NORMAL increases with more bits
used. That's because if there are 5 things that can be set there and the
patch author mentions only the two that are non-zero, I as a reviewer
don't know if the author actually know and thought about the other
three. If however they spell out PWM_POLARITY_NORMAL it's quite sure
they want normal polarity.

> Will we have one macro for each flag that will evaluate to 0 to report
> that the flag isn't set ?

Yes. Given the above mentioned advantage this is cheap enough in my
eyes.

> Or should we define a single PWM_FLAG_NONE (or
> similarly named) macro ?

I like one macro for each bit field better for the above mentioned
reason.

> In retrospect, maybe PWM_POLARITY_INVERTED
> should have been named PWM_FLAG_POLARITY_INVERTED.

Seems to be subjective. I don't see much added semantic that justifies
the longer name.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Powered by blists - more mailing lists