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: <68f9bee2-5a5b-2962-6c3d-e73ade371545@linaro.org>
Date:   Fri, 12 May 2023 19:01:24 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Komal Bajaj <quic_kbajaj@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc:     linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v3 04/10] nvmem: qfprom: Add support for secure reading on
 QDU1000/QRU1000

On 12/05/2023 14:21, Komal Bajaj wrote:
> Add qfprom driver support for QDU1000/QRU1000 SOCs.
> 
> Signed-off-by: Komal Bajaj <quic_kbajaj@...cinc.com>
> ---
>  drivers/nvmem/qfprom.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
> index 20662e2d3732..12a7981a8a71 100644
> --- a/drivers/nvmem/qfprom.c
> +++ b/drivers/nvmem/qfprom.c
> @@ -109,6 +109,10 @@ struct qfprom_soc_compatible_data {
>  	bool secure;
>  };
> 
> +static const struct qfprom_soc_compatible_data qdu1000_qfprom = {
> +	.secure = true
> +};
> +
>  static const struct nvmem_keepout sc7180_qfprom_keepout[] = {
>  	{.start = 0x128, .end = 0x148},
>  	{.start = 0x220, .end = 0x228}
> @@ -490,6 +494,7 @@ static int qfprom_probe(struct platform_device *pdev)
> 
>  static const struct of_device_id qfprom_of_match[] = {
>  	{ .compatible = "qcom,qfprom",},
> +	{ .compatible = "qcom,qdu1000-qfprom", .data = &qdu1000_qfprom},
>  	{ .compatible = "qcom,sc7180-qfprom", .data = &sc7180_qfprom},

I have doubts that this is still compatible with qcom,qfprom. It uses
entirely different read method. That's why generic fallbacks are bad,
one more case to my growing list of awesome examples. :)

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ