| Message ID | 20211013105541.68045-19-bhupesh.sharma@linaro.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Enable Qualcomm Crypto Engine on sm8250 | expand |
Hi Bhupesh, On 10/13/21 1:55 PM, Bhupesh Sharma wrote: > Since the Qualcomm qce crypto driver needs the BAM dma driver to be > setup first (to allow crypto operations), it makes sense to defer > the qce crypto driver probing in case the BAM dma driver is not yet > probed. > > Move the code leg requesting dma channels earlier in the > probe() flow. This fixes the qce probe failure issues when both qce > and BMA dma are compiled as static part of the kernel. > > Cc: Thara Gopinath <thara.gopinath@linaro.org> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> > --- > drivers/crypto/qce/core.c | 20 ++++++++++++-------- > 1 file changed, 12 insertions(+), 8 deletions(-) > > diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c > index cb8c77709e1e..c6f686126fc9 100644 > --- a/drivers/crypto/qce/core.c > +++ b/drivers/crypto/qce/core.c > @@ -209,9 +209,19 @@ static int qce_crypto_probe(struct platform_device *pdev) > if (ret < 0) > return ret; > > + /* qce driver requires BAM dma driver to be setup first. I believe a multi-line block of comments should be started with '/*' line, for reference please take a look at Documentation/process/coding-style.rst > + * In case the dma channel are not set yet, this check > + * helps use to return -EPROBE_DEFER earlier. > + */ > + ret = qce_dma_request(qce->dev, &qce->dma); > + if (ret) > + return ret; > + > qce->mem_path = of_icc_get(qce->dev, "memory"); > - if (IS_ERR(qce->mem_path)) > + if (IS_ERR(qce->mem_path)) { > + qce_dma_release(&qce->dma); > return PTR_ERR(qce->mem_path); > + } > > qce->core = devm_clk_get_optional(qce->dev, "core"); > if (IS_ERR(qce->core)) { > @@ -247,10 +257,6 @@ static int qce_crypto_probe(struct platform_device *pdev) > if (ret) > goto err_clks_iface; > > - ret = qce_dma_request(qce->dev, &qce->dma); > - if (ret) > - goto err_clks; > - > ret = qce_check_version(qce); > if (ret) > goto err_clks; > @@ -265,12 +271,10 @@ static int qce_crypto_probe(struct platform_device *pdev) > > ret = qce_register_algs(qce); > if (ret) > - goto err_dma; > + goto err_clks; > > return 0; > > -err_dma: > - qce_dma_release(&qce->dma); > err_clks: > clk_disable_unprepare(qce->bus); > err_clks_iface: > -- Best wishes, Vladimir
Hi Vladimir, On Thu, 14 Oct 2021 at 02:19, Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> wrote: > > Hi Bhupesh, > > On 10/13/21 1:55 PM, Bhupesh Sharma wrote: > > Since the Qualcomm qce crypto driver needs the BAM dma driver to be > > setup first (to allow crypto operations), it makes sense to defer > > the qce crypto driver probing in case the BAM dma driver is not yet > > probed. > > > > Move the code leg requesting dma channels earlier in the > > probe() flow. This fixes the qce probe failure issues when both qce > > and BMA dma are compiled as static part of the kernel. > > > > Cc: Thara Gopinath <thara.gopinath@linaro.org> > > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> > > --- > > drivers/crypto/qce/core.c | 20 ++++++++++++-------- > > 1 file changed, 12 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c > > index cb8c77709e1e..c6f686126fc9 100644 > > --- a/drivers/crypto/qce/core.c > > +++ b/drivers/crypto/qce/core.c > > @@ -209,9 +209,19 @@ static int qce_crypto_probe(struct platform_device *pdev) > > if (ret < 0) > > return ret; > > > > + /* qce driver requires BAM dma driver to be setup first. > > I believe a multi-line block of comments should be started with '/*' line, > for reference please take a look at Documentation/process/coding-style.rst There are exceptions to this rule as well. For e.g. see most of the networking drivers and the multi-line comment styles there :) . There is a very interesting LWN article on the same : https://lwn.net/Articles/694755/ Note that 'crypto/' and 'drivers/crypto' use these non-standard multi-line comments quite often as well. That said, I have no strong opinion on using either style. Although, I found one of the points raised by the networking maintainer during one of my patch reviews earlier quite useful - 'keeping the top line in a multi-line comment blank, wastes precious screen space while reading and reviewing the patch'. Regards, Bhupesh > > + * In case the dma channel are not set yet, this check > > + * helps use to return -EPROBE_DEFER earlier. > > + */ > > + ret = qce_dma_request(qce->dev, &qce->dma); > > + if (ret) > > + return ret; > > + > > qce->mem_path = of_icc_get(qce->dev, "memory"); > > - if (IS_ERR(qce->mem_path)) > > + if (IS_ERR(qce->mem_path)) { > > + qce_dma_release(&qce->dma); > > return PTR_ERR(qce->mem_path); > > + } > > > > qce->core = devm_clk_get_optional(qce->dev, "core"); > > if (IS_ERR(qce->core)) { > > @@ -247,10 +257,6 @@ static int qce_crypto_probe(struct platform_device *pdev) > > if (ret) > > goto err_clks_iface; > > > > - ret = qce_dma_request(qce->dev, &qce->dma); > > - if (ret) > > - goto err_clks; > > - > > ret = qce_check_version(qce); > > if (ret) > > goto err_clks; > > @@ -265,12 +271,10 @@ static int qce_crypto_probe(struct platform_device *pdev) > > > > ret = qce_register_algs(qce); > > if (ret) > > - goto err_dma; > > + goto err_clks; > > > > return 0; > > > > -err_dma: > > - qce_dma_release(&qce->dma); > > err_clks: > > clk_disable_unprepare(qce->bus); > > err_clks_iface: > > > > -- > Best wishes, > Vladimir
Hi Bhupesh, On 10/14/21 10:40 AM, Bhupesh Sharma wrote: > Hi Vladimir, > > On Thu, 14 Oct 2021 at 02:19, Vladimir Zapolskiy > <vladimir.zapolskiy@linaro.org> wrote: >> >> Hi Bhupesh, >> >> On 10/13/21 1:55 PM, Bhupesh Sharma wrote: >>> Since the Qualcomm qce crypto driver needs the BAM dma driver to be >>> setup first (to allow crypto operations), it makes sense to defer >>> the qce crypto driver probing in case the BAM dma driver is not yet >>> probed. >>> >>> Move the code leg requesting dma channels earlier in the >>> probe() flow. This fixes the qce probe failure issues when both qce >>> and BMA dma are compiled as static part of the kernel. >>> >>> Cc: Thara Gopinath <thara.gopinath@linaro.org> >>> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> >>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> >>> --- >>> drivers/crypto/qce/core.c | 20 ++++++++++++-------- >>> 1 file changed, 12 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c >>> index cb8c77709e1e..c6f686126fc9 100644 >>> --- a/drivers/crypto/qce/core.c >>> +++ b/drivers/crypto/qce/core.c >>> @@ -209,9 +209,19 @@ static int qce_crypto_probe(struct platform_device *pdev) >>> if (ret < 0) >>> return ret; >>> >>> + /* qce driver requires BAM dma driver to be setup first. >> >> I believe a multi-line block of comments should be started with '/*' line, >> for reference please take a look at Documentation/process/coding-style.rst > > There are exceptions to this rule as well. For e.g. see most of the > networking drivers and the multi-line comment styles there :) . > > There is a very interesting LWN article on the same : > https://lwn.net/Articles/694755/ > Note that 'crypto/' and 'drivers/crypto' use these non-standard > multi-line comments quite often as well. Ah, yes, I agree here, thank you for the reminder! IIRC crypto drivers kind of belong to netdev domain, at least in relation to the accepted coding style. > That said, I have no strong opinion on using either style. Although, I > found one of the points raised by the networking maintainer during one > of my patch reviews earlier quite useful - 'keeping the top line in a > multi-line comment blank, wastes precious screen space while reading > and reviewing the patch'. -- Best wishes, Vladimir
On 10/13/21 6:55 AM, Bhupesh Sharma wrote: > Since the Qualcomm qce crypto driver needs the BAM dma driver to be > setup first (to allow crypto operations), it makes sense to defer > the qce crypto driver probing in case the BAM dma driver is not yet > probed. > > Move the code leg requesting dma channels earlier in the > probe() flow. This fixes the qce probe failure issues when both qce > and BMA dma are compiled as static part of the kernel. Hi Bhupesh, I am quite curious to know the nature of probe failure you are seeing with the current sequence. I am not against changing the sequence but for me when a driver is enabled, it is clocks first, interconnect next and then dma. Also I have tested the current sequence on sm8150 with both the modules built in as static and I have not seen the failure.
Hi Thara, On Wed, 20 Oct 2021 at 19:40, Thara Gopinath <thara.gopinath@linaro.org> wrote: > > On 10/13/21 6:55 AM, Bhupesh Sharma wrote: > > Since the Qualcomm qce crypto driver needs the BAM dma driver to be > > setup first (to allow crypto operations), it makes sense to defer > > the qce crypto driver probing in case the BAM dma driver is not yet > > probed. > > > > Move the code leg requesting dma channels earlier in the > > probe() flow. This fixes the qce probe failure issues when both qce > > and BMA dma are compiled as static part of the kernel. > > Hi Bhupesh, > > I am quite curious to know the nature of probe failure you are seeing > with the current sequence. I am not against changing the sequence but > for me when a driver is enabled, it is clocks first, interconnect next > and then dma. Also I have tested the current sequence on sm8150 with > both the modules built in as static and I have not seen the failure. Sure. The problem I faced was the following. Let's consider the scenario where while the qce crypto driver and the interconnect are compiled as static parts of the kernel, the bam DMA driver is compiled as a module, then the -EPROBE_DEFER return leg from the qce crypto driver is very late in the probe() flow, as we first turn on the clocks and then the interconnect. Now the suggested linux deferred probe implementation is to return as early from the caling driver in case the called driver (subdev) is not yet ready. SInce the qce crypto driver requires the bam DMA to be set up first, it makes sense to move 'qce_dma_request' early in the boot flow. If it's not yet probed(), it probably doesn't make sense to set up the clks and interconnects yet in the qce driver. We can do it later when the bam DMA is setup. I have tested the following combinations with the change I made in this patchset: 1. qce - static, bam - module, interconnect - module -> qce_dma_request returned -EPROBE_DEFER 2. qce - static, bam - module, interconnect - static -> qce_dma_request returned -EPROBE_DEFER 3. qce - static, bam - static, interconnect - module -> qce_dma_request returned -EPROBE_DEFER 4. qce - static, bam - static, interconnect - static -> no -EPROBE_DEFER Thanks, Bhupesh > > Cc: Thara Gopinath <thara.gopinath@linaro.org> > > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> > > --- > > drivers/crypto/qce/core.c | 20 ++++++++++++-------- > > 1 file changed, 12 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c > > index cb8c77709e1e..c6f686126fc9 100644 > > --- a/drivers/crypto/qce/core.c > > +++ b/drivers/crypto/qce/core.c > > @@ -209,9 +209,19 @@ static int qce_crypto_probe(struct platform_device *pdev) > > if (ret < 0) > > return ret; > > > > + /* qce driver requires BAM dma driver to be setup first. > > + * In case the dma channel are not set yet, this check > > + * helps use to return -EPROBE_DEFER earlier. > > + */ > > + ret = qce_dma_request(qce->dev, &qce->dma); > > + if (ret) > > + return ret; > > + > > qce->mem_path = of_icc_get(qce->dev, "memory"); > > - if (IS_ERR(qce->mem_path)) > > + if (IS_ERR(qce->mem_path)) { > > + qce_dma_release(&qce->dma); > > return PTR_ERR(qce->mem_path); > > + } > > > > qce->core = devm_clk_get_optional(qce->dev, "core"); > > if (IS_ERR(qce->core)) { > > @@ -247,10 +257,6 @@ static int qce_crypto_probe(struct platform_device *pdev) > > if (ret) > > goto err_clks_iface; > > > > - ret = qce_dma_request(qce->dev, &qce->dma); > > - if (ret) > > - goto err_clks; > > - > > ret = qce_check_version(qce); > > if (ret) > > goto err_clks; > > @@ -265,12 +271,10 @@ static int qce_crypto_probe(struct platform_device *pdev) > > > > ret = qce_register_algs(qce); > > if (ret) > > - goto err_dma; > > + goto err_clks; > > > > return 0; > > > > -err_dma: > > - qce_dma_release(&qce->dma); > > err_clks: > > clk_disable_unprepare(qce->bus); > > err_clks_iface: > > > >
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c index cb8c77709e1e..c6f686126fc9 100644 --- a/drivers/crypto/qce/core.c +++ b/drivers/crypto/qce/core.c @@ -209,9 +209,19 @@ static int qce_crypto_probe(struct platform_device *pdev) if (ret < 0) return ret; + /* qce driver requires BAM dma driver to be setup first. + * In case the dma channel are not set yet, this check + * helps use to return -EPROBE_DEFER earlier. + */ + ret = qce_dma_request(qce->dev, &qce->dma); + if (ret) + return ret; + qce->mem_path = of_icc_get(qce->dev, "memory"); - if (IS_ERR(qce->mem_path)) + if (IS_ERR(qce->mem_path)) { + qce_dma_release(&qce->dma); return PTR_ERR(qce->mem_path); + } qce->core = devm_clk_get_optional(qce->dev, "core"); if (IS_ERR(qce->core)) { @@ -247,10 +257,6 @@ static int qce_crypto_probe(struct platform_device *pdev) if (ret) goto err_clks_iface; - ret = qce_dma_request(qce->dev, &qce->dma); - if (ret) - goto err_clks; - ret = qce_check_version(qce); if (ret) goto err_clks; @@ -265,12 +271,10 @@ static int qce_crypto_probe(struct platform_device *pdev) ret = qce_register_algs(qce); if (ret) - goto err_dma; + goto err_clks; return 0; -err_dma: - qce_dma_release(&qce->dma); err_clks: clk_disable_unprepare(qce->bus); err_clks_iface:
Since the Qualcomm qce crypto driver needs the BAM dma driver to be setup first (to allow crypto operations), it makes sense to defer the qce crypto driver probing in case the BAM dma driver is not yet probed. Move the code leg requesting dma channels earlier in the probe() flow. This fixes the qce probe failure issues when both qce and BMA dma are compiled as static part of the kernel. Cc: Thara Gopinath <thara.gopinath@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> --- drivers/crypto/qce/core.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-)