linux-kernel - Re: [PATCH RFT] arm64: dts: qcom: sm8350: Reenable crypto & cryptobam

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: <CAA8EJppCAMXds5F4bgeb9VJSwph-+4ekVsJ=rGib5=RR5m0DPg@mail.gmail.com>
Date: Tue, 9 Jan 2024 00:45:45 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Luca Weiss <luca.weiss@...rphone.com>
Cc: Konrad Dybcio <konrad.dybcio@...aro.org>, Andy Gross <agross@...nel.org>, 
	Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Bhupesh Sharma <bhupesh.linux@...il.com>, David Heidelberg <david@...t.cz>, 
	Stephan Gerhold <stephan@...hold.net>, ~postmarketos/upstreaming@...ts.sr.ht, 
	phone-devel@...r.kernel.org, 
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, linux-arm-msm@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFT] arm64: dts: qcom: sm8350: Reenable crypto & cryptobam

On Mon, 8 Jan 2024 at 16:23, Luca Weiss <luca.weiss@...rphone.com> wrote:
>
> On Mon Jan 8, 2024 at 3:18 PM CET, Konrad Dybcio wrote:
> > On 8.01.2024 14:49, Luca Weiss wrote:
> > > When num-channels and qcom,num-ees is not provided in devicetree, the
> > > driver will try to read these values from the registers during probe but
> > > this fails if the interconnect is not on and then crashes the system.
> > >
> > > So we can provide these properties in devicetree (queried after patching
> > > BAM driver to enable the necessary interconnect) so we can probe
> > > cryptobam without reading registers and then also use the QCE as
> > > expected.
> >
> > This really feels a bit backwards.. Enable the resource to query the
> > hardware for numbers, so that said resource can be enabled, but
> > slightly later :/
>
> If you think adding interconnect support to driver and dtsi is better,
> let me know.

I'd say, adding the proper interconnect is a better option. Otherwise
we just depend on the QCE itself to set up the vote for us.

>
> Stephan (+CC) mentioned it should be okay like this *shrug*
>
> For the record, this is the same way I got the values for sc7280[0] and
> sm6350[1].
>
> [0] https://lore.kernel.org/linux-arm-msm/20231229-sc7280-cryptobam-fixup-v1-1-bd8f68589b80@fairphone.com/
> [1] https://lore.kernel.org/linux-arm-msm/20240105-sm6350-qce-v1-0-416e5c7319ac@fairphone.com/
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index b46236235b7f..cd4dd9852d9e 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> @@ -1756,8 +1756,8 @@ cryptobam: dma-controller@...4000 {
>                         qcom,controlled-remotely;
>                         iommus = <&apps_smmu 0x594 0x0011>,
>                                  <&apps_smmu 0x596 0x0011>;
> -                       /* FIXME: Probing BAM DMA causes some abort and system hang */
> -                       status = "fail";
> +                       interconnects = <&aggre2_noc MASTER_CRYPTO 0 &mc_virt SLAVE_EBI1 0>;
> +                       interconnect-names = "memory";
>                 };
>
>                 crypto: crypto@...a000 {
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 5e7d332731e0..9de28f615639 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -40,6 +40,7 @@
>  #include <linux/circ_buf.h>
>  #include <linux/clk.h>
>  #include <linux/dmaengine.h>
> +#include <linux/interconnect.h>
>  #include <linux/pm_runtime.h>
>
>  #include "../dmaengine.h"
> @@ -394,6 +395,7 @@ struct bam_device {
>         const struct reg_offset_data *layout;
>
>         struct clk *bamclk;
> +       struct icc_path *mem_path;
>         int irq;
>
>         /* dma start transaction tasklet */
> @@ -1206,6 +1208,7 @@ static int bam_init(struct bam_device *bdev)
>                 bdev->num_channels = val & BAM_NUM_PIPES_MASK;
>         }
>
> +       printk(KERN_ERR "%s:%d DBG num_ees=%u num_channels=%u\n", __func__, __LINE__, bdev->num_ees, bdev->num_channels);
>         /* Reset BAM now if fully controlled locally */
>         if (!bdev->controlled_remotely && !bdev->powered_remotely)
>                 bam_reset(bdev);
> @@ -1298,6 +1301,14 @@ static int bam_dma_probe(struct platform_device *pdev)
>                 return ret;
>         }
>
> +       bdev->mem_path = devm_of_icc_get(bdev->dev, "memory");
> +       if (IS_ERR(bdev->mem_path))
> +               return PTR_ERR(bdev->mem_path);
> +
> +       ret = icc_set_bw(bdev->mem_path, 1, 1);

Probably this needs some more sensible value.

> +       if (ret)
> +               return ret;
> +
>         ret = bam_init(bdev);
>         if (ret)
>                 goto err_disable_clk;
>


-- 
With best wishes
Dmitry