Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org CB0FC60A44
Subject: Re: [PATCH] remoteproc: silence an uninitialized variable warning
To:     Dan Carpenter <dan.carpenter@oracle.com>
Cc:     Andy Gross <andy.gross@linaro.org>,
        David Brown <david.brown@linaro.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        kernel-janitors@vger.kernel.org
References: <20190404084204.GA20193@kadam>
 <a08db945-44d3-ff99-7a89-75367f314855@codeaurora.org>
 <20190404093622.GM32613@kadam>
From:   Mukesh Ojha <mojha@codeaurora.org>
Message-ID: <f570c0c0-1493-88d7-474c-ad7437e6a1d0@codeaurora.org>
Date:   Fri, 5 Apr 2019 12:38:19 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190404093622.GM32613@kadam>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 4/4/2019 3:06 PM, Dan Carpenter wrote:
> On Thu, Apr 04, 2019 at 02:47:39PM +0530, Mukesh Ojha wrote:
>> On 4/4/2019 2:12 PM, Dan Carpenter wrote:
>>> Smatch complains that "ret" might be uninitialized.  I can see why it
>>> generates the warning, but I don't know if it's actually possible.
>>> Anyway initializing "ret" here is harmless.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> ---
>>>    drivers/soc/qcom/mdt_loader.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
>>> index 1c488024c698..fc58d660692f 100644
>>> --- a/drivers/soc/qcom/mdt_loader.c
>>> +++ b/drivers/soc/qcom/mdt_loader.c
>>> @@ -188,7 +188,7 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
>>>    	if (reloc_base)
>>>    		*reloc_base = mem_reloc;
>>> -
>>> +	ret = 0;
>>
>> You are overriding the value here, better keep it at the start.
> I like how I wrote it.  It makes it clear that this is the success path.


But think about a case when this request_firmware_into_buf fails or the 
snippet above that can set the ret with error value

right.. is not that possible?..and ret = 0 stops propagating the error 
properly.

Thanks
Mukesh

>
> regards,
> dan carpenter
>