linux-kernel - Re: [PATCH v4 5/7] cpufreq: qcom-hw: Implement CPRh aware OSM programming

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: <20210413034940.o6uzjtnh2ylvikbf@vireshk-i7>
Date:   Tue, 13 Apr 2021 09:19:40 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Taniya Das <tdas@...eaurora.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>, agross@...nel.org,
        rjw@...ysocki.net, devicetree@...r.kernel.org, robh+dt@...nel.org,
        amit.kucheria@...aro.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org,
        konrad.dybcio@...ainline.org, marijn.suijten@...ainline.org,
        martin.botka@...ainline.org, jeffrey.l.hugo@...il.com
Subject: Re: [PATCH v4 5/7] cpufreq: qcom-hw: Implement CPRh aware OSM
 programming

On 12-04-21, 15:01, Taniya Das wrote:
> Technically the HW we are trying to program here differs in terms of
> clocking, the LUT definitions and many more. It will definitely make
> debugging much more troublesome if we try to accomodate multiple versions of
> CPUFREQ-HW in the same code.
> 
> Thus to keep it simple, easy to read, debug, the suggestion is to keep it
> with "v1" tag as the OSM version we are trying to put here is from OSM1.0.

That is a valid point and is always a case with so many drivers. What
I am concerned about is how much code is common across versions, if it
is 5-70%, or more, then we should definitely share, arrange to have
callbacks or ops per version and call them in a generic fashion instead
of writing a new driver. This is what's done across
drivers/frameworks, etc.

-- 
viresh