From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [PATCH] arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels Date: Thu, 10 Jan 2013 16:21:33 +0530 Message-ID: <50EE9D35.6060300@ti.com> References: <50EE9815.2080402@asianux.com> <50EE9C87.6060407@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from bear.ext.ti.com ([192.94.94.41]:37753 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753336Ab3AJKun (ORCPT ); Thu, 10 Jan 2013 05:50:43 -0500 In-Reply-To: <50EE9C87.6060407@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Chen Gang Cc: tony@atomide.com, linux@arm.linux.org.uk, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Santosh Shilimkar) Date: Thu, 10 Jan 2013 16:21:33 +0530 Subject: [PATCH] arch/arm/plat-omap: initializing dma_lch_count, before judging omap_dma_reserve_channels In-Reply-To: <50EE9C87.6060407@ti.com> References: <50EE9815.2080402@asianux.com> <50EE9C87.6060407@ti.com> Message-ID: <50EE9D35.6060300@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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