Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1428026ybz; Sat, 18 Apr 2020 00:24:30 -0700 (PDT) X-Google-Smtp-Source: APiQypKXdXVFrQj8hFPrY6EE6mMr0abrz4CCxRJ2+oEzhtRqeTS+/SJFJQr7pzHh0Sj3+jZjdzGx X-Received: by 2002:a05:6402:2059:: with SMTP id bc25mr6395929edb.227.1587194669956; Sat, 18 Apr 2020 00:24:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587194669; cv=none; d=google.com; s=arc-20160816; b=Uaw11YtH9717Hk8z9JxgrKZWLuxgLXXmGkw4bGPDQs63UzMXvG4B7xBbNLsmzU6T0P b41VVqkuxP7Jh0umlHw2qmAIxWZyUvQi5Zzb/R1ymxcjCB3zdWmOkuaZB/HH+5EoJmC2 UnAlEQARDbXA2RKP8m9ZtRZ2EXxdMAPY+iStfZijJDnIJcm8t6q2gqsX5u7Ys5YO79VT ADEkSE8jLfNWuz9U632BUJcyF+0gODSn4xqw99P9shp725ITRf+pCR9wuFb4Mj/hf/H/ j8CObt0FJpmVxFvz3uKTKTOBAZCKmBpnd2ysLicoQXOyDz2sjQudyhiLBeuFQN/+6eoJ 79xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=jgUyMh4mzPo+BzCmuMItscc+7IwM2D7h+sUYhitG09Q=; b=LF+F9/3lz9LM30/KxR/fkPCTfLjwNXNrGXU5+BZDeoYO9BfLIyMkKDCfxEaOWZPOrw ZrT3xXnIO4c55Bx/6vf7hL7vhIbYZOHJMNxwzeqCPt/VtOA4FCJVsQkyK2Nr8P7KFEtP R9+5r+jZBIQkUnmECGglZC+hBun3NvXEQQ3wSNvNVS1mnNU5Gl9Su3CGAZ9krI7izlZZ bAqffkZ6eHCjQQ2gp3p/FiEK6qIumiv2Q8DvZtjaKwbzOt4LVrjB8I1S6fPXoRxYVaqT F+bp8M4FgSPI8QAdE4FdFg0Sw0tiGWKIXASiKrncx/zklN2lMm5CMvkWsSO+uSHsuApx PH8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k23si10527211ejd.105.2020.04.18.00.24.07; Sat, 18 Apr 2020 00:24:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725884AbgDRHWU (ORCPT + 99 others); Sat, 18 Apr 2020 03:22:20 -0400 Received: from cmccmta2.chinamobile.com ([221.176.66.80]:3510 "EHLO cmccmta2.chinamobile.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725849AbgDRHWT (ORCPT ); Sat, 18 Apr 2020 03:22:19 -0400 Received: from spf.mail.chinamobile.com (unknown[172.16.121.15]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee55e9aaa940fd-ab33e; Sat, 18 Apr 2020 15:21:57 +0800 (CST) X-RM-TRANSID: 2ee55e9aaa940fd-ab33e X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from [192.168.0.105] (unknown[112.1.172.61]) by rmsmtp-syy-appsvr08-12008 (RichMail) with SMTP id 2ee85e9aaa9429f-6fef4; Sat, 18 Apr 2020 15:21:57 +0800 (CST) X-RM-TRANSID: 2ee85e9aaa9429f-6fef4 Subject: Re: [PATCH 3/3] ipmi:bt-bmc: Fix error handling and status check To: minyard@acm.org Cc: arnd@arndb.de, gregkh@linuxfoundation.org, openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <20200414141423.4968-1-tangbin@cmss.chinamobile.com> <20200414201832.GJ3587@minyard.net> <20200418021441.GC6246@minyard.net> From: Tang Bin Message-ID: Date: Sat, 18 Apr 2020 15:23:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200418021441.GC6246@minyard.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Corey: On 2020/4/18 10:14, Corey Minyard wrote: > Sorry for the delay, I have had a lot of distractions. No no no,  it's greatly appreciated  for your instruction. Thanks. > > The trouble is that the handling of bt_bmc->irq needs to be consistent. > Either it needs to be negative if the irq allocation fails, or it needs > to be zero if the irq allocation fails. I think it needs to be negative > because zero is a valid interrupt in some cases. > > Consider the following code: > > bt_bmc_config_irq(bt_bmc, pdev); > > if (bt_bmc->irq) { > dev_info(dev, "Using IRQ %d\n", bt_bmc->irq); > } else { > dev_info(dev, "No IRQ; using timer\n"); > timer_setup(&bt_bmc->poll_timer, poll_timer, 0); > > If bt_bmc->irq is negative (if platform_get_irq_optional() fails), it > will say it's using the irq and won't start a timer and the driver won't > work. Then later (in your change below) it will try to stop the timer > even though it's not running. > > If devm_request_irq() fails, then the interrupt is not set, but since > bt_bmc->irq is most likely not zero, it will not start the timer and the > driver won't work. > > You really need to set bt_bmc->irq negative if it fails. And fix the > check above to be if (bt_bmc->irq >= 0). Got it. You are right, I am lacking in consideration here. Thank you very much, I will send the v2. Tang Bin > > >