linux-kernel - Re: [PATCH v5 3/3] dmaengine: altera-msgdma: add OF support

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: <YL343OIeVZe0Hvod@orolia.com>
Date:   Mon, 7 Jun 2021 12:45:48 +0200
From:   Olivier Dautricourt <olivier.dautricourt@...lia.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Rob Herring <robh+dt@...nel.org>, Stefan Roese <sr@...x.de>,
        dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 3/3] dmaengine: altera-msgdma: add OF support

The 06/07/2021 15:38, Vinod Koul wrote:
> On 07-06-21, 10:28, Olivier Dautricourt wrote:
> > The 06/07/2021 12:29, Vinod Koul wrote:
> > > On 18-05-21, 15:25, Olivier Dautricourt wrote:
> > > > This driver had no device tree support.
> > > >
> > > > - add compatible field "altr,socfpga-msgdma"
> > > > - define msgdma_of_xlate, with no argument
> > > > - register dma controller with of_dma_controller_register
> > > >
> > > > Reviewed-by: Stefan Roese <sr@...x.de>
> > > > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@...lia.com>
> > > > ---
> > > >
> > > > Notes:
> > > >     Changes in v2:
> > > >         none
> > > >
> > > >     Changes from v2 to v3:
> > > >         Removed CONFIG_OF #ifdef's and use if (IS_ENABLED(CONFIG_OF))
> > > >         only once.
> > > >
> > > >     Changes from v3 to v4
> > > >         Reintroduce #ifdef CONFIG_OF for msgdma_match
> > > >         as it produces a unused variable warning
> > > >
> > > >     Changes from v4 to v5
> > > >         - As per Rob's comments on patch 1/2:
> > > >           change compatible field from altr,msgdma to
> > > >           altr,socfpga-msgdma.
> > > >         - change commit title to fit previous commits naming
> > > >         - As per Vinod's comments:
> > > >           - use dma_get_slave_channel instead of dma_get_any_slave_channel which
> > > >             makes more sense.
> > > >           - remove if (IS_ENABLED(CONFIG_OF)) for of_dma_controller_register
> > > >             as it is taken care by the core
> > > >
> > > >  drivers/dma/altera-msgdma.c | 26 ++++++++++++++++++++++++++
> > > >  1 file changed, 26 insertions(+)
> > > >
> > > > diff --git a/drivers/dma/altera-msgdma.c b/drivers/dma/altera-msgdma.c
> > > > index 9a841ce5f0c5..acf0990d73ae 100644
> > > > --- a/drivers/dma/altera-msgdma.c
> > > > +++ b/drivers/dma/altera-msgdma.c
> > > > @@ -19,6 +19,7 @@
> > > >  #include <linux/module.h>
> > > >  #include <linux/platform_device.h>
> > > >  #include <linux/slab.h>
> > > > +#include <linux/of_dma.h>
> > > >
> > > >  #include "dmaengine.h"
> > > >
> > > > @@ -784,6 +785,14 @@ static int request_and_map(struct platform_device *pdev, const char *name,
> > > >       return 0;
> > > >  }
> > > >
> > > > +static struct dma_chan *msgdma_of_xlate(struct of_phandle_args *dma_spec,
> > > > +                                     struct of_dma *ofdma)
> > > > +{
> > > > +     struct msgdma_device *d = ofdma->of_dma_data;
> > > > +
> > > > +     return dma_get_slave_channel(&d->dmachan);
> > > > +}
> > >
> > > Why not use of_dma_simple_xlate() instead?
> > I guess i could, but i don't think i need to define a filter function,
> > also there is only one possible channel.
>
> Yeah no point in adding filter_fn. I guess we need
> of_dma_xlate_by_chan_id() here, I guess you are specifying channel in dts
> right? If not above would be okay
Yes i am, but as this controller has only one channel I was thinking not to fail
if something other than chan_id == 0 is specified. But it may not be right,
I could also remove the argument in the device tree but dma controller
schema expects at least one argument.
Now i think maybe it makes more sense to use of_dma_xlate_by_chan_id and
expect chan_id == 0 in the dt.
>
> > >
> > > > +
> > > >  /**
> > > >   * msgdma_probe - Driver probe function
> > > >   * @pdev: Pointer to the platform_device structure
> > > > @@ -888,6 +897,13 @@ static int msgdma_probe(struct platform_device *pdev)
> > > >       if (ret)
> > > >               goto fail;
> > > >
> > > > +     ret = of_dma_controller_register(pdev->dev.of_node,
> > > > +                                      msgdma_of_xlate, mdev);
> > > > +     if (ret) {
> > > > +             dev_err(&pdev->dev, "failed to register dma controller");
> > > > +             goto fail;
> > >
> > > Should this be treated as an error.. the probe will be invoked on non of
> > > systems too..
> > Ok, i'm a bit confused,
> > in v4 those lines were enclosed with 'if (IS_ENABLED(CONFIG_OF)) { }'
> > when you said to me that it was already taken care by the core i though
> > that of_dma_controller_register will return 0 on non-of systems.
> > Now i can add back IS_ENABLED(CONFIG_OF) or discard the ret value.
>
> Well including in CONFIG_OF sounded protection from compilation which is
> not required.
>
> Now the issue is that you maybe running on a system which may or maynot
> have DT and even on DT based systems your device may not be DT one..
good catch, i forgot this use-case ..
>
> So i think the return should be handled here if DT device is not present
> and warn that and continue for not DT modes.. Also someone who has this
> non DT device should test the changes
I can do that.

I think Stefan used this driver on non-DT platform but he said
that he has no access to the hardware anymore.
>
>
> Thanks
> --
> ~Vinod

--
Olivier Dautricourt