Dubious IRQ masking in ide_config_drive_speed()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, I wrote:

Index: b/drivers/ide/ide-iops.c
===================================================================
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
[...]

What's interesting, ide_config_drive_speed() code looks sane in this respect:

   ... except one thing:

@@ -769,13 +768,12 @@ int ide_config_drive_speed(ide_drive_t *
     SELECT_DRIVE(drive);
     SELECT_MASK(drive, 0);

We've called disable_irq_nosync() before that, so it's not clear why we're calling the driver's maskproc() method with 0 -- which unmasks interrupt in the IDE chip.

     udelay(1);
-    if (IDE_CONTROL_REG)
-        hwif->OUTB(drive->ctl | 2, IDE_CONTROL_REG);
+    ide_set_irq(drive, 0);
     hwif->OUTB(speed, IDE_NSECTOR_REG);
     hwif->OUTB(SETFEATURES_XFER, IDE_FEATURE_REG);
     hwif->OUTBSYNC(drive, WIN_SETFEATURES, IDE_COMMAND_REG);
-    if ((IDE_CONTROL_REG) && (drive->quirk_list == 2))
-        hwif->OUTB(drive->ctl, IDE_CONTROL_REG);
+    if (drive->quirk_list == 2)
+        ide_set_irq(drive, 1);
     error = __ide_wait_stat(drive, drive->ready_stat,
                 BUSY_STAT|DRQ_STAT|ERR_STAT,

Another SELECT_MASK(drive, 0) call follows which just doesn't make any sense since the interrupt has been already unmasked by the first call.

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux