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 <[email protected]>
---
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;
+ }
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 */
--
2.31.1
On Sun, 16 Jan 2022 17:35:28 PST (-0800), [email protected] 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 <[email protected]>
> ---
> 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.
> + }
>
> 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 */
On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <[email protected]> wrote:
>
> On Sun, 16 Jan 2022 17:35:28 PST (-0800), [email protected] 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 <[email protected]>
> > ---
> > 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 */
Hi Zong, Palmer,
On Fri, Jan 21, 2022 at 3:21 AM Zong Li <[email protected]> wrote:
> On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <[email protected]> wrote:
> > On Sun, 16 Jan 2022 17:35:28 PST (-0800), [email protected] 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 <[email protected]>
> > > --- 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 -- [email protected]
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
On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Zong, Palmer,
>
> On Fri, Jan 21, 2022 at 3:21 AM Zong Li <[email protected]> wrote:
> > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <[email protected]> wrote:
> > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), [email protected] 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 <[email protected]>
>
> > > > --- 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.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> 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
On Fri, Jan 21, 2022 at 6:29 PM Zong Li <[email protected]> wrote:
>
> On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <[email protected]> wrote:
> >
> > Hi Zong, Palmer,
> >
> > On Fri, Jan 21, 2022 at 3:21 AM Zong Li <[email protected]> wrote:
> > > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <[email protected]> wrote:
> > > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), [email protected] 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 <[email protected]>
> >
> > > > > --- 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 -- [email protected]
> >
> > 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