From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Zong Li <zong.li@sifive.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
Conor Dooley <conor.dooley@microchip.com>,
Bin Meng <bin.meng@windriver.com>,
Green Wan <green.wan@sifive.com>, Vinod <vkoul@kernel.org>,
dmaengine <dmaengine@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] dmaengine: sf-pdma: Get number of channel by device tree
Date: Thu, 13 Jan 2022 09:57:40 +0100 [thread overview]
Message-ID: <CAMuHMdXUa8VCyocHzXGrQevEHiMVs_-p+qGpw_5ZFdOT66pv=Q@mail.gmail.com> (raw)
In-Reply-To: <CANXhq0rKsAsm4oSvnVqy385shoY2uTQOGUSqYdf-D=2xJ5vgWg@mail.gmail.com>
Hi Zong,
On Thu, Jan 13, 2022 at 8:26 AM Zong Li <zong.li@sifive.com> wrote:
> On Thu, Jan 13, 2022 at 2:53 PM Zong Li <zong.li@sifive.com> wrote:
> > On Wed, Jan 12, 2022 at 4:28 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, Jan 11, 2022 at 9:51 AM Zong Li <zong.li@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.
> > > >
> > > > Signed-off-by: Zong Li <zong.li@sifive.com>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/drivers/dma/sf-pdma/sf-pdma.c
> > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c
> > > > @@ -484,21 +484,24 @@ 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;
> > > > + int len, ret;
> > > > const enum dma_slave_buswidth widths =
> > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES |
> > > > DMA_SLAVE_BUSWIDTH_4_BYTES | DMA_SLAVE_BUSWIDTH_8_BYTES |
> > > > 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;
> > > > + len = sizeof(*pdma) + sizeof(*chan) * PDMA_MAX_NR_CH;
> > >
> > > Why is the last part added (yes, this is a pre-existing issue)?
> > > struct sf_pdma already contains space for chans[PDMA_MAX_NR_CH].
> > > Either drop the last part, or change sf_pdma.chans[] to a flexible
> > > array member.
> > >
> > > BTW, you can use the struct_size() or flex_array_size() helper
> > > to calculate len.
> >
> > Thanks for your suggestions, let me fix it in the next version.
> >
> > >
> > > > pdma = devm_kzalloc(&pdev->dev, len, 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;
> > > > + }
> > > >
> > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > pdma->membase = devm_ioremap_resource(&pdev->dev, res);
> > > > @@ -556,7 +559,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];
> > >
> > > If dma-channels in DT > PDMA_NR_CH, this becomes an out-of-bound
> > > access.
> > >
> >
> > Okay, let me get the min() between pdma->chans and PDMA_MAX_NR_CH,
> > please let me know if it isn't good to you.
>
> Please allow me give more details on it, I would compare the value of
> pdma->chans with PDMA_MAX_NR_CH in probe function, and set the
> pdma->chans to PDMA_MAX_NR_CH if the value in DT is bigger than
> PDMA_MAX_NR_CH.
Silently limiting "dma-channels" to PDMA_MAX_NR_CH is not a good idea,
as that may lead to hard-to-track problems.
Basically you have two options:
1. Just use the value of "dma-channels" if present.
This has the advantage that it will work automatically with
future variants that have more channels, but allows the
developer to trigger memory exhaustion by providing a very large value.
2. Return -EINVAL if "dma-channels" is larger than PDMA_MAX_NR_CH.
This is the safest, but requires driver changes for a future variant
that has more channels.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
next prev parent reply other threads:[~2022-01-13 8:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-11 8:51 [PATCH v2 0/3] Determine the number of DMA channels by 'dma-channels' property Zong Li
2022-01-11 8:51 ` [PATCH v2 1/3] riscv: dts: Add dma-channels property in dma node Zong Li
2022-01-11 8:51 ` [PATCH v2 2/3] dt-bindings: Add dma-channels for pdma device node Zong Li
2022-01-11 8:51 ` [PATCH v2 3/3] dmaengine: sf-pdma: Get number of channel by device tree Zong Li
2022-01-12 8:28 ` Geert Uytterhoeven
2022-01-13 6:53 ` Zong Li
2022-01-13 7:25 ` Zong Li
2022-01-13 8:57 ` Geert Uytterhoeven [this message]
2022-01-13 9:34 ` Zong Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdXUa8VCyocHzXGrQevEHiMVs_-p+qGpw_5ZFdOT66pv=Q@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=aou@eecs.berkeley.edu \
--cc=bin.meng@windriver.com \
--cc=conor.dooley@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=green.wan@sifive.com \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=vkoul@kernel.org \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).