linux-kernel - Re: [PATCH 1/4] clk: qcom: clk-rcg2: Fail Duty-Cycle configuration if MND divider is not enabled.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220110201452.2B3E4C36AE3@smtp.kernel.org>
Date:   Mon, 10 Jan 2022 12:14:50 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Nikita Travkin <nikita@...n.ru>
Cc:     linus.walleij@...aro.org, mturquette@...libre.com,
        bjorn.andersson@...aro.org, agross@...nel.org, tdas@...eaurora.org,
        svarbanov@...sol.com, linux-arm-msm@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH 1/4] clk: qcom: clk-rcg2: Fail Duty-Cycle configuration if MND divider is not enabled.

Quoting Nikita Travkin (2022-01-07 23:25:19)
> Hi,
> 
> Stephen Boyd писал(а) 08.01.2022 05:52:
> > Quoting Nikita Travkin (2021-12-09 08:37:17)
> I'm adding this error here primarily to bring attention of the
> user (e.g. developer enabling some peripheral that needs
> duty cycle control) who might have to change their clock tree
> to make this control effective. So, assuming that if someone
> sets the duty cycle to 50% then they might set it to some other
> value later, it makes sense to fail the first call anyway.
> 
> If you think there are some other possibilities for this call
> to happen specifically with 50% duty cycle (e.g. some
> preparations or cleanups in the clk subsystem or some drivers
> that I'm not aware of) then I can make an exemption in the check
> for that.
> 

I don't see anywhere in clk_set_duty_cycle() where it would bail out
early if the duty cycle was set to what it already is. The default for
these clks is 50%, so I worry that some driver may try to set the duty
cycle to 50% and then fail now. Either we need to check the duty cycle
in the core before calling down into the driver or we need to check it
here in the driver. Can you send a patch to check the current duty cycle
in the core before calling down into the clk ops?