[PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree
Zong Li
zong.li at sifive.com
Thu Jan 20 18:21:05 PST 2022
On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
> On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li at sifive.com wrote:
> > It currently assumes that there are always four channels, it would
> > cause the error if there is actually less than four channels. Change
> > that by getting number of channel from device tree.
> >
> > For backwards-compatible, it uses the default value (i.e. 4) when there
> > is no 'dma-channels' information in dts.
>
> Some of the same wording issues here as those I pointed out in the DT
> bindings patch.
>
> > Signed-off-by: Zong Li <zong.li at sifive.com>
> > ---
> > drivers/dma/sf-pdma/sf-pdma.c | 20 +++++++++++++-------
> > drivers/dma/sf-pdma/sf-pdma.h | 8 ++------
> > 2 files changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c
> > index f12606aeff87..1264add9897e 100644
> > --- a/drivers/dma/sf-pdma/sf-pdma.c
> > +++ b/drivers/dma/sf-pdma/sf-pdma.c
> > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma)
> > static int sf_pdma_probe(struct platform_device *pdev)
> > {
> > struct sf_pdma *pdma;
> > - struct sf_pdma_chan *chan;
> > struct resource *res;
> > - int len, chans;
> > int ret;
> > const enum dma_slave_buswidth widths =
> > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES |
> > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev)
> > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES |
> > DMA_SLAVE_BUSWIDTH_64_BYTES;
> >
> > - chans = PDMA_NR_CH;
> > - len = sizeof(*pdma) + sizeof(*chan) * chans;
> > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
> > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL);
> > if (!pdma)
> > return -ENOMEM;
> >
> > - pdma->n_chans = chans;
> > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels",
> > + &pdma->n_chans);
> > + if (ret) {
> > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n");
> > + pdma->n_chans = PDMA_MAX_NR_CH;
> > + }
> > +
> > + if (pdma->n_chans > PDMA_MAX_NR_CH) {
> > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n");
> > + return -EINVAL;
>
> Can we get away with just using only the number of channels the driver
> actually supports? ie, just never sending an op to the channels above
> MAX_NR_CH? That should leave us with nothing to track.
It might be a bit like when pdma->n_chans is bigger than the maximum,
set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we
don't access the channels above the maximum. If I understand
correctly, I gave the similar thought in the thread of v2 patch, and
there are some discussions on that, but this way seems to lead to
hard-to-track problems.
>
> > + }
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pdma->membase = devm_ioremap_resource(&pdev->dev, res);
> > @@ -556,7 +562,7 @@ static int sf_pdma_remove(struct platform_device *pdev)
> > struct sf_pdma_chan *ch;
> > int i;
> >
> > - for (i = 0; i < PDMA_NR_CH; i++) {
> > + for (i = 0; i < pdma->n_chans; i++) {
> > ch = &pdma->chans[i];
> >
> > devm_free_irq(&pdev->dev, ch->txirq, ch);
> > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h
> > index 0c20167b097d..8127d792f639 100644
> > --- a/drivers/dma/sf-pdma/sf-pdma.h
> > +++ b/drivers/dma/sf-pdma/sf-pdma.h
> > @@ -22,11 +22,7 @@
> > #include "../dmaengine.h"
> > #include "../virt-dma.h"
> >
> > -#define PDMA_NR_CH 4
> > -
> > -#if (PDMA_NR_CH != 4)
> > -#error "Please define PDMA_NR_CH to 4"
> > -#endif
> > +#define PDMA_MAX_NR_CH 4
> >
> > #define PDMA_BASE_ADDR 0x3000000
> > #define PDMA_CHAN_OFFSET 0x1000
> > @@ -118,7 +114,7 @@ struct sf_pdma {
> > void __iomem *membase;
> > void __iomem *mappedbase;
> > u32 n_chans;
> > - struct sf_pdma_chan chans[PDMA_NR_CH];
> > + struct sf_pdma_chan chans[PDMA_MAX_NR_CH];
> > };
> >
> > #endif /* _SF_PDMA_H */
More information about the linux-riscv
mailing list