linux-kernel - Re: [PATCH 01/33] clk_ops: change round

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]

Date:   Tue, 2 Jan 2018 11:01:59 -0800
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Bryan O'Donoghue <pure.logic@...us-software.ie>
Cc:     Mikko Perttunen <cyndis@...si.fi>, mturquette@...libre.com,
        linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mips@...ux-mips.org, linux-rpi-kernel@...ts.infradead.org,
        patches@...nsource.cirrus.com,
        uclinux-h8-devel@...ts.sourceforge.jp,
        linux-amlogic@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
        linux-soc@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-rockchip@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        linux-mediatek@...ts.infradead.org,
        freedreno@...ts.freedesktop.org, linux-media@...r.kernel.org,
        linux-rtc@...r.kernel.org
Subject: Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned
 long

On 12/31, Bryan O'Donoghue wrote:
> On 30/12/17 16:36, Mikko Perttunen wrote:
> >FWIW, we had this problem some years ago with the Tegra CPU clock
> >- then it was determined that a simpler solution was to have the
> >determine_rate callback support unsigned long rates - so clock
> >drivers that need to return rates higher than 2^31 can instead
> >implement the determine_rate callback. That is what's currently
> >implemented.
> >
> >Mikko
> 
> Granted we could work around it but, having both zero and less than
> zero indicate error means you can't support larger than LONG_MAX
> which is I think worth fixing.
> 

Ok. But can you implement the determine_rate op instead of the
round_rate op for your clk? It's not a work-around, it's the
preferred solution. That would allow rates larger than 2^31 for
the clk without pushing through a change to all the drivers to
express zero as "error" and non-zero as the rounded rate.

I'm not entirely opposed to this approach, because we probably
don't care to pass the particular error value from a clk provider
to a clk consumer about what the error is. It's actually what we
proposed as the solution for clk_round_rate() to return values
larger than LONG_MAX to consumers. But doing that consumer API
change or this provider side change is going to require us to
evaluate all the consumers of these clks to make sure they don't
check for some error value that's less than zero. This series
does half the work, by changing the provider side, while ignoring
the consumer side and any potential fallout of the less than zero
to zero return value change.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project