Hi Vladimir, On Thu, 14 Oct 2021 at 02:19, Vladimir Zapolskiy <vladimir.zapolskiy@xxxxxxxxxx> 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@xxxxxxxxxx> > > Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@xxxxxxxxxx> > > --- > > 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
