linux-kernel - Re: [PATCH 1/2] drivers: pwm: core: implement pwm mode

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: <CAHp75VdSGLwryheu2RFg8N7U6qbEf--HmRFG5pa5CzFwJqWdfA@mail.gmail.com>
Date:   Sun, 28 May 2017 01:11:42 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Claudiu Beznea <claudiu.beznea@...rochip.com>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        linux-pwm@...r.kernel.org,
        Linux Documentation List <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        nicolas.ferre@...rochip.com
Subject: Re: [PATCH 1/2] drivers: pwm: core: implement pwm mode

On Tue, May 9, 2017 at 3:15 PM, Claudiu Beznea
<claudiu.beznea@...rochip.com> wrote:
> Extends PWM framework to support PWM modes. The currently
> implemented PWM modes were called PWM complementary mode
> and PWM push-pull mode. For devices that have more than one
> output per PWM channel:
> - PWM complementary mode is standard working mode; in PWM
> complementary mode the rising and falling edges of the
> channels outputs have opposite levels, same duration and
> same starting time.
> - in PWM push-pull mode the channles outputs has same levels,
> same duration and the rising edges are delayed until the
> beginning of the next period.
> A new member was added in pwm_state structure in order to
> keep the new PWM argument.

To me it sound over-engineered.

It looks like polarity type

I dunno if PWM supports linked / virtual channels, but it would be like that

channel X  (polarity P) effectively is

channel Xa (polarity P) / channel Xb (polarity !P)

and vise versa.

Moreover, mode in your case doesn't fit to GPIO style of output which
would be emulated or native mode for PWM (we have already a use case
and one driver implements that).

GPIO type of output is, obviously, duty=100% in case of emulation,
though separate state for HW assisted kind of that.

-- 
With Best Regards,
Andy Shevchenko