linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCHSET libata-dev#upstream] libata: prefer hardreset, take #2
@ 2008-03-11  3:41 Tejun Heo
  2008-03-11  3:41 ` [PATCH 1/5] libata: prefer hardreset Tejun Heo
                   ` (4 more replies)
  0 siblings, 5 replies; 8+ messages in thread
From: Tejun Heo @ 2008-03-11  3:41 UTC (permalink / raw)
  To: jeff, linux-ide; +Cc: mikpe


Hello,

This is the second take of prefer-hardreset patchset.

Changes from the last take [L] are...

* Updated to the current upstream.

* Audited against code before new EH was introduced (2.6.17) to
  prevent using hardreset on controllers which don't like it.

  - Hardresets on some versions of sata_nv fail to classify devices.
    This is alrady worked around by deferring classification to SRST.
    No further workaround necessary.

  - Hardreset on sata_via vt6420 was flaky.  sata_via already has only
    SRST.  No further workaround necessary.

  - sata_sx4 doesn't have SCRs.  No further workaround necessary.

  - sata_qstor.  SRST is broken.  Already has workaround implemented.
    No further workaround necessary.

  - All variants of sata_promise preferred SRST over COMRESET.  Can't
    find out explanation why.  Unless there's known problem, I'd like
    to convert it to prefer COMRESET if Mikael acks it.

  So, sans sata_promise, things don't change too much compared against
  2.6.17.

Preferring softreset over hardreset seemed okay at the beginning but
libata has been and continue accumulating more and more quirks to
promote reset to COMRESET to avoid SRST failure.

For example, any host which supports PMP should use COMRESET because
some PMPs don't reset properly only with SRST.  Another interesting
example is PMP fan-out ports.  Depending on how the spec is read, the
fan-out ports arguably requires hardreset to begin operation.

Also, SRST doesn't reset certain aspects of device configuration and
can result in inconsistent configurations which may lead to
revalidation failure after a PHY event or resume.

I can't find any merit of preferring SRST other than the warm fuzzy
feeling of the word 'soft' in front of it, especially when preferring
SRST means libata has to carray a bunch of quirks to avoid SRST for
cases it might not work.

For more rationales, please read patch description of the first patch.

This patchset contains five patches.  The first one makes libata
prefer COMRESET and the rest four kills quirks and simplifes related
codes.

This patchset is against the current upstream (bc5468f5).

 drivers/ata/ahci.c        |   16 ++----
 drivers/ata/libata-core.c |   28 ++---------
 drivers/ata/libata-eh.c   |  114 ++++++++++++++++------------------------------
 drivers/ata/libata-pmp.c  |   57 ++++++-----------------
 drivers/ata/libata-scsi.c |    7 +-
 drivers/ata/sata_fsl.c    |    4 -
 drivers/ata/sata_mv.c     |   29 ++---------
 drivers/ata/sata_nv.c     |   17 ++----
 drivers/ata/sata_sil.c    |    5 --
 drivers/ata/sata_sil24.c  |   58 ++++++++++-------------
 drivers/ata/sata_via.c    |    2
 include/linux/libata.h    |   24 ++-------
 12 files changed, 120 insertions(+), 241 deletions(-)

--
tejun

[L] http://thread.gmane.org/gmane.linux.ide/27447

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCHSET #upstream-fixes] block/libata: update and use block layer padding and draining, take 3
@ 2008-03-11  4:27 Tejun Heo
  2008-03-11  4:27 ` [PATCH 5/5] libata: kill ata_ehi_schedule_probe() Tejun Heo
  0 siblings, 1 reply; 8+ messages in thread
From: Tejun Heo @ 2008-03-11  4:27 UTC (permalink / raw)
  To: jeff, linux-ide; +Cc: mikpe


Hello,

After posting the previous patchset, I realized #upstream is proper
subset of #upstream-fixes, so here's the updated version against
#upstream-fixes.  It still needs Mikael's ack regarding behavior
change on sata_promise.

Changes from the last take[L] are...

* Updated against the current #upstream-fixes.

This patchset is against the current #upstream-fixes (3db691da).

 drivers/ata/ahci.c        |   17 ++----
 drivers/ata/libata-core.c |   28 ++---------
 drivers/ata/libata-eh.c   |  114 ++++++++++++++++------------------------------
 drivers/ata/libata-pmp.c  |   57 ++++++-----------------
 drivers/ata/libata-scsi.c |    7 +-
 drivers/ata/sata_fsl.c    |    4 -
 drivers/ata/sata_mv.c     |   31 +++---------
 drivers/ata/sata_nv.c     |   17 ++----
 drivers/ata/sata_sil.c    |    5 --
 drivers/ata/sata_sil24.c  |   58 ++++++++++-------------
 drivers/ata/sata_via.c    |    2
 include/linux/libata.h    |   24 ++-------
 12 files changed, 121 insertions(+), 243 deletions(-)

[L] http://thread.gmane.org/gmane.linux.ide/29637

--
tejun

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCHSET libata-dev#upstream] libata: prefer hardreset
@ 2008-01-23 15:21 Tejun Heo
  2008-01-23 15:21 ` [PATCH 5/5] libata: kill ata_ehi_schedule_probe() Tejun Heo
  0 siblings, 1 reply; 8+ messages in thread
From: Tejun Heo @ 2008-01-23 15:21 UTC (permalink / raw)
  To: jeff, linux-ide

Hello, all.

This is the first take of prefer-hardreset patchset.  I've been
meaning to do this for quite some time now.  Preferring softreset over
hardreset seemed okay at the beginning but libata has been and
continue accumulating more and more quirks to promote reset to
COMRESET to avoid SRST failure.

For example, any host which supports PMP should use COMRESET because
some PMPs don't reset properly only with SRST.  Another interesting
example is PMP fan-out ports.  Depending on how the spec is read, the
fan-out ports arguably requires hardreset to begin operation.

Also, SRST doesn't reset certain aspects of device configuration and
can result in inconsistent configurations which may lead to
revalidation failure after a PHY event or resume.

I can't find any merit of preferring SRST other than the warm fuzzy
feeling of the word 'soft' in front of it, especially when preferring
SRST means libata has to carray a bunch of quirks to avoid SRST for
cases it might not work.

For more rationales, please read patch description of the first patch.

This patchset contains five patches.  The first one makes libata
prefer COMRESET and the rest four kills quirks and simplifes related
codes.

This patchset is against the current upstream (a984f58d).

 drivers/ata/ahci.c        |   16 ++----
 drivers/ata/libata-core.c |   28 ++---------
 drivers/ata/libata-eh.c   |  114 ++++++++++++++++------------------------------
 drivers/ata/libata-pmp.c  |   57 ++++++-----------------
 drivers/ata/libata-scsi.c |    7 +-
 drivers/ata/sata_fsl.c    |    4 -
 drivers/ata/sata_mv.c     |   29 ++---------
 drivers/ata/sata_nv.c     |   17 ++----
 drivers/ata/sata_sil.c    |    5 --
 drivers/ata/sata_sil24.c  |   58 ++++++++++-------------
 drivers/ata/sata_via.c    |    2 
 include/linux/libata.h    |   24 ++-------
 12 files changed, 120 insertions(+), 241 deletions(-)

Thanks.

--
tejun

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-03-11  4:27 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-11  3:41 [PATCHSET libata-dev#upstream] libata: prefer hardreset, take #2 Tejun Heo
2008-03-11  3:41 ` [PATCH 1/5] libata: prefer hardreset Tejun Heo
2008-03-11  3:41 ` [PATCH 2/5] libata: kill ATA_LFLAG_HRST_TO_RESUME Tejun Heo
2008-03-11  3:41 ` [PATCH 3/5] libata: kill ATA_EHI_RESUME_LINK Tejun Heo
2008-03-11  3:41 ` [PATCH 4/5] libata: kill ATA_LFLAG_SKIP_D2H_BSY Tejun Heo
2008-03-11  3:41 ` [PATCH 5/5] libata: kill ata_ehi_schedule_probe() Tejun Heo
  -- strict thread matches above, loose matches on Subject: below --
2008-03-11  4:27 [PATCHSET #upstream-fixes] block/libata: update and use block layer padding and draining, take 3 Tejun Heo
2008-03-11  4:27 ` [PATCH 5/5] libata: kill ata_ehi_schedule_probe() Tejun Heo
2008-01-23 15:21 [PATCHSET libata-dev#upstream] libata: prefer hardreset Tejun Heo
2008-01-23 15:21 ` [PATCH 5/5] libata: kill ata_ehi_schedule_probe() Tejun Heo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).