arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

PATCH New Chen Gang 3 participants 10 messages Jan 10, 2013 – Feb 1, 2013

Subsystems (2)

Arm (32-bit) Arm sub-architectures

lore

Share & tools

lore

Chen Gang

author

2013-01-10 10:28 UTC #0 lore raw

PATCH 1/1 arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

dma_lch_count is zero before 1st call of omap_system_dma_probe. omap_dma_reserve_channels has value before 1st call of omap_system_dma_probe

when 1st call of omap_system_dma_probe
we need set dma_lch_count before use it for judging or which will be failed for omap_dma_reserve_channels

additional info:
this patch is only for fixing bug, not touch the features. so, not use d->lch_count instead of dma_lch_count for the statement:

&& (omap_dma_reserve_channels <= dma_lch_count))

at least, now, current fixing is equal to above.
in the future
maybe omap_dma_reserve_channels can be set by outside (such as from /proc) dma_lch_count is a static global variable which has effect to all devices. maybe the original author do not hope the newer is larger than the older

Signed-off-by Chen Gang <[email protected]>

---
 arch/arm/plat-omap/dma.c |    3 +++
 1 file changed, 3 insertions(+)

arch/arm/plat-omap/dma.c +3 -0

index 4136b20..b382eef 100644
@@ -2018,6 +2018,9 @@ static int omap_system_dma_probe(struct platform_device *pdev)
 	d			= p->dma_attr;
 	errata			= p->errata;
 
+	if (!dma_lch_count)
+		dma_lch_count	= d->lch_count;
+
 	if ((d->dev_caps & RESERVE_CHANNEL) && omap_dma_reserve_channels
 			&& (omap_dma_reserve_channels <= dma_lch_count))
 		d->lch_count	= omap_dma_reserve_channels;

Signature · 1 line

1.7.10.4

Santosh Shilimkar

2013-01-10 10:47 UTC #1 lore raw

PATCH 1/1 arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

Quoted 8 lines · Chen Gang

dma_lch_count is zero before 1st call of omap_system_dma_probe. omap_dma_reserve_channels has value before 1st call of omap_system_dma_probe
when 1st call of omap_system_dma_probe
we need set dma_lch_count before use it for judging or which will be failed for omap_dma_reserve_channels

Quoted 6 lines

additional info:

     this patch is only for fixing bug, not touch the features.
     so, not use d->lch_count instead of dma_lch_count for the statement:

                         && (omap_dma_reserve_channels <= dma_lch_count))

Why not ? Infact thats the right fix as mentioned in the review.

Quoted 6 lines

at least, now, current fixing is equal to above.
in the future
maybe omap_dma_reserve_channels can be set by outside (such as from /proc) dma_lch_count is a static global variable which has effect to all devices. maybe the original author do not hope the newer is larger than the older

'omap_dma_reserve_channels' when used is suppose to be from command line. Hence the proposed fix in the review is the right one.

Regards
santosh

Santosh Shilimkar

2013-01-10 10:50 UTC #2 lore raw

PATCH 1/1 arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

Quoted 27 lines · Santosh Shilimkar

Quoted 9 lines · Chen Gang
dma_lch_count is zero before 1st call of omap_system_dma_probe. omap_dma_reserve_channels has value before 1st call of
omap_system_dma_probe
when 1st call of omap_system_dma_probe
we need set dma_lch_count before use it for judging or which will be failed for omap_dma_reserve_channels
Quoted 6 lines
additional info:
     this patch is only for fixing bug, not touch the features.
     so, not use d->lch_count instead of dma_lch_count for the statement:

                         && (omap_dma_reserve_channels <= dma_lch_count))
Why not ? Infact thats the right fix as mentioned in the review.
Quoted 9 lines
at least, now, current fixing is equal to above.
in the future
maybe omap_dma_reserve_channels can be set by outside (such as
from /proc)
dma_lch_count is a static global variable which has effect to
all devices.
maybe the original author do not hope the newer is larger than
the older

Quoted 3 lines

'omap_dma_reserve_channels' when used is suppose to be from command line. Hence the proposed fix in the review is the right one.

Another thing. please fix the subject line. It should be something like below.

ARM: OMAP: Fix the use of uninitialized dma_lch_count

Regards
santosh

Chen Gang

author

2013-01-11 05:02 UTC #4 lore raw

PATCH 1/1 arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

In reply to Santosh Shilimkar

Quoted 2 lines · Santosh Shilimkar

'omap_dma_reserve_channels' when used is suppose to be from command line. Hence the proposed fix in the review is the right one.

ok, thank you for your suggestion.

I will send patch v2, also mark you as Signed-of-by.

:-)

Signature · 7 lines

Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Chen Gang

author

2013-01-11 05:08 UTC #3 lore raw

PATCH 1/1 arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

In reply to Santosh Shilimkar

Quoted 4 lines · Santosh Shilimkar

Another thing. please fix the subject line. It should be something like below.
ARM: OMAP: Fix the use of uninitialized dma_lch_count

ok, thank you for your suggestion

I will use it as subject for patch v2.

:-)

Signature · 7 lines

Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Chen Gang

author

2013-01-11 05:38 UTC #7 lore raw

PATCH 1/1 ARM: OMAP: Fix the use of uninitialized dma_lch_count

In reply to Santosh Shilimkar

'omap_dma_reserve_channels' when used is suppose to be from command.
so, it alreay has value before 1st call of omap_system_dma_probe. and it will never be changed again during running (not from ioctl).

but 'dma_lch_count' is zero before 1st call of omap_system_dma_probe.
so it will be failed for omap_dma_reserve_channels, when 1st call.

so, need use 'd->lch_count' instead of 'dma_lch_count' for judging.

Signed-off-by Chen Gang <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

---
 arch/arm/plat-omap/dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/plat-omap/dma.c +1 -1

index 4136b20..e06c34b 100644
@@ -2019,7 +2019,7 @@ static int omap_system_dma_probe(struct platform_device *pdev)
 	errata			= p->errata;
 
 	if ((d->dev_caps & RESERVE_CHANNEL) && omap_dma_reserve_channels
-			&& (omap_dma_reserve_channels <= dma_lch_count))
+			&& (omap_dma_reserve_channels < d->lch_count))
 		d->lch_count	= omap_dma_reserve_channels;
 
 	dma_lch_count		= d->lch_count;

Signature · 1 line

1.7.10.4

Santosh Shilimkar

2013-01-11 07:26 UTC #5 lore raw

PATCH 1/1 arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

In reply to Chen Gang

Quoted 8 lines · Chen Gang

Quoted 2 lines · Santosh Shilimkar
'omap_dma_reserve_channels' when used is suppose to be from command line. Hence the proposed fix in the review is the right one.
ok, thank you for your suggestion.
I will send patch v2, also mark you as Signed-of-by.

Acked-by is just fine.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Chen Gang

author

2013-01-11 11:23 UTC #6 lore raw

PATCH 1/1 arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels

Quoted 13 lines · Santosh Shilimkar

Quoted 8 lines · Chen Gang
�� 2013��01��10�� 18:48, Santosh Shilimkar д��:
Quoted 2 lines
'omap_dma_reserve_channels' when used is suppose to be from command line. Hence the proposed fix in the review is the right one.
ok, thank you for your suggestion.
I will send patch v2, also mark you as Signed-of-by.
Acked-by is just fine.

thanks, I have send patch v2 for it, since it is a new subject, so
still use [PATCH] instead of [PATCH v2].

the subject of the new patch (which has sent) is:
[PATCH] ARM: OMAP: Fix the use of uninitialized dma_lch_count

please check, thanks.

Signature · 7 lines

Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Santosh Shilimkar

2013-01-11 11:37 UTC #8 lore raw

PATCH 1/1 ARM: OMAP: Fix the use of uninitialized dma_lch_count

In reply to Chen Gang

Quoted 5 lines · Chen Gang

'omap_dma_reserve_channels' when used is suppose to be from command.
so, it alreay has value before 1st call of omap_system_dma_probe. and it will never be changed again during running (not from ioctl).

Quoted 8 lines

but 'dma_lch_count' is zero before 1st call of omap_system_dma_probe.
so it will be failed for omap_dma_reserve_channels, when 1st call.
so, need use 'd->lch_count' instead of 'dma_lch_count' for judging.
Signed-off-by Chen Gang <[email protected]>
Signed-off-by Santosh Shilimkar <[email protected]>
---

Looks fine to me.

Tony,
If you are ok with the patch, can you pick this fix in your non-critical fixes branch ?

Tony Lindgren

2013-02-01 22:40 UTC #9 lore raw

PATCH 1/1 ARM: OMAP: Fix the use of uninitialized dma_lch_count

Quoted 11 lines · Santosh Shilimkar

Quoted 10 lines · Chen Gang
'omap_dma_reserve_channels' when used is suppose to be from command.
so, it alreay has value before 1st call of omap_system_dma_probe. and it will never be changed again during running (not from ioctl).
but 'dma_lch_count' is zero before 1st call of omap_system_dma_probe.
so it will be failed for omap_dma_reserve_channels, when 1st call.
so, need use 'd->lch_count' instead of 'dma_lch_count' for judging.

Quoted 8 lines

Quoted 3 lines
Signed-off-by Chen Gang <[email protected]>
Signed-off-by Santosh Shilimkar <[email protected]>
---
Looks fine to me.
Tony,
If you are ok with the patch, can you pick this fix in your non-critical fixes branch ?

Yes applying thanks.

Tony