linux-kernel - Re: [PATCH 0/1] pwm: meson: fix scheduling while atomic issue

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: <CAFBinCCGWsb+1WHFe6uwrpUYgH4iix0WT8_v_Nj5BhGKRyjiLQ@mail.gmail.com>
Date:   Sat, 30 Mar 2019 20:29:35 +0100
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     thierry.reding@...il.com, Neil Armstrong <narmstrong@...libre.com>,
        jbrunet@...libre.com, linux-pwm@...r.kernel.org,
        linux-amlogic@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        kernel@...gutronix.de
Subject: Re: [PATCH 0/1] pwm: meson: fix scheduling while atomic issue

Hello Uwe,

On Mon, Mar 25, 2019 at 9:07 PM Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> wrote:
[...]
> > >  - Does stopping the PWM (i.e. clearing MISC_{A,B}_EN in the MISC_AB
> > >    register) freeze the output, or is the currently running period
> > >    completed first? (The latter is the right behaviour.)
> > I don't know, I would have to measure this with a logic analyzer.
>
> In practise you can do this with a multimeter, too. Just do something
> like:
>
>         pwm_apply_state({ .enabled = true, .period = 5s, .duty_cycle = 5s, .polarity = PWM_POLARITY_NORMAL });
>         pwm_apply_state({ .enabled = false, .period = 5s, .duty_cycle = 5s, .polarity = PWM_POLARITY_NORMAL });
>
> (assuming the PWM supports periods that long). The expectation is that
> the last command takes nearly 5 s to complete and while it waits the
> output is high and on return it's low. If that isn't the case, there is
> a bug somewhere.
the longest supported period (using the 24MHz crystal as input, which
is the slowest input clock and thus gives the longest possible
duration) is 349514407ns (that's approx. 0.35 seconds). my multimeter
isn't fast enough to measure this so I'm using my logic analyzer with
puleseview instead: [0]

I added the following code to meson_pwm_request:
  struct pwm_state enable = {
        .enabled = true,
        .period = 349514407U,
        .duty_cycle = 349514407U,
        .polarity = PWM_POLARITY_NORMAL };
  struct pwm_state disable = {
        .enabled = false,
        .period = 349514407U,
        .duty_cycle = 349514407U,
        .polarity = PWM_POLARITY_NORMAL };
  pwm_apply_state(pwm, &enable);
  pwm_apply_state(pwm, &disable);

this returns immediately. my logic analyzer doesn't see signal change
(I'm sampling at 1MHz).

can you please confirm that my test code and measurement procedure is correct?
if it is then my observation is that disabling the PWM does so
immediately, without waiting for the current period to complete


Regards
Martin


[0] https://sigrok.org/wiki/Lcsoft_Mini_Board