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 2024 11:41:26 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Luca Weiss <luca@...tu.xyz>, ~postmarketos/upstreaming@...ts.sr.ht,
 phone-devel@...r.kernel.org, Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] clk: qcom: hfpll: Add QCS404-specific compatible

On 31/12/2023 15:48, Luca Weiss wrote:
> It doesn't appear that the configuration is for the HFPLL is generic, so

That's ok...

> add a qcs404-specific compatible and rename the existing struct to

but why this is the solution? If the qcom,hfpll compatible was
deprecated, but it is not. This commit is contradictory to the bindings.


> qcs404.
> 
> Signed-off-by: Luca Weiss <luca@...tu.xyz>
> ---
>  drivers/clk/qcom/hfpll.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
> index dac27e31ef60..5b12982519be 100644
> --- a/drivers/clk/qcom/hfpll.c
> +++ b/drivers/clk/qcom/hfpll.c
> @@ -14,7 +14,7 @@
>  #include "clk-regmap.h"
>  #include "clk-hfpll.h"
>  
> -static const struct hfpll_data hdata = {
> +static const struct hfpll_data qcs404 = {
>  	.mode_reg = 0x00,
>  	.l_reg = 0x04,
>  	.m_reg = 0x08,
> @@ -84,10 +84,12 @@ static const struct hfpll_data msm8976_cci = {
>  };
>  
>  static const struct of_device_id qcom_hfpll_match_table[] = {
> -	{ .compatible = "qcom,hfpll", .data = &hdata },
>  	{ .compatible = "qcom,msm8976-hfpll-a53", .data = &msm8976_a53 },
>  	{ .compatible = "qcom,msm8976-hfpll-a72", .data = &msm8976_a72 },
>  	{ .compatible = "qcom,msm8976-hfpll-cci", .data = &msm8976_cci },
> +	{ .compatible = "qcom,qcs404-hfpll", .data = &qcs404 },
> +	/* deprecated, use SoC-specific compatible */

Why? That's not a deprecated compatible. You now expect to create many
unnecessary entries, which is not really needed. This is opposite of
what we try to achieve with compatibility lists.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ