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: Wed, 3 Apr 2024 16:37:41 +0530
From: Ajit Pandey <quic_ajipan@...cinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>
CC: 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>,
        <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 4/3/2024 2:20 PM, Krzysztof Kozlowski wrote:
> On 03/04/2024 10:37, Dmitry Baryshkov wrote:
>> On Wed, 3 Apr 2024 at 09:49, Krzysztof Kozlowski
>> <krzysztof.kozlowski@...aro.org> wrote:
>>>
>>> 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?
>>
OK, for the ease and more clarity I'll update the cover letter with fix 
details and required dependency on this feature in next series.

>> Huh? I think it's pretty normal to have fixes in front of the patch
>> series. Having it in the middle would be troublesome indeed. You are
>> the first person to complain.
> 
> No, I am not the first. It differs between subsystems and I do not
> recall all folks, but the one person coming to my mind is Mark Brown who
> expressed it numerous times.
> 
> Best regards,
> Krzysztof
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ