PIO4 is a maximum PIO mode supported by a driver.  Using "255" as a max_mode
argument to ide_get_best_pio_mode() could result in wrong timings being used
by a driver (for "pio" equal to 5) or OOPS (for "pio" values > 5 && < 255).

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Reviewed-by: Alan Cox <alan@lxorguk.ukuu.org.uk>

The SiS966 has one additional PCI-ID 1180.

If the chipset is using this PCI-ID, the primary channel is connected to the
first PATA-port. The secondary channel is connected to SATA-ports in IDE
emulation mode.  The legacy IO-ports are used.

The including of the PCI-ID into pata_sis is not sufficient, because the legacy
driver in drivers/ide is initialized before pata_sis.

Signed-off-by: Uwe Koziolek <uwe.koziolek@gmx.net>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

drivers/ide/setup-pci.c: In function 'ide_scan_pcibus':
drivers/ide/setup-pci.c:879: warning: ignoring return value of '__pci_register_driver', declared with attribute warn_unused_result

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Recently the PLL input clock of Promise 2027x is sometimes detected
higher than expected (e.g. 20.027 MHz compared to 16.714 MHz).
It seems sometimes the mdelay() function is not as precise as it
used to be. Per Alan's advice, HT or power management might affect
the precision of mdelay().

This patch calls gettimeofday() to measure the time elapsed and
calculate the PLL input clock accordingly.

Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bahadir Balban <bahadir.balban@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

SWDMA modes are unsupported by it821x.  Attempts to tune SWDMA modes always
fail (due to sanity check in ->speedproc) and result in PIO being tuned.

* Fix incorrect SWDMA mask so core code won't try these modes and will just
  tune PIO if no other DMA modes are available.

* Bump driver version.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

* Driver can't skip programming transfer mode on the device in amd_set_drive()
  (similar fix has been applied to via82cxxx driver ages ago).

* While at it remove redundant warning (ide_config_drive_speed() already
  produces more valuable one).

* Bump driver version.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

The HPT36x chips finally turned out to have the channel enable bits -- however,
badly implemented.  Make use of them despite it's probably only going to burden
the driver's code -- assuming both channels are always enabled by the HighPoint
BIOS anyway...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Linas Vepstas <linas@austin.ibm.com>
Cc: michal.kepien@poczta.onet.pl
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Add the MAXTOR STM3320620A drive into the UltraDMA/66 mode blacklist
for the HPT36x chips.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Found by a static analyser. It is in theory possible we dereference
dev->id when it has become invalid. Re-order to avoid this.

Not needed for new-ide as we no longer support the crazy exabyte nest stuff

Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Look at wait_drive_not_busy in drivers/ide/ide-taskfile.c:

    static u8 wait_drive_not_busy(ide_drive_t *drive)
    {
            ide_hwif_t *hwif = HWIF(drive);
            int retries = 100;
            u8 stat;

            /*
             * Last sector was transfered, wait until drive is ready.
             * This can take up to 10 usec, but we will wait max 1 ms
             * (drive_cmd_intr() waits that long).
             */
            while (((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) && retries--)
                    udelay(10);

            if (!retries)
                    printk(KERN_ERR "%s: drive still BUSY!\n", drive->name);

            return stat;
    }

`printk' is never called because `retries' never holds zero at the
outside of `while' loop: when `retries' holds zero at the while's loop
condition, `retries' will hold -1 at the if condition.

Signed-off-by: Masatake YAMATO <jet@gyve.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Cc: joe@perches.com
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>