linux-kernel - Re: [PATCH v4 0/1] Change PWM-controlled LED pin active mode and algorithm

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: <CAHh=Yk842gFpR1a3=KiB-Yb7T1Dqbg627MBK+hntjgMtd5z6-w@mail.gmail.com>
Date:   Fri, 4 Aug 2023 14:54:33 +0800
From:   Nylon Chen <nylon.chen@...ive.com>
To:     Conor Dooley <conor.dooley@...rochip.com>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-riscv@...ts.infradead.org, geert+renesas@...der.be,
        pavel@....cz, vincent.chen@...ive.com,
        emil.renner.berthing@...onical.com, aou@...s.berkeley.edu,
        palmer@...belt.com, paul.walmsley@...ive.com,
        krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org,
        conor@...nel.org, zong.li@...ive.com
Subject: Re: [PATCH v4 0/1] Change PWM-controlled LED pin active mode and algorithm

Hi Conor,

Thank you for patiently giving me advice. I appreciate your help.

Not long ago, I said, "This patch needs to be accompanied by
modifications to the pwm_sifive_apply() function to make sense."

I recently reviewed the v3 version, and after discussing it with Emil,
there are several areas that require modification. I will provide the
necessary changes for each of them:

1. polarity check. (Suggestion from Uwe)
- if (state->polarity != PWM_POLARITY_INVERSED)
+ if (state->polarity != PWM_POLARITY_NORMAL)
2. avoid using old periodperiod, not state->period
- period = max(state->period, ddata->approx_period);
- frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
+ frac = DIV64_U64_ROUND_CLOSEST(num, period);
3. add a conditional check can be added in the code to set
ddata->approx_period to state->period when state->period is smaller
than ddata->approx_period
  if (state->period != ddata->approx_period) {
  ...
+       if (state->period < ddata->approx_period) {
+               ddata->approx_period = state->period;
+       }
-       ddata->approx_period = state->period;
+       period = ddata->approx_period;

I will use 'unmatched' on my end to verify again. If there are any
other errors, feel free to point them out. Thank you.

Nylon Chen <nylon.chen@...ive.com> 於 2023年8月4日 週五 上午9:42寫道：
>
> Hi Conor,
>
> Conor Dooley <conor.dooley@...rochip.com> 於 2023年8月3日 週四 下午5:44寫道：
> >
> > Hey Nylon,
> >
> > (I yoinked the reply to 1/1 to here, as it makes more sense in this
> > context)
> >
> > > On Thu, Aug 03, 2023 at 10:15:10AM +0100, Conor Dooley wrote:
> > > > On Thu, Aug 03, 2023 at 04:57:33PM +0800, Nylon Chen wrote:
> > > > > According to the circuit diagram of User LEDs - RGB described in themanual hifive-unleashed-a00.pdf[0] and hifive-unmatched-schematics-v3.pdf[1].
> > > > >
> > > > > The behavior of PWM is acitve-high.
> > > > >
> > > > > Removed patches: 1
> > > > > New patches: (none)
> > > > >
> > > > > Links:
> > > > > - [0]:  https://sifive.cdn.prismic.io/sifive/c52a8e32-05ce-4aaf-95c8-7bf8453f8698_hifive-unleashed-a00-schematics-1.pdf
> > > > > - [1]:  https://sifive.cdn.prismic.io/sifive/6a06d6c0-6e66-49b5-8e9e-e68ce76f4192_hifive-unmatched-schematics-v3.pdf
> > > > > - [2]:  https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf
> > > > >
> > > > > Changed in v4:
> > > > >  - Remove previous updates to the PWM algorithm.
> > > >
> > > > Why? I don't recall the conclusion on the previous version being that
> > > > that patch was not needed.
> > >
> > > I apologize for forgetting about this update earlier. Just now,
> > > I tried to pull rebase master and noticed that other developers seem
> > > to have made some fixes to the algorithm. Upon closer inspection, I
> > > found that they addressed the part we previously discussed with Emil
> > > and Uwe, such as "first pwm_apply_state."
> > >
> > > Therefore, my instinct tells me that they have already taken care of
> > > the issues we discussed before.
> >
> > I didn't see anything in linux-next that would solve this problem of
> > inversion. The last meaningful change is:
> >         commit 334c7b13d38321e47d1a51dba0bef9f4c403ec75
> >         Author:     Emil Renner Berthing <emil.renner.berthing@...onical.com>
> >         AuthorDate: Wed Nov 9 12:37:24 2022 +0100
> >         Commit:     Thierry Reding <thierry.reding@...il.com>
> >         CommitDate: Mon Jan 30 16:42:45 2023 +0100
> >
> >             pwm: sifive: Always let the first pwm_apply_state succeed
> >
> > which predates your v3 by quite a bit.
> >
> > > I will review the conflicting parts in the pwm-sifive.c code in my v4
> > > version once again to ensure there are no omissions. If I find any, I
> > > will submit v5 accordingly.
> >
> > And if this patch is okay in isolation, please reply here explaining
> > which commit fixed the algorithm, so that I can pick it up.
> This patch needs to be accompanied by modifications to the
> pwm_sifive_apply() function to make sense.
>
> I will double-check and review the previous discussions to ensure
> that. Thank you for your response.
> >
> > Thanks,
> > Conor.