On Fri, Jan 21, 2022 at 6:29 PM Zong Li <zong.li@xxxxxxxxxx> wrote:
>
> On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> >
> > Hi Zong, Palmer,
> >
> > On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@xxxxxxxxxx> wrote:
> > > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote:
> > > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@xxxxxxxxxx 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@xxxxxxxxxx>
> >
> > > > > --- 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.
> >
> > In theory we can...
> >
> > > 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.
> >
> > ... but that would mean that when a new variant appears that supports
> > more channels, no error is printed, and people might not notice
> > immediately that the higher channels are never used.
> >
>
> I guess people might need to follow the dt-bindings, so they couldn't
> specify the number of channels to the value which is more than
> maximum. But as you mentioned, if people don't notice that and specify
> it more than maximum, they wouldn't be aware that the higher channels
> are never used. It seems to me that we could keep returning the error
> there, or show a warning message and use PDMA_MAX_NR_CH in that
> situation, both looks good to me.
>
Hi all, thank you for the review, I'd like to prepare the next version
patch, if current implementation of this part is ok to you, I will
keep it in the next version. Please let me know if anything can be
improved. Thanks
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds
