return type of wait_for_completion_timeout is unsigned long not int. The
return variable is renamed to reflect its use and the type adjusted to
unsigned long.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
Patch was only compile tested with x86_64_defconfig (implies CONFIG_ATA=y)
Patch is against 3.19.0-rc7 (localversion-next is -next-20150209)
drivers/ata/libata-core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4c35f08..bddf8b6 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1563,7 +1563,7 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
DECLARE_COMPLETION_ONSTACK(wait);
unsigned long flags;
unsigned int err_mask;
- int rc;
+ unsigned long irq_timeout;
spin_lock_irqsave(ap->lock, flags);
@@ -1644,14 +1644,15 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
if (ap->ops->error_handler)
ata_eh_release(ap);
- rc = wait_for_completion_timeout(&wait, msecs_to_jiffies(timeout));
+ irq_timeout = wait_for_completion_timeout(&wait,
+ msecs_to_jiffies(timeout));
if (ap->ops->error_handler)
ata_eh_acquire(ap);
ata_sff_flush_pio_task(ap);
- if (!rc) {
+ if (irq_timeout == 0) {
spin_lock_irqsave(ap->lock, flags);
/* We're racing with irq here. If we lose, the
--
1.7.10.4
On Tue, Feb 10, 2015 at 03:39:36AM -0500, Nicholas Mc Guire wrote:
> - if (!rc) {
> + if (irq_timeout == 0) {
Why == 0 tho? This always bothers me. To match this style, we'd use
!= 0 to test the other direction. In what way is "if (ret != 0)"
better than "if (ret)"? We're negating the two tests needlessly.
Thanks.
--
tejun
On Tue, 10 Feb 2015, Tejun Heo wrote:
> On Tue, Feb 10, 2015 at 03:39:36AM -0500, Nicholas Mc Guire wrote:
> > - if (!rc) {
> > + if (irq_timeout == 0) {
>
> Why == 0 tho? This always bothers me. To match this style, we'd use
> != 0 to test the other direction. In what way is "if (ret != 0)"
> better than "if (ret)"? We're negating the two tests needlessly.
>
The == 0 seemed better to me than ! here because it would read
if (not irq_timeout) {
while it actually did time out - but this could be resolved by renaming
irq_timeout to time_left (as was suggested by Sergei Shtylyov
<[email protected]> for a similar patch) and then it
would read:
if (time_left == 0) {
which would nicely describe the timeout state.
if that addresses your concerns then I'll fix it up and repost.
thx!
hofrat
On Tue, Feb 10, 2015 at 04:55:17PM +0100, Nicholas Mc Guire wrote:
> On Tue, 10 Feb 2015, Tejun Heo wrote:
>
> > On Tue, Feb 10, 2015 at 03:39:36AM -0500, Nicholas Mc Guire wrote:
> > > - if (!rc) {
> > > + if (irq_timeout == 0) {
> >
> > Why == 0 tho? This always bothers me. To match this style, we'd use
> > != 0 to test the other direction. In what way is "if (ret != 0)"
> > better than "if (ret)"? We're negating the two tests needlessly.
> >
> The == 0 seemed better to me than ! here because it would read
>
> if (not irq_timeout) {
>
> while it actually did time out - but this could be resolved by renaming
> irq_timeout to time_left (as was suggested by Sergei Shtylyov
> <[email protected]> for a similar patch) and then it
> would read:
>
> if (time_left == 0) {
>
> which would nicely describe the timeout state.
>
> if that addresses your concerns then I'll fix it up and repost.
Plesae just do !
Thanks.
--
tejun
On 02/10/2015 06:55 PM, Nicholas Mc Guire wrote:
>> On Tue, Feb 10, 2015 at 03:39:36AM -0500, Nicholas Mc Guire wrote:
>>> - if (!rc) {
>>> + if (irq_timeout == 0) {
>> Why == 0 tho? This always bothers me. To match this style, we'd use
>> != 0 to test the other direction. In what way is "if (ret != 0)"
>> better than "if (ret)"? We're negating the two tests needlessly.
> The == 0 seemed better to me than ! here because it would read
> if (not irq_timeout) {
No, 'irq_timeout == 0' isn't really better.
> while it actually did time out - but this could be resolved by renaming
> irq_timeout to time_left (as was suggested by Sergei Shtylyov
> <[email protected]> for a similar patch) and then it
> would read:
> if (time_left == 0) {
> which would nicely describe the timeout state.
'!time_left' also would.
> if that addresses your concerns then I'll fix it up and repost.
> thx!
> hofrat
MBR, Sergei