1. 11 May, 2009 3 commits
    • Bartlomiej Zolnierkiewicz's avatar
      pata_pdc202xx_old: fix UDMA33 handling · 6ad58b24
      Bartlomiej Zolnierkiewicz authored
      The original driver doesn't use 66 MHz clock for UDMA33.
      
      [ The alternative solution would be to adjust UDMA33 timings
        for 66 MHz clock but I think that it is safer to stick with
        old & tested behavior for now. ]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      6ad58b24
    • Martin Michlmayr's avatar
      sata_mv: use new sata phy register settings for new devices · 29b7e43c
      Martin Michlmayr authored
      Marvell's new SoC (65 nano) needs different settings for its SATA
      PHY registers.
      Tested-by: default avatarMartin Michlmayr <tbm@cyrius.com>
      Signed-off-by: default avatarSaeed Bishara <saeed@marvell.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      29b7e43c
    • Tejun Heo's avatar
      libata: fix attach error handling · 842faa6c
      Tejun Heo authored
      New device attach path in ata_eh_revalidate_and_attach() is divided
      into two separate loops because ATA requires IDENTIFY to be issued to
      slave first while the user expects to see device probe messages from
      the master device.  new_mask is used to track which devices are the
      new ones between the first loop and the second.
      
      This usually works well but if an error occurs during configuration
      stage, ata_dev_revalidate_and_attach() returns with error code and
      forgets new_mask.  On the retry run, dev->class is set and new_mask
      for the device is clear, so the device just gets revalidated and thus
      ends up skipping post-configuration procedure including scheduling of
      SCSI_HOTPLUG for the device.  When this occurs, ATA part of probing
      works fine but SCSI probing usually doesn't happen and makes the
      device unreachable.
      
      The behavior has been around for a very long time but it has been
      uncovered with the recent addition of 1_5_GBPS horkage which uses
      -EAGAIN return value from ata_dev_configure() to restart the probing
      sequence after forcing cable speed.
      
      This can be fixed by making sure dev->class is permanently set only
      after all configurations are successfully complete.  Fix it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarTim Connors <tconnors+linuxkml@astro.swin.edu.au>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      842faa6c
  2. 10 May, 2009 12 commits
  3. 09 May, 2009 25 commits