From: Geert Uytterhoeven <geert@linux-m68k.org> To: Zong Li <zong.li@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com>, Rob Herring <robh+dt@kernel.org>, Paul Walmsley <paul.walmsley@sifive.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@vger.kernel.org List" <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org> Subject: Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree Date: Fri, 21 Jan 2022 09:33:19 +0100 [thread overview] Message-ID: <CAMuHMdVh_cXpbUeOmr_1K0dOJwGHSO0Ao=W43j5mpgvOiNyV9w@mail.gmail.com> (raw) In-Reply-To: <CANXhq0ruGxjO0WPUipzZ7QQM1oEapyHAvb_aVQ_CMqVxbjc_BQ@mail.gmail.com> Hi Zong, Palmer, On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), 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. > > > > Some of the same wording issues here as those I pointed out in the DT > > bindings patch. > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > --- 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. 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
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org> To: Zong Li <zong.li@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com>, Rob Herring <robh+dt@kernel.org>, Paul Walmsley <paul.walmsley@sifive.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@vger.kernel.org List" <linux-kernel@vger.kernel.org>, linux-riscv <linux-riscv@lists.infradead.org> Subject: Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree Date: Fri, 21 Jan 2022 09:33:19 +0100 [thread overview] Message-ID: <CAMuHMdVh_cXpbUeOmr_1K0dOJwGHSO0Ao=W43j5mpgvOiNyV9w@mail.gmail.com> (raw) In-Reply-To: <CANXhq0ruGxjO0WPUipzZ7QQM1oEapyHAvb_aVQ_CMqVxbjc_BQ@mail.gmail.com> Hi Zong, Palmer, On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), 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. > > > > Some of the same wording issues here as those I pointed out in the DT > > bindings patch. > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > --- 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. 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-01-21 8:33 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-17 1:35 [PATCH v4 0/3] Determine the number of DMA channels by 'dma-channels' property Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-17 1:35 ` [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-18 15:04 ` Conor.Dooley 2022-01-18 15:04 ` Conor.Dooley 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-27 7:03 ` Vinod Koul 2022-01-27 7:03 ` Vinod Koul 2022-01-27 7:35 ` Zong Li 2022-01-27 7:35 ` Zong Li 2022-01-17 1:35 ` [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-21 1:57 ` Zong Li 2022-01-21 1:57 ` Zong Li 2022-01-17 1:35 ` [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-21 2:21 ` Zong Li 2022-01-21 2:21 ` Zong Li 2022-01-21 8:33 ` Geert Uytterhoeven [this message] 2022-01-21 8:33 ` Geert Uytterhoeven 2022-01-21 10:29 ` Zong Li 2022-01-21 10:29 ` Zong Li 2022-01-25 5:08 ` Zong Li 2022-01-25 5:08 ` 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='CAMuHMdVh_cXpbUeOmr_1K0dOJwGHSO0Ao=W43j5mpgvOiNyV9w@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.