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;
Date:   Fri, 26 Jan 2018 17:31:30 +0000
From:   Al Viro <viro@ZenIV.linux.org.uk>
To:     Jia-Ju Bai <baijiaju1990@gmail.com>
Cc:     tim@cyberelk.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: paride: on26: Replace mdelay with msleep in
 on26_test_port
Message-ID: <20180126173130.GZ13338@ZenIV.linux.org.uk>
References: <1516981345-8202-1-git-send-email-baijiaju1990@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1516981345-8202-1-git-send-email-baijiaju1990@gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jan 26, 2018 at 11:42:25PM +0800, Jia-Ju Bai wrote:
> After checking all possible call chains to on26_test_port() here,
> my tool finds that this function is never called in atomic context,
> namely never in an interrupt handler or holding a spinlock.
> And on26_test_port() is only called by pi_probe_unit() that calls 
> wait_event() through pi_claim(),
> so it indicates that on26_test_port() can call functions that can sleep.
> Thus mdelay can be replaced with msleep to avoid busy wait.

Sigh...  Here's how I would've written it:

"
on26_test_port() is never called from atomic contexts.

It has no direct callers and it is reachable only via ->test_port.
->test_port has only one user:
drivers/block/paride/paride.c:322:              max = pi->proto->test_port(pi);
in pi_probe_unit().  That gets called only from pi_init(), called from
p{d,cd,f,t,g}_detect(), called from module_init stuff, all of the above
without entering atomic contexts along the way.

Despite never getting called from atomic contexts, on26_test_port() contains
mdelay(100), i.e. busy-loops for 0.1s; that's neither nice nor needed, since
msleep() would serve just as well.

Found by [reference to tool]"