| Message ID | 50EE9815.2080402@asianux.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thursday 10 January 2013 03:59 PM, Chen Gang wrote: > > 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)) > Why not ? Infact thats the right fix as mentioned in the review. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 10 January 2013 04:18 PM, Santosh Shilimkar wrote: > On Thursday 10 January 2013 03:59 PM, Chen Gang wrote: >> >> 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)) >> > Why not ? Infact thats the right fix as mentioned in the review. > >> 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013?01?10? 18:48, 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. :-)
? 2013?01?10? 18:51, 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. :-)
On Friday 11 January 2013 10:33 AM, Chen Gang wrote: > ? 2013?01?10? 18:48, 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013?01?11? 15:26, Santosh Shilimkar ??: > On Friday 11 January 2013 10:33 AM, Chen Gang wrote: >> ?? 2013??01??10?? 18:48, 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. > > > 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.
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index 4136b20..b382eef 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -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;
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 <gang.chen@asianux.com> --- arch/arm/plat-omap/dma.c | 3 +++ 1 file changed, 3 insertions(+)