linux-kernel - Re: [PATCH 1/7] clk: qcom: clk-alpha-pll: Fix CAL_L

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: <da93a8ed-4fbb-488f-a1af-e701f7191fbd@linaro.org>
Date: Wed, 3 Apr 2024 08:49:09 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Ajit Pandey <quic_ajipan@...cinc.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>, Vinod Koul <vkoul@...nel.org>,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
 linux-kernel@...r.kernel.org, Taniya Das <quic_tdas@...cinc.com>,
 Jagadeesh Kona <quic_jkona@...cinc.com>,
 Imran Shaik <quic_imrashai@...cinc.com>,
 Satya Priya Kakitapalli <quic_skakitap@...cinc.com>
Subject: Re: [PATCH 1/7] clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for
 LUCID EVO PLL

On 02/04/2024 20:35, Ajit Pandey wrote:
> 
> 
> On 3/31/2024 12:49 AM, Krzysztof Kozlowski wrote:
>> On 30/03/2024 19:28, Ajit Pandey wrote:
>>> In LUCID EVO PLL CAL_L_VAL and L_VAL bitfields are part of single
>>> PLL_L_VAL register. Update for L_VAL bitfield values in PLL_L_VAL
>>> register using regmap_write() API in __alpha_pll_trion_set_rate
>>> callback will override LUCID EVO PLL initial configuration related
>>> to PLL_CAL_L_VAL bit fields in PLL_L_VAL register.
>>>
>>> Observed random PLL lock failures during PLL enable due to such
>>> override in PLL calibration value. Use regmap_update_bits() with
>>> L_VAL bitfield mask instead of regmap_write() API to update only
>>> PLL_L_VAL bitfields in __alpha_pll_trion_set_rate callback.
>>>
>>> Fixes: 260e36606a03 ("clk: qcom: clk-alpha-pll: add Lucid EVO PLL configuration interfaces")
>>>
>>
>> No blank lines between tags.
>>
>> Add Cc-stable tag.
>>
> Sure, will update in next series
> 
>> Please do not combine fixes with new features.
>>  > Best regards,
>> Krzysztof
>>
> 
> Actually this fix is required for correct scaling for few frequencies in 
> this patch series, hence combined them together and pushed this fix as 
> first patch in series so that they get mainlined together and feature 
> functionality will not get impacted.

OK, that's fine but usual way is that such need is expressed in the
cover letter, so maintainer will know what to do. What if this patch
should go to fixes and rest normally to for-next? How do you expect
maintainer to apply the patch? Entire thread and then manually move the
commits? Why making it so complicated for the maintainers?

Best regards,
Krzysztof