linux-kernel - Re: [PATCH 2/3] k3dma: add support to reserved minimum channels

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: <CAFGCpxwkdJQAf9bwHTLp+Zc5ASbnFQn9UDsA+zFCH7UZJy9aBQ@mail.gmail.com>
Date:   Fri, 6 Jul 2018 11:05:21 +0800
From:   Guodong Xu <guodong.xu@...aro.org>
To:     vkoul@...nel.org
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>, dan.j.williams@...el.com,
        liyu65@...ilicon.com, Suzhuangluan <suzhuangluan@...ilicon.com>,
        "xuhongtao (A)" <xuhongtao8@...ilicon.com>,
        zhongkaihua <zhongkaihua@...wei.com>,
        Xuezhiliang <xuezhiliang@...ilicon.com>,
        "xupeng (Q)" <xupeng7@...wei.com>, sunliang10@...wei.com,
        "Fengbaopeng (kevin, Kirin Solution Dept)" 
        <fengbaopeng@...ilicon.com>, dmaengine@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] k3dma: add support to reserved minimum channels

On Thu, Jun 28, 2018 at 2:02 PM Vinod <vkoul@...nel.org> wrote:
>
> On 22-06-18, 11:24, Guodong Xu wrote:
> > From: Li Yu <liyu65@...ilicon.com>
> >
> > On k3 series of SoC, DMA controller reserves some channels for
> > other on-chip coprocessors. By adding support to dma_min_chan, kernel
> > will not be able to use these reserved channels.
> >
> > One example is on Hi3660 platform, channel 0 is reserved to lpm3.
> >
> > Please also refer to Documentation/devicetree/bindings/dma/k3dma.txt
>
> and if some other platform has channel X marked for co-processor, maybe
> a last channel or something in middle, how will this work then?
>
Hi， Vinod

Sorry for delayed response. We checked with Kirin hardware design
team, so far their design strategy is all Kirin SoC series reserve
only from minimum side, saying channel 0, then 1, then 2. That impacts
the current SoC in upstreaming, Kirin960 (Hi3660), and next versions
in Kirin SoC, Kirin970 and 980, which may hit upstream later.

> I am thinking this should be a mask, rather than min.
>

So, since this driver k3dma.c is only used by Kirin SoC DMA
controllers, I would prefer to keep the current design dma_min_chan
unchanged.

What do you think?

-Guodong


> >
> > Signed-off-by: Li Yu <liyu65@...ilicon.com>
> > Signed-off-by: Guodong Xu <guodong.xu@...aro.org>
> > ---
> >  drivers/dma/k3dma.c | 13 ++++++++-----
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
> > index fa31cccbe04f..13cec12742e3 100644
> > --- a/drivers/dma/k3dma.c
> > +++ b/drivers/dma/k3dma.c
> > @@ -113,6 +113,7 @@ struct k3_dma_dev {
> >       struct dma_pool         *pool;
> >       u32                     dma_channels;
> >       u32                     dma_requests;
> > +     u32                     dma_min_chan;
> >       unsigned int            irq;
> >  };
> >
> > @@ -309,7 +310,7 @@ static void k3_dma_tasklet(unsigned long arg)
> >
> >       /* check new channel request in d->chan_pending */
> >       spin_lock_irq(&d->lock);
> > -     for (pch = 0; pch < d->dma_channels; pch++) {
> > +     for (pch = d->dma_min_chan; pch < d->dma_channels; pch++) {
> >               p = &d->phy[pch];
> >
> >               if (p->vchan == NULL && !list_empty(&d->chan_pending)) {
> > @@ -326,7 +327,7 @@ static void k3_dma_tasklet(unsigned long arg)
> >       }
> >       spin_unlock_irq(&d->lock);
> >
> > -     for (pch = 0; pch < d->dma_channels; pch++) {
> > +     for (pch = d->dma_min_chan; pch < d->dma_channels; pch++) {
> >               if (pch_alloc & (1 << pch)) {
> >                       p = &d->phy[pch];
> >                       c = p->vchan;
> > @@ -825,6 +826,8 @@ static int k3_dma_probe(struct platform_device *op)
> >                               "dma-channels", &d->dma_channels);
> >               of_property_read_u32((&op->dev)->of_node,
> >                               "dma-requests", &d->dma_requests);
> > +             of_property_read_u32((&op->dev)->of_node,
> > +                             "dma-min-chan", &d->dma_min_chan);
> >       }
> >
> >       d->clk = devm_clk_get(&op->dev, NULL);
> > @@ -848,12 +851,12 @@ static int k3_dma_probe(struct platform_device *op)
> >               return -ENOMEM;
> >
> >       /* init phy channel */
> > -     d->phy = devm_kcalloc(&op->dev,
> > -             d->dma_channels, sizeof(struct k3_dma_phy), GFP_KERNEL);
> > +     d->phy = devm_kcalloc(&op->dev, (d->dma_channels - d->dma_min_chan),
> > +                     sizeof(struct k3_dma_phy), GFP_KERNEL);
> >       if (d->phy == NULL)
> >               return -ENOMEM;
> >
> > -     for (i = 0; i < d->dma_channels; i++) {
> > +     for (i = d->dma_min_chan; i < d->dma_channels; i++) {
> >               struct k3_dma_phy *p = &d->phy[i];
> >
> >               p->idx = i;
> > --
> > 2.17.1
>
> --
> ~Vinod