[PATCH 00/86] PATA fixes

[PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

Hi,

I've been going through PATA drivers for the last few days to make
sure that we offer similar level of hardware support in the new PATA
drivers as with the old IDE subsystem and the following patchset is
the end result of said audit.


Inside:

- many bugfixes

  ( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x,
    pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis,
    pata_radisys, pata_rz1000 & pata_via )

- add Power Management support for more controllers

  ( pata_artop, pata_pdc2027x, pata_sl82c105 )

- add 32-bit PIO support for more controllers

  ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
    pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
    pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
    pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
    pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
    pata_sis, pata_triflex & pata_via )

- fix QDI65x0 support in pata_legacy driver so pata_qdi driver can
  be finally removed

- remove pata_qdi and pata_winbond drivers resulting in 600 LOC gone

  (affected hardware is fully supported by pata_legacy driver now)

- unify code for programming PIO and MWDMA timings for 'PIIX-like'
  controllers resulting in 200 LOC gone

  ( ata_piix, pata_efar, pata_it8213, pata_oldpiix, pata_radisys &
    pata_rdc )

- add ->init_host method for abstracting host specific controller
  initialization and then use it to cleanup Power Managment code
  resulting in over 100 LOC gone

  ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
    pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
    pata_ns87415, pata_pdc2027x & sata_sil )

- misc fixes and cleanups


The following changes since commit 5c0e519edce8aa5c517e3b3e9a1fdf6fa0f3cf83:
  Christoph Hellwig (1):
        libata: add translation for SCSI WRITE SAME (aka TRIM support)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-v1

Bartlomiej Zolnierkiewicz (86):
      ata_piix: fix MWDMA handling on PIIX3
      ata_piix: unify code for programming PIO and MWDMA timings
      pata_artop: add 32-bit PIO support
      pata_artop: fix chipsets naming
      pata_artop: add Power Management support
      pata_artop: unify ->prereset methods
      pata_artop: remove dead 34MHz PCI clock support
      pata_atiixp: add 32-bit PIO support
      pata_atiixp: no need to program PIO timings for MWDMA
      pata_atiixp: add MWDMA0 support
      pata_atiixp: remove custom BMDMA methods
      pata_atiixp: add proper ->prereset method
      pata_efar: add 32-bit PIO support
      pata_efar: fix wrong PIO timings being programmed
      pata_efar: fix wrong MWDMA timings being programmed
      pata_efar: MWDMA0 is unsupported
      pata_efar: fix register naming used in efar_set_piomode()
      pata_efar: unify code for programming PIO and MWDMA timings
      pata_cmd640: document known issues
      pata_cmd64x: add 32-bit PIO support
      pata_cmd64x: add enablebits checking
      pata_cmd64x: add cmd64x_fixup()
      pata_cs5520: add 32-bit PIO support
      pata_cs5520: remove dead VDMA support
      pata_cs5530: add 32-bit PIO support
      pata_cs5535: add 32-bit PIO support
      pata_cs5535: no need to program PIO0 timings during device init
      pata_cypress: add 32-bit PIO support
      pata_cypress: document known issues
      pata_hpt366: add 32-bit PIO support
      pata_hpt37x: add 32-bit PIO support
      pata_hpt3x2n: add 32-bit PIO support
      pata_hpt3x3: Power Management fix
      pata_it8213: add 32-bit PIO support
      pata_it8213: fix UDMA handling
      pata_it8213: add UDMA100 and UDMA133 support
      pata_it8213: fix wrong PIO timings being programmed
      pata_it8213: fix PIO2 underclocking
      pata_it8213: fix wrong MWDMA timings being programmed
      pata_it8213: fix register naming used in it8213_set_piomode()
      pata_efar: unify code for programming PIO and MWDMA timings
      pata_it8213: fix it8213_pre_reset() documentation
      pata_it821x: add 32-bit PIO support
      pata_jmicron: add 32-bit PIO support
      pata_legacy: do not probe extra ports automatically if PCI is not present
      pata_legacy: fix QDI6580DP support
      pata_legacy: fix access to control register for QDI6580
      pata_legacy: add pointers to QDI65x0 documentation
      pata_legacy: unify QDI ->set_piomode methods
      pata_legacy: use PIO mask defines
      libata: remove no longer needed pata_qdi driver
      libata: remove no longer needed pata_winbond driver
      pata_marvell: fix marvell_pre_reset() documentation
      pata_ns87415: add 32-bit PIO support
      pata_ns87415: Power Management fix
      pata_oldpiix: unify code for programming PIO and MWDMA timings
      pata_opti: add 32-bit PIO support
      pata_pdc2027x: add 32-bit PIO support
      pata_pdc2027x: add Power Management support
      pata_pdc202xx_old: add 32-bit PIO support
      pata_sis: Power Management fix
      pata_pdc202xx_old: document known issues
      pata_radisys: fix UDMA handling
      pata_radisys: unify code for programming PIO and MWDMA timings
      pata_rdc: unify code for programming PIO and MWDMA timings
      pata_rz1000: add 32-bit PIO support
      pata_rz1000: Power Management fix
      pata_sc1200: add 32-bit PIO support
      pata_scc: add 32-bit PIO support
      pata_scc: add proper cable detection method
      pata_sch: add 32-bit PIO support
      pata_serverworks: add 32-bit PIO support
      pata_serverworks: use standard cable detection methods
      pata_serverworks: add serverworks_fixup()
      pata_sl82c105: add 32-bit PIO support
      pata_sl82c105: add Power Management support
      pata_sis: add 32-bit PIO support
      pata_sis: Power Management fix
      pata_triflex: add 32-bit PIO support
      libata: make ata_sff_data_xfer_noirq() work with 32-bit PIO
      pata_via: add 32-bit PIO support
      pata_via: clear UDMA transfer mode bit for PIO and MWDMA
      pata_via: add via_fixup()
      libata: add ata_mwdma_to_pio() inline helper
      libata: add ->init_host method
      libata: add private driver field to struct ata_device

 drivers/ata/Kconfig             |   16 ++-
 drivers/ata/Makefile            |    2 -
 drivers/ata/ata_piix.c          |  113 ++++---------
 drivers/ata/libata-core.c       |   14 ++-
 drivers/ata/libata-sff.c        |   12 +-
 drivers/ata/pata_ali.c          |   29 +--
 drivers/ata/pata_amd.c          |   45 ++---
 drivers/ata/pata_artop.c        |  224 ++++++++++++-------------
 drivers/ata/pata_atiixp.c       |  112 ++++---------
 drivers/ata/pata_cmd640.c       |   27 +--
 drivers/ata/pata_cmd64x.c       |  100 +++++++-----
 drivers/ata/pata_cs5520.c       |   41 +----
 drivers/ata/pata_cs5530.c       |   33 +---
 drivers/ata/pata_cs5535.c       |   14 +--
 drivers/ata/pata_cypress.c      |    2 +-
 drivers/ata/pata_efar.c         |  121 +++++---------
 drivers/ata/pata_hpt366.c       |   32 ++---
 drivers/ata/pata_hpt37x.c       |    4 +-
 drivers/ata/pata_hpt3x2n.c      |    2 +-
 drivers/ata/pata_hpt3x3.c       |   23 ++--
 drivers/ata/pata_it8213.c       |  136 ++++++---------
 drivers/ata/pata_it821x.c       |   39 ++---
 drivers/ata/pata_jmicron.c      |    2 +-
 drivers/ata/pata_legacy.c       |  156 +++++++----------
 drivers/ata/pata_marvell.c      |    2 +-
 drivers/ata/pata_ninja32.c      |   30 ++--
 drivers/ata/pata_ns87415.c      |   22 ++-
 drivers/ata/pata_oldpiix.c      |   95 +++-------
 drivers/ata/pata_opti.c         |    2 +
 drivers/ata/pata_pdc2027x.c     |   24 ++-
 drivers/ata/pata_pdc202xx_old.c |   37 ++++-
 drivers/ata/pata_qdi.c          |  366 ---------------------------------------
 drivers/ata/pata_radisys.c      |   78 +++------
 drivers/ata/pata_rdc.c          |  106 ++++--------
 drivers/ata/pata_rz1000.c       |   13 ++-
 drivers/ata/pata_sc1200.c       |    2 +-
 drivers/ata/pata_scc.c          |   16 +--
 drivers/ata/pata_sch.c          |    2 +-
 drivers/ata/pata_serverworks.c  |  104 +++++-------
 drivers/ata/pata_sis.c          |   25 +++-
 drivers/ata/pata_sl82c105.c     |   28 +++-
 drivers/ata/pata_triflex.c      |    2 +-
 drivers/ata/pata_via.c          |   74 ++++----
 drivers/ata/pata_winbond.c      |  282 ------------------------------
 drivers/ata/sata_sil.c          |   33 +---
 include/linux/ata.h             |   11 ++
 include/linux/libata.h          |   15 ++-
 47 files changed, 854 insertions(+), 1814 deletions(-)
 delete mode 100644 drivers/ata/pata_qdi.c
 delete mode 100644 drivers/ata/pata_winbond.c

[PATCH 01/86] ata_piix: fix MWDMA handling on PIIX3

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ata_piix: fix MWDMA handling on PIIX3

Fix erroneous check for ap->udma_mask in do_pata_set_dmamode()
resulting in controller not being programmed properly for MWDMA.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/ata_piix.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: b/drivers/ata/ata_piix.c
===================================================================
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -869,10 +869,10 @@ static void do_pata_set_dmamode(struct a
 				(timings[pio][1] << 8);
 		}
 
-		if (ap->udma_mask) {
+		if (ap->udma_mask)
 			udma_enable &= ~(1 << devid);
-			pci_write_config_word(dev, master_port, master_data);
-		}
+
+		pci_write_config_word(dev, master_port, master_data);
 	}
 	/* Don't scribble on 0x48 if the controller does not support UDMA */
 	if (ap->udma_mask)

[PATCH 02/86] ata_piix: unify code for programming PIO and MWDMA timings

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ata_piix: unify code for programming PIO and MWDMA timings

It results in ~2% decrease in the driver LOC count and also ~2%
decrease in the driver binary size (as measured on x86-32).

This change should be safe as this is how we have been doing
things in IDE piix host driver for years.

Fix piix_set_piomode() documentation while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/ata_piix.c |  112 ++++++++++++++++---------------------------------
 1 file changed, 37 insertions(+), 75 deletions(-)

Index: b/drivers/ata/ata_piix.c
===================================================================
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -666,22 +666,11 @@ static int piix_pata_prereset(struct ata
 
 static DEFINE_SPINLOCK(piix_lock);
 
-/**
- *	piix_set_piomode - Initialize host controller PATA PIO timings
- *	@ap: Port whose timings we are configuring
- *	@adev: um
- *
- *	Set PIO mode for device, in host controller PCI config space.
- *
- *	LOCKING:
- *	None (inherited from caller).
- */
-
-static void piix_set_piomode(struct ata_port *ap, struct ata_device *adev)
+static void piix_set_timings(struct ata_port *ap, struct ata_device *adev,
+			     u8 pio, bool use_mwdma)
 {
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	unsigned long flags;
-	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	unsigned int is_slave	= (adev->devno != 0);
 	unsigned int master_port= ap->port_no ? 0x42 : 0x40;
 	unsigned int slave_port	= 0x44;
@@ -702,14 +691,18 @@ static void piix_set_piomode(struct ata_
 			    { 2, 1 },
 			    { 2, 3 }, };
 
-	if (pio >= 2)
+	if (pio >= 2 || use_mwdma)
 		control |= 1;	/* TIME1 enable */
-	if (ata_pio_need_iordy(adev))
+	if (ata_pio_need_iordy(adev) || use_mwdma)
 		control |= 2;	/* IE enable */
-
 	/* Intel specifies that the PPE functionality is for disk only */
 	if (adev->class == ATA_DEV_ATA)
 		control |= 4;	/* PPE enable */
+	/* If the drive MWDMA is faster than it can do PIO then
+	   we must force PIO into PIO0 */
+	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
+		/* Enable DMA timing only */
+		control |= 8;	/* PIO cycles in PIO0 */
 
 	spin_lock_irqsave(&piix_lock, flags);
 
@@ -757,6 +750,22 @@ static void piix_set_piomode(struct ata_
 }
 
 /**
+ *	piix_set_piomode - Initialize host controller PATA PIO timings
+ *	@ap: Port whose timings we are configuring
+ *	@adev: Drive in question
+ *
+ *	Set PIO mode for device, in host controller PCI config space.
+ *
+ *	LOCKING:
+ *	None (inherited from caller).
+ */
+
+static void piix_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+	piix_set_timings(ap, adev, adev->pio_mode - XFER_PIO_0, 0);
+}
+
+/**
  *	do_pata_set_dmamode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Drive in question
@@ -772,31 +781,20 @@ static void do_pata_set_dmamode(struct a
 {
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	unsigned long flags;
-	u8 master_port		= ap->port_no ? 0x42 : 0x40;
-	u16 master_data;
 	u8 speed		= adev->dma_mode;
 	int devid		= adev->devno + 2 * ap->port_no;
 	u8 udma_enable		= 0;
 
-	static const	 /* ISP  RTC */
-	u8 timings[][2]	= { { 0, 0 },
-			    { 0, 0 },
-			    { 1, 0 },
-			    { 2, 1 },
-			    { 2, 3 }, };
-
-	spin_lock_irqsave(&piix_lock, flags);
-
-	pci_read_config_word(dev, master_port, &master_data);
-	if (ap->udma_mask)
-		pci_read_config_byte(dev, 0x48, &udma_enable);
-
 	if (speed >= XFER_UDMA_0) {
-		unsigned int udma = adev->dma_mode - XFER_UDMA_0;
+		unsigned int udma = speed - XFER_UDMA_0;
 		u16 udma_timing;
 		u16 ideconf;
 		int u_clock, u_speed;
 
+		spin_lock_irqsave(&piix_lock, flags);
+
+		pci_read_config_byte(dev, 0x48, &udma_enable);
+
 		/*
 		 * UDMA is handled by a combination of clock switching and
 		 * selection of dividers
@@ -829,56 +827,20 @@ static void do_pata_set_dmamode(struct a
 			   performance (WR_PingPong_En) */
 			pci_write_config_word(dev, 0x54, ideconf);
 		}
+
+		pci_write_config_byte(dev, 0x48, udma_enable);
+
+		spin_unlock_irqrestore(&piix_lock, flags);
 	} else {
-		/*
-		 * MWDMA is driven by the PIO timings. We must also enable
-		 * IORDY unconditionally along with TIME1. PPE has already
-		 * been set when the PIO timing was set.
-		 */
-		unsigned int mwdma	= adev->dma_mode - XFER_MW_DMA_0;
-		unsigned int control;
-		u8 slave_data;
+		/* MWDMA is driven by the PIO timings. */
+		unsigned int mwdma = speed - XFER_MW_DMA_0;
 		const unsigned int needed_pio[3] = {
 			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
 		};
 		int pio = needed_pio[mwdma] - XFER_PIO_0;
 
-		control = 3;	/* IORDY|TIME1 */
-
-		/* If the drive MWDMA is faster than it can do PIO then
-		   we must force PIO into PIO0 */
-
-		if (adev->pio_mode < needed_pio[mwdma])
-			/* Enable DMA timing only */
-			control |= 8;	/* PIO cycles in PIO0 */
-
-		if (adev->devno) {	/* Slave */
-			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
-			master_data |= control << 4;
-			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= (ap->port_no ? 0x0f : 0xf0);
-			/* Load the matching timing */
-			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
-			pci_write_config_byte(dev, 0x44, slave_data);
-		} else { 	/* Master */
-			master_data &= 0xCCF4;	/* Mask out IORDY|TIME1|DMAONLY
-						   and master timing bits */
-			master_data |= control;
-			master_data |=
-				(timings[pio][0] << 12) |
-				(timings[pio][1] << 8);
-		}
-
-		if (ap->udma_mask)
-			udma_enable &= ~(1 << devid);
-
-		pci_write_config_word(dev, master_port, master_data);
+		piix_set_timings(ap, adev, pio, 1);
 	}
-	/* Don't scribble on 0x48 if the controller does not support UDMA */
-	if (ap->udma_mask)
-		pci_write_config_byte(dev, 0x48, udma_enable);
-
-	spin_unlock_irqrestore(&piix_lock, flags);
 }
 
 /**

[PATCH 03/86] pata_artop: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_artop: add 32-bit PIO support

There shouldn't be any problems with it as IDE aec62xx host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_artop.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -312,7 +312,7 @@ static struct scsi_host_template artop_s
 };
 
 static struct ata_port_operations artop6210_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.cable_detect		= ata_cable_40wire,
 	.set_piomode		= artop6210_set_piomode,
 	.set_dmamode		= artop6210_set_dmamode,
@@ -321,7 +321,7 @@ static struct ata_port_operations artop6
 };
 
 static struct ata_port_operations artop6260_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.cable_detect		= artop6260_cable_detect,
 	.set_piomode		= artop6260_set_piomode,
 	.set_dmamode		= artop6260_set_dmamode,

[PATCH 04/86] pata_artop: fix chipsets naming

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_artop: fix chipsets naming

6210, 6260[R] and 6280[R] are names used for AEC cards while
ARTOP chipset names are: 850, 860[R] and 865[R] respectively.

Fix the naming used in the driver to avoid confusion and make
it more consistent with pata_atp87x.c.

While at it:
- use atp86x_ prefix for functions used by all ATP86x chipsets
  (previously they were erroneously prefixed with artop6260_)
- use '133' instead of 'fast' to denote UDMA133 support
- use '6880' instead of '6280 + fast' to denote AEC6880 card
- fix documentation of ->prereset method
- fix typo in the documentation of ->qc_defer method
- fix few CodingStyle issues

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_artop.c |  111 +++++++++++++++++++++++------------------------
 1 file changed, 55 insertions(+), 56 deletions(-)

Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -39,7 +39,7 @@
 
 static int clock = 0;
 
-static int artop6210_pre_reset(struct ata_link *link, unsigned long deadline)
+static int atp850_pre_reset(struct ata_link *link, unsigned long deadline)
 {
 	struct ata_port *ap = link->ap;
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
@@ -55,15 +55,14 @@ static int artop6210_pre_reset(struct at
 }
 
 /**
- *	artop6260_pre_reset	-	check for 40/80 pin
+ *	atp86x_pre_reset	-	probe begin
  *	@link: link
  *	@deadline: deadline jiffies for the operation
  *
- *	The ARTOP hardware reports the cable detect bits in register 0x49.
  *	Nothing complicated needed here.
  */
 
-static int artop6260_pre_reset(struct ata_link *link, unsigned long deadline)
+static int atp86x_pre_reset(struct ata_link *link, unsigned long deadline)
 {
 	static const struct pci_bits artop_enable_bits[] = {
 		{ 0x4AU, 1U, 0x02UL, 0x02UL },	/* port 0 */
@@ -81,13 +80,13 @@ static int artop6260_pre_reset(struct at
 }
 
 /**
- *	artop6260_cable_detect	-	identify cable type
+ *	atp86x_cable_detect	-	identify cable type
  *	@ap: Port
  *
  *	Identify the cable type for the ARTOP interface in question
  */
 
-static int artop6260_cable_detect(struct ata_port *ap)
+static int atp86x_cable_detect(struct ata_port *ap)
 {
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
 	u8 tmp;
@@ -98,7 +97,7 @@ static int artop6260_cable_detect(struct
 }
 
 /**
- *	artop6210_load_piomode - Load a set of PATA PIO timings
+ *	atp850_load_piomode - Load a set of PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device
  *	@pio: PIO mode
@@ -111,7 +110,8 @@ static int artop6260_cable_detect(struct
  *	None (inherited from caller).
  */
 
-static void artop6210_load_piomode(struct ata_port *ap, struct ata_device *adev, unsigned int pio)
+static void atp850_load_piomode(struct ata_port *ap, struct ata_device *adev,
+				unsigned int pio)
 {
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
 	int dn = adev->devno + 2 * ap->port_no;
@@ -125,7 +125,7 @@ static void artop6210_load_piomode(struc
 }
 
 /**
- *	artop6210_set_piomode - Initialize host controller PATA PIO timings
+ *	atp850_set_piomode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device we are configuring
  *
@@ -138,13 +138,13 @@ static void artop6210_load_piomode(struc
  *	None (inherited from caller).
  */
 
-static void artop6210_set_piomode(struct ata_port *ap, struct ata_device *adev)
+static void atp850_set_piomode(struct ata_port *ap, struct ata_device *adev)
 {
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
 	int dn = adev->devno + 2 * ap->port_no;
 	u8 ultra;
 
-	artop6210_load_piomode(ap, adev, adev->pio_mode - XFER_PIO_0);
+	atp850_load_piomode(ap, adev, adev->pio_mode - XFER_PIO_0);
 
 	/* Clear the UDMA mode bits (set_dmamode will redo this if needed) */
 	pci_read_config_byte(pdev, 0x54, &ultra);
@@ -153,19 +153,20 @@ static void artop6210_set_piomode(struct
 }
 
 /**
- *	artop6260_load_piomode - Initialize host controller PATA PIO timings
+ *	atp86x_load_piomode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device we are configuring
  *	@pio: PIO mode
  *
- *	Set PIO mode for device, in host controller PCI config space. The
- *	ARTOP6260 and relatives store the timing data differently.
+ *	Set PIO mode for device, in host controller PCI config space.
+ *	The ATP860 and relatives store the timing data differently.
  *
  *	LOCKING:
  *	None (inherited from caller).
  */
 
-static void artop6260_load_piomode (struct ata_port *ap, struct ata_device *adev, unsigned int pio)
+static void atp86x_load_piomode(struct ata_port *ap, struct ata_device *adev,
+				unsigned int pio)
 {
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
 	int dn = adev->devno + 2 * ap->port_no;
@@ -179,7 +180,7 @@ static void artop6260_load_piomode (stru
 }
 
 /**
- *	artop6260_set_piomode - Initialize host controller PATA PIO timings
+ *	atp86x_set_piomode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device we are configuring
  *
@@ -192,12 +193,12 @@ static void artop6260_load_piomode (stru
  *	None (inherited from caller).
  */
 
-static void artop6260_set_piomode(struct ata_port *ap, struct ata_device *adev)
+static void atp86x_set_piomode(struct ata_port *ap, struct ata_device *adev)
 {
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
 	u8 ultra;
 
-	artop6260_load_piomode(ap, adev, adev->pio_mode - XFER_PIO_0);
+	atp86x_load_piomode(ap, adev, adev->pio_mode - XFER_PIO_0);
 
 	/* Clear the UDMA mode bits (set_dmamode will redo this if needed) */
 	pci_read_config_byte(pdev, 0x44 + ap->port_no, &ultra);
@@ -206,7 +207,7 @@ static void artop6260_set_piomode(struct
 }
 
 /**
- *	artop6210_set_dmamode - Initialize host controller PATA PIO timings
+ *	atp850_set_dmamode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device whose timings we are configuring
  *
@@ -216,7 +217,7 @@ static void artop6260_set_piomode(struct
  *	None (inherited from caller).
  */
 
-static void artop6210_set_dmamode (struct ata_port *ap, struct ata_device *adev)
+static void atp850_set_dmamode(struct ata_port *ap, struct ata_device *adev)
 {
 	unsigned int pio;
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
@@ -229,7 +230,7 @@ static void artop6210_set_dmamode (struc
 		pio = 4;
 
 	/* Load the PIO timing active/recovery bits */
-	artop6210_load_piomode(ap, adev, pio);
+	atp850_load_piomode(ap, adev, pio);
 
 	pci_read_config_byte(pdev, 0x54, &ultra);
 	ultra &= ~(3 << (2 * dn));
@@ -245,18 +246,18 @@ static void artop6210_set_dmamode (struc
 }
 
 /**
- *	artop6260_set_dmamode - Initialize host controller PATA PIO timings
+ *	atp86x_set_dmamode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device we are configuring
  *
- *	Set DMA mode for device, in host controller PCI config space. The
- *	ARTOP6260 and relatives store the timing data differently.
+ *	Set DMA mode for device, in host controller PCI config space.
+ *	The ATP860 and relatives store the timing data differently.
  *
  *	LOCKING:
  *	None (inherited from caller).
  */
 
-static void artop6260_set_dmamode (struct ata_port *ap, struct ata_device *adev)
+static void atp86x_set_dmamode(struct ata_port *ap, struct ata_device *adev)
 {
 	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
@@ -268,7 +269,7 @@ static void artop6260_set_dmamode (struc
 		pio = 4;
 
 	/* Load the PIO timing active/recovery bits */
-	artop6260_load_piomode(ap, adev, pio);
+	atp86x_load_piomode(ap, adev, pio);
 
 	/* Add ultra DMA bits if in UDMA mode */
 	pci_read_config_byte(pdev, 0x44 + ap->port_no, &ultra);
@@ -283,13 +284,13 @@ static void artop6260_set_dmamode (struc
 }
 
 /**
- *	artop_6210_qc_defer	-	implement serialization
+ *	atp850_qc_defer	-	implement serialization
  *	@qc: command
  *
  *	Issue commands per host on this chip.
  */
 
-static int artop6210_qc_defer(struct ata_queued_cmd *qc)
+static int atp850_qc_defer(struct ata_queued_cmd *qc)
 {
 	struct ata_host *host = qc->ap->host;
 	struct ata_port *alt = host->ports[1 ^ qc->ap->port_no];
@@ -311,21 +312,21 @@ static struct scsi_host_template artop_s
 	ATA_BMDMA_SHT(DRV_NAME),
 };
 
-static struct ata_port_operations artop6210_ops = {
+static struct ata_port_operations atp850_ops = {
 	.inherits		= &ata_bmdma32_port_ops,
 	.cable_detect		= ata_cable_40wire,
-	.set_piomode		= artop6210_set_piomode,
-	.set_dmamode		= artop6210_set_dmamode,
-	.prereset		= artop6210_pre_reset,
-	.qc_defer		= artop6210_qc_defer,
+	.set_piomode		= atp850_set_piomode,
+	.set_dmamode		= atp850_set_dmamode,
+	.prereset		= atp850_pre_reset,
+	.qc_defer		= atp850_qc_defer,
 };
 
-static struct ata_port_operations artop6260_ops = {
+static struct ata_port_operations atp86x_ops = {
 	.inherits		= &ata_bmdma32_port_ops,
-	.cable_detect		= artop6260_cable_detect,
-	.set_piomode		= artop6260_set_piomode,
-	.set_dmamode		= artop6260_set_dmamode,
-	.prereset		= artop6260_pre_reset,
+	.cable_detect		= atp86x_cable_detect,
+	.set_piomode		= atp86x_set_piomode,
+	.set_dmamode		= atp86x_set_dmamode,
+	.prereset		= atp86x_pre_reset,
 };
 
 
@@ -346,33 +347,33 @@ static struct ata_port_operations artop6
 static int artop_init_one (struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	static int printed_version;
-	static const struct ata_port_info info_6210 = {
+	static const struct ata_port_info atp850_info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
 		.mwdma_mask	= ATA_MWDMA2,
 		.udma_mask 	= ATA_UDMA2,
-		.port_ops	= &artop6210_ops,
+		.port_ops	= &atp850_ops,
 	};
-	static const struct ata_port_info info_626x = {
+	static const struct ata_port_info atp860_info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
 		.mwdma_mask	= ATA_MWDMA2,
 		.udma_mask 	= ATA_UDMA4,
-		.port_ops	= &artop6260_ops,
+		.port_ops	= &atp86x_ops,
 	};
-	static const struct ata_port_info info_628x = {
+	static const struct ata_port_info atp865_info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
 		.mwdma_mask	= ATA_MWDMA2,
 		.udma_mask 	= ATA_UDMA5,
-		.port_ops	= &artop6260_ops,
+		.port_ops	= &atp86x_ops,
 	};
-	static const struct ata_port_info info_628x_fast = {
+	static const struct ata_port_info atp865_133_info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
 		.mwdma_mask	= ATA_MWDMA2,
 		.udma_mask 	= ATA_UDMA6,
-		.port_ops	= &artop6260_ops,
+		.port_ops	= &atp86x_ops,
 	};
 	const struct ata_port_info *ppi[] = { NULL, NULL };
 	int rc;
@@ -385,20 +386,19 @@ static int artop_init_one (struct pci_de
 	if (rc)
 		return rc;
 
-	if (id->driver_data == 0) {	/* 6210 variant */
-		ppi[0] = &info_6210;
+	if (id->driver_data == 0) {		/* AEC6210 */
+		ppi[0] = &atp850_info;
 		/* BIOS may have left us in UDMA, clear it before libata probe */
 		pci_write_config_byte(pdev, 0x54, 0);
-	}
-	else if (id->driver_data == 1)	/* 6260 */
-		ppi[0] = &info_626x;
-	else if (id->driver_data == 2)	{ /* 6280 or 6280 + fast */
+	} else if (id->driver_data == 1) {	/* AEC6260[R] */
+		ppi[0] = &atp860_info;
+	} else if (id->driver_data == 2) { 	/* AEC6280[R] */
 		unsigned long io = pci_resource_start(pdev, 4);
 		u8 reg;
 
-		ppi[0] = &info_628x;
-		if (inb(io) & 0x10)
-			ppi[0] = &info_628x_fast;
+		ppi[0] = &atp865_info;
+		if (inb(io) & 0x10)		/* AEC6880[R] */
+			ppi[0] = &atp865_133_info;
 		/* Mac systems come up with some registers not set as we
 		   will need them */
 
@@ -416,7 +416,6 @@ static int artop_init_one (struct pci_de
 		/* Enable IRQ output and burst mode */
 		pci_read_config_byte(pdev, 0x4a, &reg);
 		pci_write_config_byte(pdev, 0x4a, (reg & ~0x01) | 0x80);
-
 	}
 
 	BUG_ON(ppi[0] == NULL);

[PATCH 05/86] pata_artop: add Power Management support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_artop: add Power Management support

There shouldn't be any problems with it as IDE aec62xx host driver
has been supporting Power Management for over year now.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_artop.c |   72 +++++++++++++++++++++++++++++++++--------------
 1 file changed, 51 insertions(+), 21 deletions(-)

Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -2,7 +2,7 @@
  *    pata_artop.c - ARTOP ATA controller driver
  *
  *	(C) 2006 Red Hat
- *	(C) 2007 Bartlomiej Zolnierkiewicz
+ *	(C) 2007,2009 Bartlomiej Zolnierkiewicz
  *
  *    Based in part on drivers/ide/pci/aec62xx.c
  *	Copyright (C) 1999-2002	Andre Hedrick <andre@linux-ide.org>
@@ -330,6 +330,33 @@ static struct ata_port_operations atp86x
 	.prereset		= atp86x_pre_reset,
 };
 
+static void atp8xx_fixup(struct pci_dev *pdev)
+{
+	if (pdev->device == 0x0005)
+		/* BIOS may have left us in UDMA, clear it before probe */
+		pci_write_config_byte(pdev, 0x54, 0);
+	else if (pdev->device == 0x0008 || pdev->device == 0x0009) {
+		u8 reg;
+
+		/* Mac systems come up with some registers not set as we
+		   will need them */
+
+		/* Clear reset & test bits */
+		pci_read_config_byte(pdev, 0x49, &reg);
+		pci_write_config_byte(pdev, 0x49, reg & ~ 0x30);
+
+		/* PCI latency must be > 0x80 for burst mode, tweak it
+		 * if required.
+		 */
+		pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &reg);
+		if (reg <= 0x80)
+			pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x90);
+
+		/* Enable IRQ output and burst mode */
+		pci_read_config_byte(pdev, 0x4a, &reg);
+		pci_write_config_byte(pdev, 0x4a, (reg & ~0x01) | 0x80);
+	}
+}
 
 /**
  *	artop_init_one - Register ARTOP ATA PCI device with kernel services
@@ -389,41 +416,40 @@ static int artop_init_one (struct pci_de
 
 	if (id->driver_data == 0) {		/* AEC6210 */
 		ppi[0] = &atp850_info;
-		/* BIOS may have left us in UDMA, clear it before libata probe */
-		pci_write_config_byte(pdev, 0x54, 0);
 	} else if (id->driver_data == 1) {	/* AEC6260[R] */
 		ppi[0] = &atp860_info;
 	} else if (id->driver_data == 2) { 	/* AEC6280[R] */
 		unsigned long io = pci_resource_start(pdev, 4);
-		u8 reg;
 
 		ppi[0] = &atp865_info;
 		if (inb(io) & 0x10)		/* AEC6880[R] */
 			ppi[0] = &atp865_133_info;
-		/* Mac systems come up with some registers not set as we
-		   will need them */
-
-		/* Clear reset & test bits */
-		pci_read_config_byte(pdev, 0x49, &reg);
-		pci_write_config_byte(pdev, 0x49, reg & ~ 0x30);
-
-		/* PCI latency must be > 0x80 for burst mode, tweak it
-		 * if required.
-		 */
-		pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &reg);
-		if (reg <= 0x80)
-			pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x90);
-
-		/* Enable IRQ output and burst mode */
-		pci_read_config_byte(pdev, 0x4a, &reg);
-		pci_write_config_byte(pdev, 0x4a, (reg & ~0x01) | 0x80);
 	}
 
 	BUG_ON(ppi[0] == NULL);
 
+	atp8xx_fixup(pdev);
+
 	return ata_pci_sff_init_one(pdev, ppi, &artop_sht, NULL);
 }
 
+#ifdef CONFIG_PM
+static int atp8xx_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	atp8xx_fixup(pdev);
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 static const struct pci_device_id artop_pci_tbl[] = {
 	{ PCI_VDEVICE(ARTOP, 0x0005), 0 },
 	{ PCI_VDEVICE(ARTOP, 0x0006), 1 },
@@ -439,6 +465,10 @@ static struct pci_driver artop_pci_drive
 	.id_table		= artop_pci_tbl,
 	.probe			= artop_init_one,
 	.remove			= ata_pci_remove_one,
+#ifdef CONFIG_PM
+	.suspend		= ata_pci_device_suspend,
+	.resume			= atp8xx_reinit_one,
+#endif
 };
 
 static int __init artop_init(void)

[PATCH 06/86] pata_artop: unify ->prereset methods

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_artop: unify ->prereset methods

We can use the same ->prereset method for ATP850 and ATP86xR chipsets.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_artop.c |   28 +++++++---------------------
 1 file changed, 7 insertions(+), 21 deletions(-)

Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -39,30 +39,15 @@
 
 static int clock = 0;
 
-static int atp850_pre_reset(struct ata_link *link, unsigned long deadline)
-{
-	struct ata_port *ap = link->ap;
-	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
-	const struct pci_bits artop_enable_bits[] = {
-		{ 0x4AU, 1U, 0x02UL, 0x02UL },	/* port 0 */
-		{ 0x4AU, 1U, 0x04UL, 0x04UL },	/* port 1 */
-	};
-
-	if (!pci_test_config_bits(pdev, &artop_enable_bits[ap->port_no]))
-		return -ENOENT;
-
-	return ata_sff_prereset(link, deadline);
-}
-
 /**
- *	atp86x_pre_reset	-	probe begin
+ *	atp8xx_prereset	-	probe begin
  *	@link: link
  *	@deadline: deadline jiffies for the operation
  *
  *	Nothing complicated needed here.
  */
 
-static int atp86x_pre_reset(struct ata_link *link, unsigned long deadline)
+static int atp8xx_prereset(struct ata_link *link, unsigned long deadline)
 {
 	static const struct pci_bits artop_enable_bits[] = {
 		{ 0x4AU, 1U, 0x02UL, 0x02UL },	/* port 0 */
@@ -72,8 +57,9 @@ static int atp86x_pre_reset(struct ata_l
 	struct ata_port *ap = link->ap;
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
 
-	/* Odd numbered device ids are the units with enable bits (the -R cards) */
-	if (pdev->device % 1 && !pci_test_config_bits(pdev, &artop_enable_bits[ap->port_no]))
+	/* Odd numbered device ids are the units with enable bits. */
+	if (pdev->device % 1 &&
+	    !pci_test_config_bits(pdev, &artop_enable_bits[ap->port_no]))
 		return -ENOENT;
 
 	return ata_sff_prereset(link, deadline);
@@ -317,7 +303,7 @@ static struct ata_port_operations atp850
 	.cable_detect		= ata_cable_40wire,
 	.set_piomode		= atp850_set_piomode,
 	.set_dmamode		= atp850_set_dmamode,
-	.prereset		= atp850_pre_reset,
+	.prereset		= atp8xx_prereset,
 	.qc_defer		= atp850_qc_defer,
 };
 
@@ -326,7 +312,7 @@ static struct ata_port_operations atp86x
 	.cable_detect		= atp86x_cable_detect,
 	.set_piomode		= atp86x_set_piomode,
 	.set_dmamode		= atp86x_set_dmamode,
-	.prereset		= atp86x_pre_reset,
+	.prereset		= atp8xx_prereset,
 };
 
 static void atp8xx_fixup(struct pci_dev *pdev)

[PATCH 07/86] pata_artop: remove dead 34MHz PCI clock support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_artop: remove dead 34MHz PCI clock support

It has been dead for the last three years (== since the initial driver
merge) and probability that it will ever get fixed is quite low.

Since there is no reason to keep this dead code around any longer just
remove it (it can still be retrieved from the git history if necessary).

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_artop.c |   29 ++++++++---------------------
 1 file changed, 8 insertions(+), 21 deletions(-)

Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -30,15 +30,6 @@
 #define DRV_NAME	"pata_artop"
 #define DRV_VERSION	"0.4.5"
 
-/*
- *	The ARTOP has 33 Mhz and "over clocked" timing tables. Until we
- *	get PCI bus speed functionality we leave this as 0. Its a variable
- *	for when we get the functionality and also for folks wanting to
- *	test stuff.
- */
-
-static int clock = 0;
-
 /**
  *	atp8xx_prereset	-	probe begin
  *	@link: link
@@ -101,13 +92,11 @@ static void atp850_load_piomode(struct a
 {
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
 	int dn = adev->devno + 2 * ap->port_no;
-	const u16 timing[2][5] = {
-		{ 0x0000, 0x000A, 0x0008, 0x0303, 0x0301 },
-		{ 0x0700, 0x070A, 0x0708, 0x0403, 0x0401 }
+	const u16 timing[5] =
+		{ 0x0000, 0x000A, 0x0008, 0x0303, 0x0301 };
 
-	};
 	/* Load the PIO timing active/recovery bits */
-	pci_write_config_word(pdev, 0x40 + 2 * dn, timing[clock][pio]);
+	pci_write_config_word(pdev, 0x40 + 2 * dn, timing[pio]);
 }
 
 /**
@@ -156,13 +145,11 @@ static void atp86x_load_piomode(struct a
 {
 	struct pci_dev *pdev	= to_pci_dev(ap->host->dev);
 	int dn = adev->devno + 2 * ap->port_no;
-	const u8 timing[2][5] = {
-		{ 0x00, 0x0A, 0x08, 0x33, 0x31 },
-		{ 0x70, 0x7A, 0x78, 0x43, 0x41 }
+	const u8 timing[5] =
+		{ 0x00, 0x0A, 0x08, 0x33, 0x31 };
 
-	};
 	/* Load the PIO timing active/recovery bits */
-	pci_write_config_byte(pdev, 0x40 + dn, timing[clock][pio]);
+	pci_write_config_byte(pdev, 0x40 + dn, timing[pio]);
 }
 
 /**
@@ -223,7 +210,7 @@ static void atp850_set_dmamode(struct at
 
 	/* Add ultra DMA bits if in UDMA mode */
 	if (adev->dma_mode >= XFER_UDMA_0) {
-		u8 mode = (adev->dma_mode - XFER_UDMA_0) + 1 - clock;
+		u8 mode = (adev->dma_mode - XFER_UDMA_0) + 1;
 		if (mode == 0)
 			mode = 1;
 		ultra |= (mode << (2 * dn));
@@ -261,7 +248,7 @@ static void atp86x_set_dmamode(struct at
 	pci_read_config_byte(pdev, 0x44 + ap->port_no, &ultra);
 	ultra &= ~(7 << (4  * adev->devno));	/* One nibble per drive */
 	if (adev->dma_mode >= XFER_UDMA_0) {
-		u8 mode = adev->dma_mode - XFER_UDMA_0 + 1 - clock;
+		u8 mode = adev->dma_mode - XFER_UDMA_0 + 1;
 		if (mode == 0)
 			mode = 1;
 		ultra |= (mode << (4 * adev->devno));

[PATCH 08/86] pata_atiixp: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_atiixp: add 32-bit PIO support

There shouldn't be any problems with it as IDE atiixp host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_atiixp.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -206,7 +206,7 @@ static struct scsi_host_template atiixp_
 };
 
 static struct ata_port_operations atiixp_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.qc_prep 	= ata_sff_dumb_qc_prep,
 	.bmdma_start 	= atiixp_bmdma_start,

[PATCH 09/86] pata_atiixp: no need to program PIO timings for MWDMA

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_atiixp: no need to program PIO timings for MWDMA

Moreover the code to do it was buggy and programmed PIO timings
even if they were already set to a desired values.

There shouldn't be any problems with it as IDE atiixp host driver
has been allowing separate PIO/MWDMA timings for last two years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_atiixp.c |   15 ---------------
 1 file changed, 15 deletions(-)

Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -107,7 +107,6 @@ static void atiixp_set_dmamode(struct at
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
 	int dma = adev->dma_mode;
 	int dn = 2 * ap->port_no + adev->devno;
-	int wanted_pio;
 
 	if (adev->dma_mode >= XFER_UDMA_0) {
 		u16 udma_mode_data;
@@ -131,20 +130,6 @@ static void atiixp_set_dmamode(struct at
 		pci_write_config_dword(pdev, ATIIXP_IDE_MWDMA_TIMING,
 				       mwdma_timing_data);
 	}
-	/*
-	 *	We must now look at the PIO mode situation. We may need to
-	 *	adjust the PIO mode to keep the timings acceptable
-	 */
-	 if (adev->dma_mode >= XFER_MW_DMA_2)
-	 	wanted_pio = 4;
-	else if (adev->dma_mode == XFER_MW_DMA_1)
-		wanted_pio = 3;
-	else if (adev->dma_mode == XFER_MW_DMA_0)
-		wanted_pio = 0;
-	else BUG();
-
-	if (adev->pio_mode != wanted_pio)
-		atiixp_set_pio_timing(ap, adev, wanted_pio);
 }
 
 /**

[PATCH 10/86] pata_atiixp: add MWDMA0 support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_atiixp: add MWDMA0 support

There shouldn't be any problems with it as IDE atiixp host driver
has been allowing MWDMA0 mode for last two years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_atiixp.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -207,7 +207,7 @@ static int atiixp_init_one(struct pci_de
 	static const struct ata_port_info info = {
 		.flags = ATA_FLAG_SLAVE_POSS,
 		.pio_mask = ATA_PIO4,
-		.mwdma_mask = ATA_MWDMA12_ONLY,
+		.mwdma_mask = ATA_MWDMA2,
 		.udma_mask = ATA_UDMA5,
 		.port_ops = &atiixp_port_ops
 	};

[PATCH 11/86] pata_atiixp: remove custom BMDMA methods

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_atiixp: remove custom BMDMA methods

Enable/disable UDMA bit only once in ->set_dmamode method
and then remove custom ->bmdma_[start,stop] methods.

There shouldn't be any problems with it as IDE atiixp host driver
has been doing it this way for last two years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_atiixp.c |   58 ++++------------------------------------------
 1 file changed, 6 insertions(+), 52 deletions(-)

Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -107,6 +107,9 @@ static void atiixp_set_dmamode(struct at
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
 	int dma = adev->dma_mode;
 	int dn = 2 * ap->port_no + adev->devno;
+	u16 tmp16;
+
+	pci_read_config_word(pdev, ATIIXP_IDE_UDMA_CONTROL, &tmp16);
 
 	if (adev->dma_mode >= XFER_UDMA_0) {
 		u16 udma_mode_data;
@@ -117,6 +120,8 @@ static void atiixp_set_dmamode(struct at
 		udma_mode_data &= ~(0x7 << (4 * dn));
 		udma_mode_data |= dma << (4 * dn);
 		pci_write_config_word(pdev, ATIIXP_IDE_UDMA_MODE, udma_mode_data);
+
+		tmp16 |= (1 << dn);
 	} else {
 		int timing_shift = (16 * ap->port_no) + 8 * (adev->devno ^ 1);
 		u32 mwdma_timing_data;
@@ -129,60 +134,11 @@ static void atiixp_set_dmamode(struct at
 		mwdma_timing_data |= (mwdma_timings[dma] << timing_shift);
 		pci_write_config_dword(pdev, ATIIXP_IDE_MWDMA_TIMING,
 				       mwdma_timing_data);
-	}
-}
-
-/**
- *	atiixp_bmdma_start	-	DMA start callback
- *	@qc: Command in progress
- *
- *	When DMA begins we need to ensure that the UDMA control
- *	register for the channel is correctly set.
- *
- *	Note: The host lock held by the libata layer protects
- *	us from two channels both trying to set DMA bits at once
- */
-
-static void atiixp_bmdma_start(struct ata_queued_cmd *qc)
-{
-	struct ata_port *ap = qc->ap;
-	struct ata_device *adev = qc->dev;
-
-	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
-	int dn = (2 * ap->port_no) + adev->devno;
-	u16 tmp16;
 
-	pci_read_config_word(pdev, ATIIXP_IDE_UDMA_CONTROL, &tmp16);
-	if (ata_using_udma(adev))
-		tmp16 |= (1 << dn);
-	else
 		tmp16 &= ~(1 << dn);
-	pci_write_config_word(pdev, ATIIXP_IDE_UDMA_CONTROL, tmp16);
-	ata_bmdma_start(qc);
-}
-
-/**
- *	atiixp_dma_stop	-	DMA stop callback
- *	@qc: Command in progress
- *
- *	DMA has completed. Clear the UDMA flag as the next operations will
- *	be PIO ones not UDMA data transfer.
- *
- *	Note: The host lock held by the libata layer protects
- *	us from two channels both trying to set DMA bits at once
- */
-
-static void atiixp_bmdma_stop(struct ata_queued_cmd *qc)
-{
-	struct ata_port *ap = qc->ap;
-	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
-	int dn = (2 * ap->port_no) + qc->dev->devno;
-	u16 tmp16;
+	}
 
-	pci_read_config_word(pdev, ATIIXP_IDE_UDMA_CONTROL, &tmp16);
-	tmp16 &= ~(1 << dn);
 	pci_write_config_word(pdev, ATIIXP_IDE_UDMA_CONTROL, tmp16);
-	ata_bmdma_stop(qc);
 }
 
 static struct scsi_host_template atiixp_sht = {
@@ -194,8 +150,6 @@ static struct ata_port_operations atiixp
 	.inherits	= &ata_bmdma32_port_ops,
 
 	.qc_prep 	= ata_sff_dumb_qc_prep,
-	.bmdma_start 	= atiixp_bmdma_start,
-	.bmdma_stop	= atiixp_bmdma_stop,
 
 	.cable_detect	= atiixp_cable_detect,
 	.set_piomode	= atiixp_set_piomode,

[PATCH 12/86] pata_atiixp: add proper ->prereset method

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_atiixp: add proper ->prereset method

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_atiixp.c |   35 ++++++++++++++++++++++++++---------
 1 file changed, 26 insertions(+), 9 deletions(-)

Index: b/drivers/ata/pata_atiixp.c
===================================================================
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -47,6 +47,31 @@ static int atiixp_cable_detect(struct at
 }
 
 /**
+ *	atiixp_prereset	-	perform reset handling
+ *	@link: ATA link
+ *	@deadline: deadline jiffies for the operation
+ *
+ *	Reset sequence checking enable bits to see which ports are
+ *	active.
+ */
+
+static int atiixp_prereset(struct ata_link *link, unsigned long deadline)
+{
+	static const struct pci_bits atiixp_enable_bits[] = {
+		{ 0x48, 1, 0x01, 0x00 },
+		{ 0x48, 1, 0x08, 0x00 }
+	};
+
+	struct ata_port *ap = link->ap;
+	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
+
+	if (!pci_test_config_bits(pdev, &atiixp_enable_bits[ap->port_no]))
+		return -ENOENT;
+
+	return ata_sff_prereset(link, deadline);
+}
+
+/**
  *	atiixp_set_pio_timing	-	set initial PIO mode data
  *	@ap: ATA interface
  *	@adev: ATA device
@@ -151,6 +176,7 @@ static struct ata_port_operations atiixp
 
 	.qc_prep 	= ata_sff_dumb_qc_prep,
 
+	.prereset	= atiixp_prereset,
 	.cable_detect	= atiixp_cable_detect,
 	.set_piomode	= atiixp_set_piomode,
 	.set_dmamode	= atiixp_set_dmamode,
@@ -165,16 +191,7 @@ static int atiixp_init_one(struct pci_de
 		.udma_mask = ATA_UDMA5,
 		.port_ops = &atiixp_port_ops
 	};
-	static const struct pci_bits atiixp_enable_bits[] = {
-		{ 0x48, 1, 0x01, 0x00 },
-		{ 0x48, 1, 0x08, 0x00 }
-	};
 	const struct ata_port_info *ppi[] = { &info, &info };
-	int i;
-
-	for (i = 0; i < 2; i++)
-		if (!pci_test_config_bits(pdev, &atiixp_enable_bits[i]))
-			ppi[i] = &ata_dummy_port_info;
 
 	return ata_pci_sff_init_one(pdev, ppi, &atiixp_sht, NULL);
 }

[PATCH 13/86] pata_efar: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_efar: add 32-bit PIO support

There shouldn't be any problems with it as IDE slc90e66 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_efar.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -223,7 +223,7 @@ static struct scsi_host_template efar_sh
 };
 
 static struct ata_port_operations efar_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.cable_detect		= efar_cable_detect,
 	.set_piomode		= efar_set_piomode,
 	.set_dmamode		= efar_set_dmamode,

[PATCH 14/86] pata_efar: fix wrong PIO timings being programmed

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_efar: fix wrong PIO timings being programmed

* do not clear PIO timings for master when programming slave
* do not clear PIO timings for device on the other port when
  programming slave device

Both changes should be safe as this is how we have been doing
things in IDE slc90e66 host driver for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_efar.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -2,6 +2,7 @@
  *    pata_efar.c - EFAR PIIX clone controller driver
  *
  *	(C) 2005 Red Hat
+ *	(C) 2009 Bartlomiej Zolnierkiewicz
  *
  *    Some parts based on ata_piix.c by Jeff Garzik and others.
  *
@@ -118,12 +119,12 @@ static void efar_set_piomode (struct ata
 		int shift = 4 * ap->port_no;
 		u8 slave_data;
 
-		idetm_data &= 0xCC0F;
+		idetm_data &= 0xFF0F;
 		idetm_data |= (control << 4);
 
 		/* Slave timing in separate register */
 		pci_read_config_byte(dev, 0x44, &slave_data);
-		slave_data &= 0x0F << shift;
+		slave_data &= ap->port_no ? 0x0F : 0xF0;
 		slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << shift;
 		pci_write_config_byte(dev, 0x44, slave_data);
 	}

[PATCH 15/86] pata_efar: fix wrong MWDMA timings being programmed

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_efar: fix wrong MWDMA timings being programmed

Do not clear MWDMA timings for device on the other port when
programming slave device.

This change should be safe as this is how we have been doing
things in IDE slc90e66 host driver for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_efar.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -201,7 +201,7 @@ static void efar_set_dmamode (struct ata
 			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
 			master_data |= control << 4;
 			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= (0x0F + 0xE1 * ap->port_no);
+			slave_data &= ap->port_no ? 0x0F : 0xF0;
 			/* Load the matching timing */
 			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
 			pci_write_config_byte(dev, 0x44, slave_data);

[PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_efar: MWDMA0 is unsupported

MWDMA0 timings cannot be met with the PIIX based controller
programming interface.

This change should be safe as this is how we have been doing
things in IDE slc90e66 host driver for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_efar.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -252,7 +252,7 @@ static int efar_init_one (struct pci_dev
 	static const struct ata_port_info info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
-		.mwdma_mask	= ATA_MWDMA2,
+		.mwdma_mask	= ATA_MWDMA12_ONLY,
 		.udma_mask 	= ATA_UDMA4,
 		.port_ops	= &efar_ops,
 	};

[PATCH 17/86] pata_efar: fix register naming used in efar_set_piomode()

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_efar: fix register naming used in efar_set_piomode()

Rename 'idetm_port' and 'idetm_data' variables to 'master_port'
and 'master_data' respectively to match register naming used in
efar_set_dma_mode() and in ata_piix.c.

Fix efar_set_piomode() documentation and 'master_port' type
while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_efar.c |   22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -71,7 +71,7 @@ static int efar_cable_detect(struct ata_
 /**
  *	efar_set_piomode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
- *	@adev: um
+ *	@adev: Device to program
  *
  *	Set PIO mode for device, in host controller PCI config space.
  *
@@ -83,8 +83,8 @@ static void efar_set_piomode (struct ata
 {
 	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
-	unsigned int idetm_port= ap->port_no ? 0x42 : 0x40;
-	u16 idetm_data;
+	u8 master_port		= ap->port_no ? 0x42 : 0x40;
+	u16 master_data;
 	int control = 0;
 
 	/*
@@ -107,20 +107,20 @@ static void efar_set_piomode (struct ata
 	if (adev->class == ATA_DEV_ATA)
 		control |= 4;	/* PPE */
 
-	pci_read_config_word(dev, idetm_port, &idetm_data);
+	pci_read_config_word(dev, master_port, &master_data);
 
 	/* Set PPE, IE, and TIME as appropriate */
 	if (adev->devno == 0) {
-		idetm_data &= 0xCCF0;
-		idetm_data |= control;
-		idetm_data |= (timings[pio][0] << 12) |
+		master_data &= 0xCCF0;
+		master_data |= control;
+		master_data |= (timings[pio][0] << 12) |
 			(timings[pio][1] << 8);
 	} else {
 		int shift = 4 * ap->port_no;
 		u8 slave_data;
 
-		idetm_data &= 0xFF0F;
-		idetm_data |= (control << 4);
+		master_data &= 0xFF0F;
+		master_data |= (control << 4);
 
 		/* Slave timing in separate register */
 		pci_read_config_byte(dev, 0x44, &slave_data);
@@ -129,8 +129,8 @@ static void efar_set_piomode (struct ata
 		pci_write_config_byte(dev, 0x44, slave_data);
 	}
 
-	idetm_data |= 0x4000;	/* Ensure SITRE is set */
-	pci_write_config_word(dev, idetm_port, idetm_data);
+	master_data |= 0x4000;	/* Ensure SITRE is set */
+	pci_write_config_word(dev, master_port, master_data);
 }
 
 /**

[PATCH 18/86] pata_efar: unify code for programming PIO and MWDMA timings

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_efar: unify code for programming PIO and MWDMA timings

It results in ~10% decrease in the driver LOC count and also ~8%
decrease in the driver binary size (as measured on x86-32).

This change should be safe as this is how we have been doing
things in IDE slc90e66 host driver for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_efar.c |   88 +++++++++++++++---------------------------------
 1 file changed, 29 insertions(+), 59 deletions(-)

Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -68,20 +68,9 @@ static int efar_cable_detect(struct ata_
 	return ATA_CBL_PATA80;
 }
 
-/**
- *	efar_set_piomode - Initialize host controller PATA PIO timings
- *	@ap: Port whose timings we are configuring
- *	@adev: Device to program
- *
- *	Set PIO mode for device, in host controller PCI config space.
- *
- *	LOCKING:
- *	None (inherited from caller).
- */
-
-static void efar_set_piomode (struct ata_port *ap, struct ata_device *adev)
+static void efar_set_timings(struct ata_port *ap, struct ata_device *adev,
+			     u8 pio, bool use_mwdma)
 {
-	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	u8 master_port		= ap->port_no ? 0x42 : 0x40;
 	u16 master_data;
@@ -99,13 +88,18 @@ static void efar_set_piomode (struct ata
 			    { 2, 1 },
 			    { 2, 3 }, };
 
-	if (pio > 1)
+	if (pio > 1 || use_mwdma)
 		control |= 1;	/* TIME */
-	if (ata_pio_need_iordy(adev))	/* PIO 3/4 require IORDY */
+	if (ata_pio_need_iordy(adev) || use_mwdma)
 		control |= 2;	/* IE */
 	/* Intel specifies that the prefetch/posting is for disk only */
 	if (adev->class == ATA_DEV_ATA)
 		control |= 4;	/* PPE */
+	/* If the drive MWDMA is faster than it can do PIO then
+	   we must force PIO into PIO0 */
+	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
+		/* Enable DMA timing only */
+		control |= 8;	/* PIO cycles in PIO0 */
 
 	pci_read_config_word(dev, master_port, &master_data);
 
@@ -134,6 +128,22 @@ static void efar_set_piomode (struct ata
 }
 
 /**
+ *	efar_set_piomode - Initialize host controller PATA PIO timings
+ *	@ap: Port whose timings we are configuring
+ *	@adev: Device to program
+ *
+ *	Set PIO mode for device, in host controller PCI config space.
+ *
+ *	LOCKING:
+ *	None (inherited from caller).
+ */
+
+static void efar_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+	efar_set_timings(ap, adev, adev->pio_mode - XFER_PIO_0, 0);
+}
+
+/**
  *	efar_set_dmamode - Initialize host controller PATA DMA timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device to program
@@ -147,24 +157,14 @@ static void efar_set_piomode (struct ata
 static void efar_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 {
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
-	u8 master_port		= ap->port_no ? 0x42 : 0x40;
-	u16 master_data;
 	u8 speed		= adev->dma_mode;
 	int devid		= adev->devno + 2 * ap->port_no;
 	u8 udma_enable;
 
-	static const	 /* ISP  RTC */
-	u8 timings[][2]	= { { 0, 0 },
-			    { 0, 0 },
-			    { 1, 0 },
-			    { 2, 1 },
-			    { 2, 3 }, };
-
-	pci_read_config_word(dev, master_port, &master_data);
 	pci_read_config_byte(dev, 0x48, &udma_enable);
 
 	if (speed >= XFER_UDMA_0) {
-		unsigned int udma	= adev->dma_mode - XFER_UDMA_0;
+		unsigned int udma = speed - XFER_UDMA_0;
 		u16 udma_timing;
 
 		udma_enable |= (1 << devid);
@@ -175,46 +175,16 @@ static void efar_set_dmamode (struct ata
 		udma_timing |= udma << (4 * devid);
 		pci_write_config_word(dev, 0x4A, udma_timing);
 	} else {
-		/*
-		 * MWDMA is driven by the PIO timings. We must also enable
-		 * IORDY unconditionally along with TIME1. PPE has already
-		 * been set when the PIO timing was set.
-		 */
-		unsigned int mwdma	= adev->dma_mode - XFER_MW_DMA_0;
-		unsigned int control;
-		u8 slave_data;
+		/* MWDMA is driven by the PIO timings. */
+		unsigned int mwdma = speed - XFER_MW_DMA_0;
 		const unsigned int needed_pio[3] = {
 			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
 		};
 		int pio = needed_pio[mwdma] - XFER_PIO_0;
 
-		control = 3;	/* IORDY|TIME1 */
-
-		/* If the drive MWDMA is faster than it can do PIO then
-		   we must force PIO into PIO0 */
+		efar_set_timings(ap, adev, pio, 1);
 
-		if (adev->pio_mode < needed_pio[mwdma])
-			/* Enable DMA timing only */
-			control |= 8;	/* PIO cycles in PIO0 */
-
-		if (adev->devno) {	/* Slave */
-			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
-			master_data |= control << 4;
-			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= ap->port_no ? 0x0F : 0xF0;
-			/* Load the matching timing */
-			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
-			pci_write_config_byte(dev, 0x44, slave_data);
-		} else { 	/* Master */
-			master_data &= 0xCCF4;	/* Mask out IORDY|TIME1|DMAONLY
-						   and master timing bits */
-			master_data |= control;
-			master_data |=
-				(timings[pio][0] << 12) |
-				(timings[pio][1] << 8);
-		}
 		udma_enable &= ~(1 << devid);
-		pci_write_config_word(dev, master_port, master_data);
 	}
 	pci_write_config_byte(dev, 0x48, udma_enable);
 }

[PATCH 19/86] pata_cmd640: document known issues

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cmd640: document known issues

Document known issues with the driver to aid distribution makers,
users and developers in making informed decisions instead of wasting
their time needlessly.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/Kconfig |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -287,8 +287,11 @@ config PATA_CMD640_PCI
 	depends on PCI && EXPERIMENTAL
 	help
 	  This option enables support for the CMD640 PCI IDE
-	  interface chip. Only the primary channel is currently
-	  supported.
+	  interface chip.
+
+	  Known issues:
+	  - only the primary channel is currently supported
+	  - only the PCI chip interface is currently supported
 
 	  If unsure, say N.
 

[PATCH 20/86] pata_cmd64x: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cmd64x: add 32-bit PIO support

There shouldn't be any problems with it as IDE cmd64x host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cmd64x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -270,7 +270,7 @@ static struct scsi_host_template cmd64x_
 };
 
 static const struct ata_port_operations cmd64x_base_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.set_piomode	= cmd64x_set_piomode,
 	.set_dmamode	= cmd64x_set_dmamode,
 };

[PATCH 21/86] pata_cmd64x: add enablebits checking

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cmd64x: add enablebits checking

There shouldn't be any problems with it as IDE cmd64x host driver
has been supporting enablebits checking for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cmd64x.c |   36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -2,6 +2,7 @@
  * pata_cmd64x.c 	- CMD64x PATA for new ATA layer
  *			  (C) 2005 Red Hat Inc
  *			  Alan Cox <alan@lxorguk.ukuu.org.uk>
+ *			  (C) 2009 Bartlomiej Zolnierkiewicz
  *
  * Based upon
  * linux/drivers/ide/pci/cmd64x.c		Version 1.30	Sept 10, 2002
@@ -88,6 +89,40 @@ static int cmd648_cable_detect(struct at
 }
 
 /**
+ *	cmd64x_prereset	-	perform reset handling
+ *	@link: ATA link
+ *	@deadline: deadline jiffies for the operation
+ *
+ *	Reset sequence checking enable bits to see which ports are
+ *	active.
+ */
+
+static int cmd64x_prereset(struct ata_link *link, unsigned long deadline)
+{
+	static const struct pci_bits cmd64x_enable_bits[] = {
+		{ 0x51, 1, 0x04, 0x04 },
+		{ 0x51, 1, 0x08, 0x08 }
+	};
+
+	struct ata_port *ap = link->ap;
+	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
+
+	/*
+	 * The original PCI0643 and PCI0646 didn't have the primary
+	 * channel enable bit, it appeared starting with PCI0646U
+	 * (i.e. revision ID 3).
+	 */
+	if (pdev->device == PCI_DEVICE_ID_CMD_643 ||
+	    (pdev->device == PCI_DEVICE_ID_CMD_646 && pdev->revision < 3))
+		goto out;
+
+	if (!pci_test_config_bits(pdev, &cmd64x_enable_bits[ap->port_no]))
+		return -ENOENT;
+out:
+	return ata_sff_prereset(link, deadline);
+}
+
+/**
  *	cmd64x_set_piomode	-	set PIO and MWDMA timing
  *	@ap: ATA interface
  *	@adev: ATA device
@@ -278,6 +313,7 @@ static const struct ata_port_operations
 static struct ata_port_operations cmd64x_port_ops = {
 	.inherits	= &cmd64x_base_ops,
 	.cable_detect	= ata_cable_40wire,
+	.prereset	= cmd64x_prereset,
 };
 
 static struct ata_port_operations cmd646r1_port_ops = {

[PATCH 22/86] pata_cmd64x: add cmd64x_fixup()

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cmd64x: add cmd64x_fixup()

Factor out common code from cmd64x_[re]init_one() to cmd64x_fixup().

Remove stale comment and fix CodingStyle issue while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cmd64x.c |   41 +++++++++++++++++++----------------------
 1 file changed, 19 insertions(+), 22 deletions(-)

Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -292,6 +292,22 @@ static struct ata_port_operations cmd648
 	.cable_detect	= cmd648_cable_detect,
 };
 
+static void cmd64x_fixup(struct pci_dev *pdev)
+{
+	u8 mrdmode;
+
+	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 64);
+	pci_read_config_byte(pdev, MRDMODE, &mrdmode);
+	mrdmode &= ~0x30;	/* IRQ set up */
+	mrdmode |= 0x02;	/* Memory read line enable */
+	pci_write_config_byte(pdev, MRDMODE, mrdmode);
+
+	/* PPC specific fixup copied from old driver */
+#ifdef CONFIG_PPC
+	pci_write_config_byte(pdev, UDIDETCR0, 0xF0);
+#endif
+}
+
 static int cmd64x_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	u32 class_rev;
@@ -338,7 +354,6 @@ static int cmd64x_init_one(struct pci_de
 		}
 	};
 	const struct ata_port_info *ppi[] = { &cmd_info[id->driver_data], NULL };
-	u8 mrdmode;
 	int rc;
 
 	rc = pcim_enable_device(pdev);
@@ -360,18 +375,7 @@ static int cmd64x_init_one(struct pci_de
 			ppi[0] = &cmd_info[3];
 	}
 
-	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 64);
-	pci_read_config_byte(pdev, MRDMODE, &mrdmode);
-	mrdmode &= ~ 0x30;	/* IRQ set up */
-	mrdmode |= 0x02;	/* Memory read line enable */
-	pci_write_config_byte(pdev, MRDMODE, mrdmode);
-
-	/* Force PIO 0 here.. */
-
-	/* PPC specific fixup copied from old driver */
-#ifdef CONFIG_PPC
-	pci_write_config_byte(pdev, UDIDETCR0, 0xF0);
-#endif
+	cmd64x_fixup(pdev);
 
 	return ata_pci_sff_init_one(pdev, ppi, &cmd64x_sht, NULL);
 }
@@ -380,21 +384,14 @@ static int cmd64x_init_one(struct pci_de
 static int cmd64x_reinit_one(struct pci_dev *pdev)
 {
 	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	u8 mrdmode;
 	int rc;
 
 	rc = ata_pci_device_do_resume(pdev);
 	if (rc)
 		return rc;
 
-	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 64);
-	pci_read_config_byte(pdev, MRDMODE, &mrdmode);
-	mrdmode &= ~ 0x30;	/* IRQ set up */
-	mrdmode |= 0x02;	/* Memory read line enable */
-	pci_write_config_byte(pdev, MRDMODE, mrdmode);
-#ifdef CONFIG_PPC
-	pci_write_config_byte(pdev, UDIDETCR0, 0xF0);
-#endif
+	cmd64x_fixup(pdev);
+
 	ata_host_resume(host);
 	return 0;
 }

[PATCH 23/86] pata_cs5520: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cs5520: add 32-bit PIO support

There shouldn't be any problems with it as IDE cs5520 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cs5520.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_cs5520.c
===================================================================
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -145,7 +145,7 @@ static struct scsi_host_template cs5520_
 };
 
 static struct ata_port_operations cs5520_port_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.qc_prep		= ata_sff_dumb_qc_prep,
 	.cable_detect		= ata_cable_40wire,
 	.set_piomode		= cs5520_set_piomode,

[PATCH 24/86] pata_cs5520: remove dead VDMA support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cs5520: remove dead VDMA support

It has been dead for the last three years (== since the initial driver
merge) and probability that it will ever get fixed is quite low.

Since there is no reason to keep this dead code around any longer just
remove it (it can still be retrieved from the git history if necessary).

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cs5520.c |   39 +--------------------------------------
 1 file changed, 1 insertion(+), 38 deletions(-)

Index: b/drivers/ata/pata_cs5520.c
===================================================================
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -90,48 +90,12 @@ static void cs5520_set_timings(struct at
 }
 
 /**
- *	cs5520_enable_dma	-	turn on DMA bits
- *
- *	Turn on the DMA bits for this disk. Needed because the BIOS probably
- *	has not done the work for us. Belongs in the core SATA code.
- */
-
-static void cs5520_enable_dma(struct ata_port *ap, struct ata_device *adev)
-{
-	/* Set the DMA enable/disable flag */
-	u8 reg = ioread8(ap->ioaddr.bmdma_addr + 0x02);
-	reg |= 1<<(adev->devno + 5);
-	iowrite8(reg, ap->ioaddr.bmdma_addr + 0x02);
-}
-
-/**
- *	cs5520_set_dmamode	-	program DMA timings
- *	@ap: ATA port
- *	@adev: ATA device
- *
- *	Program the DMA mode timings for the controller according to the pio
- *	clocking table. Note that this device sets the DMA timings to PIO
- *	mode values. This may seem bizarre but the 5520 architecture talks
- *	PIO mode to the disk and DMA mode to the controller so the underlying
- *	transfers are PIO timed.
- */
-
-static void cs5520_set_dmamode(struct ata_port *ap, struct ata_device *adev)
-{
-	static const int dma_xlate[3] = { XFER_PIO_0, XFER_PIO_3, XFER_PIO_4 };
-	cs5520_set_timings(ap, adev, dma_xlate[adev->dma_mode]);
-	cs5520_enable_dma(ap, adev);
-}
-
-/**
  *	cs5520_set_piomode	-	program PIO timings
  *	@ap: ATA port
  *	@adev: ATA device
  *
  *	Program the PIO mode timings for the controller according to the pio
- *	clocking table. We know pio_mode will equal dma_mode because of the
- *	CS5520 architecture. At least once we turned DMA on and wrote a
- *	mode setter.
+ *	clocking table.
  */
 
 static void cs5520_set_piomode(struct ata_port *ap, struct ata_device *adev)
@@ -149,7 +113,6 @@ static struct ata_port_operations cs5520
 	.qc_prep		= ata_sff_dumb_qc_prep,
 	.cable_detect		= ata_cable_40wire,
 	.set_piomode		= cs5520_set_piomode,
-	.set_dmamode		= cs5520_set_dmamode,
 };
 
 static int __devinit cs5520_init_one(struct pci_dev *pdev, const struct pci_device_id *id)

[PATCH 25/86] pata_cs5530: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cs5530: add 32-bit PIO support

There shouldn't be any problems with it as IDE cs5530 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cs5530.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_cs5530.c
===================================================================
--- a/drivers/ata/pata_cs5530.c
+++ b/drivers/ata/pata_cs5530.c
@@ -165,7 +165,7 @@ static struct scsi_host_template cs5530_
 };
 
 static struct ata_port_operations cs5530_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.qc_prep 	= ata_sff_dumb_qc_prep,
 	.qc_issue	= cs5530_qc_issue,

[PATCH 26/86] pata_cs5535: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cs5535: add 32-bit PIO support

There shouldn't be any problems with it as IDE cs5535 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cs5535.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_cs5535.c
===================================================================
--- a/drivers/ata/pata_cs5535.c
+++ b/drivers/ata/pata_cs5535.c
@@ -161,7 +161,7 @@ static struct scsi_host_template cs5535_
 };
 
 static struct ata_port_operations cs5535_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.cable_detect	= cs5535_cable_detect,
 	.set_piomode	= cs5535_set_piomode,
 	.set_dmamode	= cs5535_set_dmamode,

[PATCH 27/86] pata_cs5535: no need to program PIO0 timings during device init

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cs5535: no need to program PIO0 timings during device init

Core libata code takes care of it nowadays.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cs5535.c |   12 ------------
 1 file changed, 12 deletions(-)

Index: b/drivers/ata/pata_cs5535.c
===================================================================
--- a/drivers/ata/pata_cs5535.c
+++ b/drivers/ata/pata_cs5535.c
@@ -67,8 +67,6 @@
 
 #define CS5535_CABLE_DETECT    0x48
 
-#define CS5535_BAD_PIO(timings) ( (timings&~0x80000000UL)==0x00009172 )
-
 /**
  *	cs5535_cable_detect	-	detect cable type
  *	@ap: Port to detect on
@@ -188,16 +186,6 @@ static int cs5535_init_one(struct pci_de
 	};
 	const struct ata_port_info *ppi[] = { &info, &ata_dummy_port_info };
 
-	u32 timings, dummy;
-
-	/* Check the BIOS set the initial timing clock. If not set the
-	   timings for PIO0 */
-	rdmsr(ATAC_CH0D0_PIO, timings, dummy);
-	if (CS5535_BAD_PIO(timings))
-		wrmsr(ATAC_CH0D0_PIO, 0xF7F4F7F4UL, 0);
-	rdmsr(ATAC_CH0D1_PIO, timings, dummy);
-	if (CS5535_BAD_PIO(timings))
-		wrmsr(ATAC_CH0D1_PIO, 0xF7F4F7F4UL, 0);
 	return ata_pci_sff_init_one(dev, ppi, &cs5535_sht, NULL);
 }
 

[PATCH 28/86] pata_cypress: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cypress: add 32-bit PIO support

There shouldn't be any problems with it as IDE cy82c693 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_cypress.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_cypress.c
===================================================================
--- a/drivers/ata/pata_cypress.c
+++ b/drivers/ata/pata_cypress.c
@@ -114,7 +114,7 @@ static struct scsi_host_template cy82c69
 };
 
 static struct ata_port_operations cy82c693_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.cable_detect	= ata_cable_40wire,
 	.set_piomode	= cy82c693_set_piomode,
 	.set_dmamode	= cy82c693_set_dmamode,

[PATCH 29/86] pata_cypress: document known issues

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_cypress: document known issues

Document known issues with the driver to aid distribution makers,
users and developers in making informed decisions instead of wasting
their time needlessly.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -344,6 +344,9 @@ config PATA_CYPRESS
 	  This option enables support for the Cypress/Contaq CY82C693
 	  chipset found in some Alpha systems
 
+	  Known issues:
+	  - only the primary channel is currently supported
+
 	  If unsure, say N.
 
 config PATA_EFAR

[PATCH 30/86] pata_hpt366: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_hpt366: add 32-bit PIO support

There shouldn't be any problems with it as IDE hpt366 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_hpt366.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_hpt366.c
===================================================================
--- a/drivers/ata/pata_hpt366.c
+++ b/drivers/ata/pata_hpt366.c
@@ -283,7 +283,7 @@ static struct scsi_host_template hpt36x_
  */
 
 static struct ata_port_operations hpt366_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.cable_detect	= hpt36x_cable_detect,
 	.mode_filter	= hpt366_filter,
 	.set_piomode	= hpt366_set_piomode,

[PATCH 31/86] pata_hpt37x: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_hpt37x: add 32-bit PIO support

There shouldn't be any problems with it as IDE hpt366 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_hpt37x.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_hpt37x.c
===================================================================
--- a/drivers/ata/pata_hpt37x.c
+++ b/drivers/ata/pata_hpt37x.c
@@ -579,7 +579,7 @@ static struct scsi_host_template hpt37x_
  */
 
 static struct ata_port_operations hpt370_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.bmdma_stop	= hpt370_bmdma_stop,
 
@@ -604,7 +604,7 @@ static struct ata_port_operations hpt370
  */
 
 static struct ata_port_operations hpt372_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.bmdma_stop	= hpt37x_bmdma_stop,
 

[PATCH 32/86] pata_hpt3x2n: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_hpt3x2n: add 32-bit PIO support

There shouldn't be any problems with it as IDE hpt366 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_hpt3x2n.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_hpt3x2n.c
===================================================================
--- a/drivers/ata/pata_hpt3x2n.c
+++ b/drivers/ata/pata_hpt3x2n.c
@@ -335,7 +335,7 @@ static struct scsi_host_template hpt3x2n
  */
 
 static struct ata_port_operations hpt3x2n_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.bmdma_stop	= hpt3x2n_bmdma_stop,
 	.qc_issue	= hpt3x2n_qc_issue,

[PATCH 33/86] pata_hpt3x3: Power Management fix

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_hpt3x3: Power Management fix

Fix ->resume method to re-enable & re-init PCI device properly
before doing chipset specific setup.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_hpt3x3.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Index: b/drivers/ata/pata_hpt3x3.c
===================================================================
--- a/drivers/ata/pata_hpt3x3.c
+++ b/drivers/ata/pata_hpt3x3.c
@@ -255,8 +255,17 @@ static int hpt3x3_init_one(struct pci_de
 #ifdef CONFIG_PM
 static int hpt3x3_reinit_one(struct pci_dev *dev)
 {
+	struct ata_host *host = dev_get_drvdata(&dev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(dev);
+	if (rc)
+		return rc;
+
 	hpt3x3_init_chipset(dev);
-	return ata_pci_device_resume(dev);
+
+	ata_host_resume(host);
+	return 0;
 }
 #endif
 

[PATCH 34/86] pata_it8213: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: add 32-bit PIO support

There shouldn't be any problems with it as IDE it8213 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -235,7 +235,7 @@ static struct scsi_host_template it8213_
 
 
 static struct ata_port_operations it8213_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.cable_detect		= it8213_cable_detect,
 	.set_piomode		= it8213_set_piomode,
 	.set_dmamode		= it8213_set_dmamode,

[PATCH 35/86] pata_it8213: fix UDMA handling

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: fix UDMA handling

Driver should program the cycle timing not the mode number
(doing the latter results in wrong timings being used).

There shouldn't be any problems with it as IDE it8213 host driver
has been doing it this way for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -173,10 +173,10 @@ static void it8213_set_dmamode (struct a
 
 		udma_enable |= (1 << devid);
 
-		/* Load the UDMA mode number */
+		/* Load the UDMA cycle time */
 		pci_read_config_word(dev, 0x4A, &udma_timing);
 		udma_timing &= ~(3 << (4 * devid));
-		udma_timing |= (udma & 3) << (4 * devid);
+		udma_timing |= u_speed << (4 * devid);
 		pci_write_config_word(dev, 0x4A, udma_timing);
 
 		/* Load the clock selection */

[PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: add UDMA100 and UDMA133 support

There shouldn't be any problems with it as IDE it8213 host driver
has been supporting UDMA100 and UDMA133 for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a
 
 		/* Clocks follow the PIIX style */
 		u_speed = min(2 - (udma & 1), udma);
-		if (udma == 5)
+		if (udma > 4)
 			u_clock = 0x1000;	/* 100Mhz */
 		else if (udma > 2)
 			u_clock = 1;		/* 66Mhz */
@@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
 		.mwdma_mask	= ATA_MWDMA2,
-		.udma_mask 	= ATA_UDMA4, /* FIXME: want UDMA 100? */
+		.udma_mask 	= ATA_UDMA6,
 		.port_ops	= &it8213_ops,
 	};
 	/* Current IT8213 stuff is single port */

[PATCH 37/86] pata_it8213: fix wrong PIO timings being programmed

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: fix wrong PIO timings being programmed

* do not clear PIO timings for master when programming slave
* program new PIO timings in the correct register nibble

Both changes should be safe as this is how we have been doing
things in IDE it8213 host driver for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -112,13 +112,13 @@ static void it8213_set_piomode (struct a
 	} else {
 		u8 slave_data;
 
-		idetm_data &= 0xCC0F;
+		idetm_data &= 0xFF0F;
 		idetm_data |= (control << 4);
 
 		/* Slave timing in separate register */
 		pci_read_config_byte(dev, 0x44, &slave_data);
 		slave_data &= 0xF0;
-		slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << 4;
+		slave_data |= (timings[pio][0] << 2) | timings[pio][1];
 		pci_write_config_byte(dev, 0x44, slave_data);
 	}
 

[PATCH 38/86] pata_it8213: fix PIO2 underclocking

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: fix PIO2 underclocking

[ port of Sergei's fixes for pata_efar from commit 5f33b3b ]

Fix the PIO mode 2 using mode 0 timings -- this driver should enable the
fast timing bank starting with PIO2, just like the PIIX/ICH drivers do.
Also, fix/rephrase some comments while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -92,18 +92,17 @@ static void it8213_set_piomode (struct a
 			    { 2, 1 },
 			    { 2, 3 }, };
 
-	if (pio > 2)
-		control |= 1;	/* TIME1 enable */
+	if (pio > 1)
+		control |= 1;	/* TIME */
 	if (ata_pio_need_iordy(adev))	/* PIO 3/4 require IORDY */
-		control |= 2;	/* IORDY enable */
+		control |= 2;	/* IE */
 	/* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */
 	if (adev->class != ATA_DEV_ATA)
-		control |= 4;
+		control |= 4;	/* PPE */
 
 	pci_read_config_word(dev, idetm_port, &idetm_data);
 
-	/* Enable PPE, IE and TIME as appropriate */
-
+	/* Set PPE, IE, and TIME as appropriate */
 	if (adev->devno == 0) {
 		idetm_data &= 0xCCF0;
 		idetm_data |= control;
@@ -122,7 +121,7 @@ static void it8213_set_piomode (struct a
 		pci_write_config_byte(dev, 0x44, slave_data);
 	}
 
-	idetm_data |= 0x4000;	/* Ensure SITRE is enabled */
+	idetm_data |= 0x4000;	/* Ensure SITRE is set */
 	pci_write_config_word(dev, idetm_port, idetm_data);
 }
 

[PATCH 39/86] pata_it8213: fix wrong MWDMA timings being programmed

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: fix wrong MWDMA timings being programmed

Clear old MWDMA timings before programming new ones (IT8213
is a single port host so there is no need to check ap->port_no).

This change should be safe as this is how we have been doing
things in IDE it8213 host driver for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -211,7 +211,7 @@ static void it8213_set_dmamode (struct a
 			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
 			master_data |= control << 4;
 			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= (0x0F + 0xE1 * ap->port_no);
+			slave_data &= 0xF0;
 			/* Load the matching timing */
 			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
 			pci_write_config_byte(dev, 0x44, slave_data);

[PATCH 40/86] pata_it8213: fix register naming used in it8213_set_piomode()

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: fix register naming used in it8213_set_piomode()

Rename 'idetm_port' and 'idetm_data' variables to 'master_port'
and 'master_data' respectively to match register naming used in
it8213_set_dma_mode() and in ata_piix.c.

Fix 'master_port' type while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -76,8 +76,8 @@ static void it8213_set_piomode (struct a
 {
 	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
-	unsigned int idetm_port= ap->port_no ? 0x42 : 0x40;
-	u16 idetm_data;
+	u8 master_port		= ap->port_no ? 0x42 : 0x40;
+	u16 master_data;
 	int control = 0;
 
 	/*
@@ -100,19 +100,19 @@ static void it8213_set_piomode (struct a
 	if (adev->class != ATA_DEV_ATA)
 		control |= 4;	/* PPE */
 
-	pci_read_config_word(dev, idetm_port, &idetm_data);
+	pci_read_config_word(dev, master_port, &master_data);
 
 	/* Set PPE, IE, and TIME as appropriate */
 	if (adev->devno == 0) {
-		idetm_data &= 0xCCF0;
-		idetm_data |= control;
-		idetm_data |= (timings[pio][0] << 12) |
+		master_data &= 0xCCF0;
+		master_data |= control;
+		master_data |= (timings[pio][0] << 12) |
 			(timings[pio][1] << 8);
 	} else {
 		u8 slave_data;
 
-		idetm_data &= 0xFF0F;
-		idetm_data |= (control << 4);
+		master_data &= 0xFF0F;
+		master_data |= (control << 4);
 
 		/* Slave timing in separate register */
 		pci_read_config_byte(dev, 0x44, &slave_data);
@@ -121,8 +121,8 @@ static void it8213_set_piomode (struct a
 		pci_write_config_byte(dev, 0x44, slave_data);
 	}
 
-	idetm_data |= 0x4000;	/* Ensure SITRE is set */
-	pci_write_config_word(dev, idetm_port, idetm_data);
+	master_data |= 0x4000;	/* Ensure SITRE is set */
+	pci_write_config_word(dev, master_port, master_data);
 }
 
 /**

[PATCH 41/86] pata_efar: unify code for programming PIO and MWDMA timings

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: unify code for programming PIO and MWDMA timings

It results in ~9% decrease in the driver LOC count and also ~6%
decrease in the driver binary size (as measured on x86-32).

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |   87 +++++++++++++++-------------------------------
 1 file changed, 29 insertions(+), 58 deletions(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -61,20 +61,9 @@ static int it8213_cable_detect(struct at
 	return ATA_CBL_PATA80;
 }
 
-/**
- *	it8213_set_piomode - Initialize host controller PATA PIO timings
- *	@ap: Port whose timings we are configuring
- *	@adev: Device whose timings we are configuring
- *
- *	Set PIO mode for device, in host controller PCI config space.
- *
- *	LOCKING:
- *	None (inherited from caller).
- */
-
-static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev)
+static void it8213_set_timings(struct ata_port *ap, struct ata_device *adev,
+			       u8 pio, bool use_mwdma)
 {
-	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	u8 master_port		= ap->port_no ? 0x42 : 0x40;
 	u16 master_data;
@@ -92,13 +81,18 @@ static void it8213_set_piomode (struct a
 			    { 2, 1 },
 			    { 2, 3 }, };
 
-	if (pio > 1)
+	if (pio > 1 || use_mwdma)
 		control |= 1;	/* TIME */
-	if (ata_pio_need_iordy(adev))	/* PIO 3/4 require IORDY */
+	if (ata_pio_need_iordy(adev) || use_mwdma)
 		control |= 2;	/* IE */
 	/* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */
 	if (adev->class != ATA_DEV_ATA)
 		control |= 4;	/* PPE */
+	/* If the drive MWDMA is faster than it can do PIO then
+	   we must force PIO into PIO0 */
+	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
+		/* Enable DMA timing only */
+		control |= 8;	/* PIO cycles in PIO0 */
 
 	pci_read_config_word(dev, master_port, &master_data);
 
@@ -127,6 +121,22 @@ static void it8213_set_piomode (struct a
 }
 
 /**
+ *	it8213_set_piomode - Initialize host controller PATA PIO timings
+ *	@ap: Port whose timings we are configuring
+ *	@adev: Device whose timings we are configuring
+ *
+ *	Set PIO mode for device, in host controller PCI config space.
+ *
+ *	LOCKING:
+ *	None (inherited from caller).
+ */
+
+static void it8213_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+	it8213_set_timings(ap, adev, adev->pio_mode - XFER_PIO_0, 0);
+}
+
+/**
  *	it8213_set_dmamode - Initialize host controller PATA DMA timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device to program
@@ -141,23 +151,14 @@ static void it8213_set_piomode (struct a
 static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 {
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
-	u16 master_data;
 	u8 speed		= adev->dma_mode;
 	int devid		= adev->devno;
 	u8 udma_enable;
 
-	static const	 /* ISP  RTC */
-	u8 timings[][2]	= { { 0, 0 },
-			    { 0, 0 },
-			    { 1, 0 },
-			    { 2, 1 },
-			    { 2, 3 }, };
-
-	pci_read_config_word(dev, 0x40, &master_data);
 	pci_read_config_byte(dev, 0x48, &udma_enable);
 
 	if (speed >= XFER_UDMA_0) {
-		unsigned int udma = adev->dma_mode - XFER_UDMA_0;
+		unsigned int udma = speed - XFER_UDMA_0;
 		u16 udma_timing;
 		u16 ideconf;
 		int u_clock, u_speed;
@@ -185,46 +186,16 @@ static void it8213_set_dmamode (struct a
 		ideconf |= u_clock << devid;
 		pci_write_config_word(dev, 0x54, ideconf);
 	} else {
-		/*
-		 * MWDMA is driven by the PIO timings. We must also enable
-		 * IORDY unconditionally along with TIME1. PPE has already
-		 * been set when the PIO timing was set.
-		 */
-		unsigned int mwdma	= adev->dma_mode - XFER_MW_DMA_0;
-		unsigned int control;
-		u8 slave_data;
+		/* MWDMA is driven by the PIO timings. */
+		unsigned int mwdma = speed - XFER_MW_DMA_0;
 		static const unsigned int needed_pio[3] = {
 			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
 		};
 		int pio = needed_pio[mwdma] - XFER_PIO_0;
 
-		control = 3;	/* IORDY|TIME1 */
-
-		/* If the drive MWDMA is faster than it can do PIO then
-		   we must force PIO into PIO0 */
+		it8213_set_timings(ap, adev, pio, 1);
 
-		if (adev->pio_mode < needed_pio[mwdma])
-			/* Enable DMA timing only */
-			control |= 8;	/* PIO cycles in PIO0 */
-
-		if (devid) {	/* Slave */
-			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
-			master_data |= control << 4;
-			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= 0xF0;
-			/* Load the matching timing */
-			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
-			pci_write_config_byte(dev, 0x44, slave_data);
-		} else { 	/* Master */
-			master_data &= 0xCCF4;	/* Mask out IORDY|TIME1|DMAONLY
-						   and master timing bits */
-			master_data |= control;
-			master_data |=
-				(timings[pio][0] << 12) |
-				(timings[pio][1] << 8);
-		}
 		udma_enable &= ~(1 << devid);
-		pci_write_config_word(dev, 0x40, master_data);
 	}
 	pci_write_config_byte(dev, 0x48, udma_enable);
 }

[PATCH 42/86] pata_it8213: fix it8213_pre_reset() documentation

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it8213: fix it8213_pre_reset() documentation

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it8213.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -22,7 +22,7 @@
 #define DRV_VERSION	"0.0.3"
 
 /**
- *	it8213_pre_reset	-	check for 40/80 pin
+ *	it8213_pre_reset	-	probe begin
  *	@link: link
  *	@deadline: deadline jiffies for the operation
  *

[PATCH 43/86] pata_it821x: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_it821x: add 32-bit PIO support

There shouldn't be any problems with it as IDE it821x host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_it821x.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: b/drivers/ata/pata_it821x.c
===================================================================
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -738,7 +738,7 @@ static int it821x_port_start(struct ata_
 	struct it821x_dev *itdev;
 	u8 conf;
 
-	int ret = ata_sff_port_start(ap);
+	int ret = ata_sff_port_start32(ap);
 	if (ret < 0)
 		return ret;
 
@@ -801,7 +801,7 @@ static struct scsi_host_template it821x_
 };
 
 static struct ata_port_operations it821x_smart_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.check_atapi_dma= it821x_check_atapi_dma,
 	.qc_issue	= it821x_smart_qc_issue,
@@ -815,7 +815,7 @@ static struct ata_port_operations it821x
 };
 
 static struct ata_port_operations it821x_passthru_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.check_atapi_dma= it821x_check_atapi_dma,
 	.sff_dev_select	= it821x_passthru_dev_select,
@@ -831,7 +831,7 @@ static struct ata_port_operations it821x
 };
 
 static struct ata_port_operations it821x_rdc_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 
 	.check_atapi_dma= it821x_check_atapi_dma,
 	.sff_dev_select	= it821x_passthru_dev_select,

[PATCH 44/86] pata_jmicron: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_jmicron: add 32-bit PIO support

There shouldn't be any problems with it as IDE jmicron host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_jmicron.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_jmicron.c
===================================================================
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -112,7 +112,7 @@ static struct scsi_host_template jmicron
 };
 
 static struct ata_port_operations jmicron_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.prereset		= jmicron_pre_reset,
 };
 

[PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_legacy: do not probe extra ports automatically if PCI is not present

It can be problematic if there are other ISA/VLB devices using
those ports.

This is a forward port of bugfix from IDE ide-generic host driver.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_legacy.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -1241,7 +1241,7 @@ static __init int legacy_init(void)
 	if (secondary == 0 || all)
 		legacy_probe_add(0x170, 15, UNKNOWN, 0);
 
-	if (probe_all || !pci_present) {
+	if (probe_all) {
 		/* ISA/VLB extra ports */
 		legacy_probe_add(0x1E8, 11, UNKNOWN, 0);
 		legacy_probe_add(0x168, 10, UNKNOWN, 0);

[PATCH 46/86] pata_legacy: fix QDI6580DP support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_legacy: fix QDI6580DP support

Dual port QDI6580 has shared PIO timings for master/slave
devices so it needs to use custom ->qc_issue method.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_legacy.c |    1 +
 1 file changed, 1 insertion(+)

Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -787,6 +787,7 @@ static struct ata_port_operations qdi658
 static struct ata_port_operations qdi6580dp_port_ops = {
 	.inherits	= &legacy_base_port_ops,
 	.set_piomode	= qdi6580dp_set_piomode,
+	.qc_issue	= qdi_qc_issue,
 	.sff_data_xfer	= vlb32_data_xfer,
 };
 

[PATCH 47/86] pata_legacy: fix access to control register for QDI6580

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_legacy: fix access to control register for QDI6580

We need to mask out the port offset from the port number
cached in ld_qdi->timing.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_legacy.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -672,7 +672,7 @@ static void qdi6580dp_set_piomode(struct
 	outb(timing, ld_qdi->timing + 2 * ap->port_no);
 	/* Clear the FIFO */
 	if (adev->class != ATA_DEV_ATA)
-		outb(0x5F, ld_qdi->timing + 3);
+		outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
 }
 
 /**
@@ -707,7 +707,7 @@ static void qdi6580_set_piomode(struct a
 	outb(timing, ld_qdi->timing + 2 * adev->devno);
 	/* Clear the FIFO */
 	if (adev->class != ATA_DEV_ATA)
-		outb(0x5F, ld_qdi->timing + 3);
+		outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
 }
 
 /**

[PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_legacy: add pointers to QDI65x0 documentation

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_legacy.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -25,6 +25,13 @@
  *		http://www.ryston.cz/petr/vlb/pdc20230b.html
  *		http://www.ryston.cz/petr/vlb/pdc20230c.html
  *		http://www.ryston.cz/petr/vlb/pdc20630.html
+ *	QDI65x0:
+ *		http://www.ryston.cz/petr/vlb/qd6500.html
+ *		http://www.ryston.cz/petr/vlb/qd6580.html
+ *
+ *	QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c
+ *	Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by
+ *	Samuel Thibault <samuel.thibault@ens-lyon.org>
  *
  *  Unsupported but docs exist:
  *	Appian/Adaptec AIC25VL01/Cirrus Logic PD7220
@@ -35,7 +42,7 @@
  *  the MPIIX where the tuning is PCI side but the IDE is "ISA side".
  *
  *  Specific support is included for the ht6560a/ht6560b/opti82c611a/
- *  opti82c465mv/promise 20230c/20630/winbond83759A
+ *  opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A
  *
  *  Use the autospeed and pio_mask options with:
  *	Appian ADI/2 aka CLPD7220 or AIC25VL01.

[PATCH 49/86] pata_legacy: unify QDI ->set_piomode methods

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_legacy: unify QDI ->set_piomode methods

Add controller type field to struct legacy_data and then use it
to merge together all ->set_piomode methods for QDI controllers.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_legacy.c |   98 ++++++++++------------------------------------
 1 file changed, 23 insertions(+), 75 deletions(-)

Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -76,15 +76,6 @@ static int all;
 module_param(all, int, 0444);
 MODULE_PARM_DESC(all, "Grab all legacy port devices, even if PCI(0=off, 1=on)");
 
-struct legacy_data {
-	unsigned long timing;
-	u8 clock[2];
-	u8 last;
-	int fast;
-	struct platform_device *platform_dev;
-
-};
-
 enum controller {
 	BIOS = 0,
 	SNOOP = 1,
@@ -101,6 +92,14 @@ enum controller {
 	UNKNOWN = -1
 };
 
+struct legacy_data {
+	unsigned long timing;
+	u8 clock[2];
+	u8 last;
+	int fast;
+	enum controller type;
+	struct platform_device *platform_dev;
+};
 
 struct legacy_probe {
 	unsigned char *name;
@@ -622,40 +621,20 @@ static struct ata_port_operations opti82
 	.qc_issue	= opti82c46x_qc_issue,
 };
 
-static void qdi6500_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
-	struct ata_timing t;
-	struct legacy_data *ld_qdi = ap->host->private_data;
-	int active, recovery;
-	u8 timing;
-
-	/* Get the timing data in cycles */
-	ata_timing_compute(adev, adev->pio_mode, &t, 30303, 1000);
-
-	if (ld_qdi->fast) {
-		active = 8 - clamp_val(t.active, 1, 8);
-		recovery = 18 - clamp_val(t.recover, 3, 18);
-	} else {
-		active = 9 - clamp_val(t.active, 2, 9);
-		recovery = 15 - clamp_val(t.recover, 0, 15);
-	}
-	timing = (recovery << 4) | active | 0x08;
-
-	ld_qdi->clock[adev->devno] = timing;
-
-	outb(timing, ld_qdi->timing);
-}
-
 /**
- *	qdi6580dp_set_piomode		-	PIO setup for dual channel
+ *	qdi65x0_set_piomode		-	PIO setup for QDI65x0
  *	@ap: Port
  *	@adev: Device
  *
+ *	In single channel mode the 6580 has one clock per device and we can
+ *	avoid the requirement to clock switch. We also have to load the timing
+ *	into the right clock according to whether we are master or slave.
+ *
  *	In dual channel mode the 6580 has one clock per channel and we have
  *	to software clockswitch in qc_issue.
  */
 
-static void qdi6580dp_set_piomode(struct ata_port *ap, struct ata_device *adev)
+static void qdi65x0_set_piomode(struct ata_port *ap, struct ata_device *adev)
 {
 	struct ata_timing t;
 	struct legacy_data *ld_qdi = ap->host->private_data;
@@ -673,47 +652,15 @@ static void qdi6580dp_set_piomode(struct
 		recovery = 15 - clamp_val(t.recover, 0, 15);
 	}
 	timing = (recovery << 4) | active | 0x08;
-
 	ld_qdi->clock[adev->devno] = timing;
 
-	outb(timing, ld_qdi->timing + 2 * ap->port_no);
-	/* Clear the FIFO */
-	if (adev->class != ATA_DEV_ATA)
-		outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
-}
-
-/**
- *	qdi6580_set_piomode		-	PIO setup for single channel
- *	@ap: Port
- *	@adev: Device
- *
- *	In single channel mode the 6580 has one clock per device and we can
- *	avoid the requirement to clock switch. We also have to load the timing
- *	into the right clock according to whether we are master or slave.
- */
-
-static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
-	struct ata_timing t;
-	struct legacy_data *ld_qdi = ap->host->private_data;
-	int active, recovery;
-	u8 timing;
-
-	/* Get the timing data in cycles */
-	ata_timing_compute(adev, adev->pio_mode, &t, 30303, 1000);
+	if (ld_qdi->type == QDI6580)
+		outb(timing, ld_qdi->timing + 2 * adev->devno);
+	else
+		outb(timing, ld_qdi->timing + 2 * ap->port_no);
 
-	if (ld_qdi->fast) {
-		active = 8 - clamp_val(t.active, 1, 8);
-		recovery = 18 - clamp_val(t.recover, 3, 18);
-	} else {
-		active = 9 - clamp_val(t.active, 2, 9);
-		recovery = 15 - clamp_val(t.recover, 0, 15);
-	}
-	timing = (recovery << 4) | active | 0x08;
-	ld_qdi->clock[adev->devno] = timing;
-	outb(timing, ld_qdi->timing + 2 * adev->devno);
 	/* Clear the FIFO */
-	if (adev->class != ATA_DEV_ATA)
+	if (ld_qdi->type != QDI6500 && adev->class != ATA_DEV_ATA)
 		outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
 }
 
@@ -780,20 +727,20 @@ static int qdi_port(struct platform_devi
 
 static struct ata_port_operations qdi6500_port_ops = {
 	.inherits	= &legacy_base_port_ops,
-	.set_piomode	= qdi6500_set_piomode,
+	.set_piomode	= qdi65x0_set_piomode,
 	.qc_issue	= qdi_qc_issue,
 	.sff_data_xfer	= vlb32_data_xfer,
 };
 
 static struct ata_port_operations qdi6580_port_ops = {
 	.inherits	= &legacy_base_port_ops,
-	.set_piomode	= qdi6580_set_piomode,
+	.set_piomode	= qdi65x0_set_piomode,
 	.sff_data_xfer	= vlb32_data_xfer,
 };
 
 static struct ata_port_operations qdi6580dp_port_ops = {
 	.inherits	= &legacy_base_port_ops,
-	.set_piomode	= qdi6580dp_set_piomode,
+	.set_piomode	= qdi65x0_set_piomode,
 	.qc_issue	= qdi_qc_issue,
 	.sff_data_xfer	= vlb32_data_xfer,
 };
@@ -1013,6 +960,7 @@ static __init int legacy_init_one(struct
 	ctrl_addr = devm_ioport_map(&pdev->dev, io + 0x0206, 1);
 	if (!io_addr || !ctrl_addr)
 		goto fail;
+	ld->type = probe->type;
 	if (controller->setup)
 		if (controller->setup(pdev, probe, ld) < 0)
 			goto fail;

[PATCH 50/86] pata_legacy: use PIO mask defines

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_legacy: use PIO mask defines

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_legacy.c |   22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -817,29 +817,29 @@ static struct ata_port_operations winbon
 };
 
 static struct legacy_controller controllers[] = {
-	{"BIOS",	&legacy_port_ops, 	0x1F,
+	{"BIOS",	&legacy_port_ops, 	ATA_PIO4,
 			ATA_FLAG_NO_IORDY,	0,			NULL },
-	{"Snooping", 	&simple_port_ops, 	0x1F,
+	{"Snooping", 	&simple_port_ops, 	ATA_PIO4,
 			0,			0,			NULL },
-	{"PDC20230",	&pdc20230_port_ops,	0x7,
+	{"PDC20230",	&pdc20230_port_ops,	ATA_PIO2,
 			ATA_FLAG_NO_IORDY,
 			ATA_PFLAG_PIO32 | ATA_PFLAG_PIO32CHANGE,	NULL },
-	{"HT6560A",	&ht6560a_port_ops,	0x07,
+	{"HT6560A",	&ht6560a_port_ops,	ATA_PIO2,
 			ATA_FLAG_NO_IORDY,	0,			NULL },
-	{"HT6560B",	&ht6560b_port_ops,	0x1F,
+	{"HT6560B",	&ht6560b_port_ops,	ATA_PIO4,
 			ATA_FLAG_NO_IORDY,	0,			NULL },
-	{"OPTI82C611A",	&opti82c611a_port_ops,	0x0F,
+	{"OPTI82C611A",	&opti82c611a_port_ops,	ATA_PIO3,
 			0,			0,			NULL },
-	{"OPTI82C46X",	&opti82c46x_port_ops,	0x0F,
+	{"OPTI82C46X",	&opti82c46x_port_ops,	ATA_PIO3,
 			0,			0,			NULL },
-	{"QDI6500",	&qdi6500_port_ops,	0x07,
+	{"QDI6500",	&qdi6500_port_ops,	ATA_PIO2,
 			ATA_FLAG_NO_IORDY,
 			ATA_PFLAG_PIO32 | ATA_PFLAG_PIO32CHANGE,    qdi_port },
-	{"QDI6580",	&qdi6580_port_ops,	0x1F,
+	{"QDI6580",	&qdi6580_port_ops,	ATA_PIO4,
 			0, ATA_PFLAG_PIO32 | ATA_PFLAG_PIO32CHANGE, qdi_port },
-	{"QDI6580DP",	&qdi6580dp_port_ops,	0x1F,
+	{"QDI6580DP",	&qdi6580dp_port_ops,	ATA_PIO4,
 			0, ATA_PFLAG_PIO32 | ATA_PFLAG_PIO32CHANGE, qdi_port },
-	{"W83759A",	&winbond_port_ops,	0x1F,
+	{"W83759A",	&winbond_port_ops,	ATA_PIO4,
 			0, ATA_PFLAG_PIO32 | ATA_PFLAG_PIO32CHANGE,
 								winbond_port }
 };

[PATCH 51/86] libata: remove no longer needed pata_qdi driver

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] libata: remove no longer needed pata_qdi driver

QDI65x0 controllers are fully supported by pata_legacy driver
so remove no longer needed pata_qdi driver.

Leave PATA_QDI config option for compatibility reasons and teach
pata_legacy to preserve the old behavior of pata_qdi driver.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/Kconfig       |    1 
 drivers/ata/Makefile      |    1 
 drivers/ata/pata_legacy.c |    9 +
 drivers/ata/pata_qdi.c    |  366 ----------------------------------------------
 4 files changed, 9 insertions(+), 368 deletions(-)

Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -591,6 +591,7 @@ config PATA_PDC_OLD
 config PATA_QDI
 	tristate "QDI VLB PATA support"
 	depends on ISA
+	select PATA_LEGACY
 	help
 	  Support for QDI 6500 and 6580 PATA controllers on VESA local bus.
 
Index: b/drivers/ata/Makefile
===================================================================
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_PATA_PALMLD)	+= pata_palmld
 obj-$(CONFIG_PATA_PCMCIA)	+= pata_pcmcia.o
 obj-$(CONFIG_PATA_PDC2027X)	+= pata_pdc2027x.o
 obj-$(CONFIG_PATA_PDC_OLD)	+= pata_pdc202xx_old.o
-obj-$(CONFIG_PATA_QDI)		+= pata_qdi.o
 obj-$(CONFIG_PATA_RADISYS)	+= pata_radisys.o
 obj-$(CONFIG_PATA_RB532)	+= pata_rb532_cf.o
 obj-$(CONFIG_PATA_RDC)		+= pata_rdc.o
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -133,7 +133,12 @@ static int ht6560a;		/* HT 6560A on prim
 static int ht6560b;		/* HT 6560A on primary 1, second 2, both 3 */
 static int opti82c611a;		/* Opti82c611A on primary 1, sec 2, both 3 */
 static int opti82c46x;		/* Opti 82c465MV present(pri/sec autodetect) */
-static int qdi;			/* Set to probe QDI controllers */
+/* Set to probe QDI controllers */
+#ifdef PATA_QDI_MODULE
+static int qdi = 1;
+#else
+static int qdi;
+#endif
 static int winbond;		/* Set to probe Winbond controllers,
 					give I/O port if non standard */
 static int autospeed;		/* Chip present which snoops speed changes */
@@ -1245,6 +1250,7 @@ MODULE_AUTHOR("Alan Cox");
 MODULE_DESCRIPTION("low-level driver for legacy ATA");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(DRV_VERSION);
+MODULE_ALIAS("pata_qdi");
 
 module_param(probe_all, int, 0);
 module_param(autospeed, int, 0);
@@ -1253,6 +1259,7 @@ module_param(ht6560b, int, 0);
 module_param(opti82c611a, int, 0);
 module_param(opti82c46x, int, 0);
 module_param(qdi, int, 0);
+module_param_named(probe_qdi, qdi, int, 0);
 module_param(pio_mask, int, 0);
 module_param(iordy_mask, int, 0);
 
Index: b/drivers/ata/pata_qdi.c
===================================================================
--- a/drivers/ata/pata_qdi.c
+++ /dev/null
@@ -1,366 +0,0 @@
-/*
- *    pata_qdi.c - QDI VLB ATA controllers
- *	(C) 2006 Red Hat
- *
- * This driver mostly exists as a proof of concept for non PCI devices under
- * libata. While the QDI6580 was 'neat' in 1993 it is no longer terribly
- * useful.
- *
- * Tuning code written from the documentation at
- * http://www.ryston.cz/petr/vlb/qd6500.html
- * http://www.ryston.cz/petr/vlb/qd6580.html
- *
- * Probe code based on drivers/ide/legacy/qd65xx.c
- * Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by
- * Samuel Thibault <samuel.thibault@ens-lyon.org>
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/pci.h>
-#include <linux/init.h>
-#include <linux/blkdev.h>
-#include <linux/delay.h>
-#include <scsi/scsi_host.h>
-#include <linux/libata.h>
-#include <linux/platform_device.h>
-
-#define DRV_NAME "pata_qdi"
-#define DRV_VERSION "0.3.1"
-
-#define NR_HOST 4	/* Two 6580s */
-
-struct qdi_data {
-	unsigned long timing;
-	u8 clock[2];
-	u8 last;
-	int fast;
-	struct platform_device *platform_dev;
-
-};
-
-static struct ata_host *qdi_host[NR_HOST];
-static struct qdi_data qdi_data[NR_HOST];
-static int nr_qdi_host;
-
-#ifdef MODULE
-static int probe_qdi = 1;
-#else
-static int probe_qdi;
-#endif
-
-static void qdi6500_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
-	struct ata_timing t;
-	struct qdi_data *qdi = ap->host->private_data;
-	int active, recovery;
-	u8 timing;
-
-	/* Get the timing data in cycles */
-	ata_timing_compute(adev, adev->pio_mode, &t, 30303, 1000);
-
-	if (qdi->fast) {
-		active = 8 - clamp_val(t.active, 1, 8);
-		recovery = 18 - clamp_val(t.recover, 3, 18);
-	} else {
-		active = 9 - clamp_val(t.active, 2, 9);
-		recovery = 15 - clamp_val(t.recover, 0, 15);
-	}
-	timing = (recovery << 4) | active | 0x08;
-
-	qdi->clock[adev->devno] = timing;
-
-	outb(timing, qdi->timing);
-}
-
-static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
-	struct ata_timing t;
-	struct qdi_data *qdi = ap->host->private_data;
-	int active, recovery;
-	u8 timing;
-
-	/* Get the timing data in cycles */
-	ata_timing_compute(adev, adev->pio_mode, &t, 30303, 1000);
-
-	if (qdi->fast) {
-		active = 8 - clamp_val(t.active, 1, 8);
-		recovery = 18 - clamp_val(t.recover, 3, 18);
-	} else {
-		active = 9 - clamp_val(t.active, 2, 9);
-		recovery = 15 - clamp_val(t.recover, 0, 15);
-	}
-	timing = (recovery << 4) | active | 0x08;
-
-	qdi->clock[adev->devno] = timing;
-
-	outb(timing, qdi->timing);
-
-	/* Clear the FIFO */
-	if (adev->class != ATA_DEV_ATA)
-		outb(0x5F, (qdi->timing & 0xFFF0) + 3);
-}
-
-/**
- *	qdi_qc_issue		-	command issue
- *	@qc: command pending
- *
- *	Called when the libata layer is about to issue a command. We wrap
- *	this interface so that we can load the correct ATA timings.
- */
-
-static unsigned int qdi_qc_issue(struct ata_queued_cmd *qc)
-{
-	struct ata_port *ap = qc->ap;
-	struct ata_device *adev = qc->dev;
-	struct qdi_data *qdi = ap->host->private_data;
-
-	if (qdi->clock[adev->devno] != qdi->last) {
-		if (adev->pio_mode) {
-			qdi->last = qdi->clock[adev->devno];
-			outb(qdi->clock[adev->devno], qdi->timing);
-		}
-	}
-	return ata_sff_qc_issue(qc);
-}
-
-static unsigned int qdi_data_xfer(struct ata_device *dev, unsigned char *buf,
-				  unsigned int buflen, int rw)
-{
-	if (ata_id_has_dword_io(dev->id)) {
-		struct ata_port *ap = dev->link->ap;
-		int slop = buflen & 3;
-
-		if (rw == READ)
-			ioread32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
-		else
-			iowrite32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
-
-		if (unlikely(slop)) {
-			__le32 pad;
-			if (rw == READ) {
-				pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
-				memcpy(buf + buflen - slop, &pad, slop);
-			} else {
-				memcpy(&pad, buf + buflen - slop, slop);
-				iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
-			}
-			buflen += 4 - slop;
-		}
-	} else
-		buflen = ata_sff_data_xfer(dev, buf, buflen, rw);
-
-	return buflen;
-}
-
-static struct scsi_host_template qdi_sht = {
-	ATA_PIO_SHT(DRV_NAME),
-};
-
-static struct ata_port_operations qdi6500_port_ops = {
-	.inherits	= &ata_sff_port_ops,
-	.qc_issue	= qdi_qc_issue,
-	.sff_data_xfer	= qdi_data_xfer,
-	.cable_detect	= ata_cable_40wire,
-	.set_piomode	= qdi6500_set_piomode,
-};
-
-static struct ata_port_operations qdi6580_port_ops = {
-	.inherits	= &qdi6500_port_ops,
-	.set_piomode	= qdi6580_set_piomode,
-};
-
-/**
- *	qdi_init_one		-	attach a qdi interface
- *	@type: Type to display
- *	@io: I/O port start
- *	@irq: interrupt line
- *	@fast: True if on a > 33Mhz VLB
- *
- *	Register an ISA bus IDE interface. Such interfaces are PIO and we
- *	assume do not support IRQ sharing.
- */
-
-static __init int qdi_init_one(unsigned long port, int type, unsigned long io, int irq, int fast)
-{
-	unsigned long ctl = io + 0x206;
-	struct platform_device *pdev;
-	struct ata_host *host;
-	struct ata_port *ap;
-	void __iomem *io_addr, *ctl_addr;
-	int ret;
-
-	/*
-	 *	Fill in a probe structure first of all
-	 */
-
-	pdev = platform_device_register_simple(DRV_NAME, nr_qdi_host, NULL, 0);
-	if (IS_ERR(pdev))
-		return PTR_ERR(pdev);
-
-	ret = -ENOMEM;
-	io_addr = devm_ioport_map(&pdev->dev, io, 8);
-	ctl_addr = devm_ioport_map(&pdev->dev, ctl, 1);
-	if (!io_addr || !ctl_addr)
-		goto fail;
-
-	ret = -ENOMEM;
-	host = ata_host_alloc(&pdev->dev, 1);
-	if (!host)
-		goto fail;
-	ap = host->ports[0];
-
-	if (type == 6580) {
-		ap->ops = &qdi6580_port_ops;
-		ap->pio_mask = ATA_PIO4;
-		ap->flags |= ATA_FLAG_SLAVE_POSS;
-	} else {
-		ap->ops = &qdi6500_port_ops;
-		ap->pio_mask = ATA_PIO2; /* Actually PIO3 !IORDY is possible */
-		ap->flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_NO_IORDY;
-	}
-
-	ap->ioaddr.cmd_addr = io_addr;
-	ap->ioaddr.altstatus_addr = ctl_addr;
-	ap->ioaddr.ctl_addr = ctl_addr;
-	ata_sff_std_ports(&ap->ioaddr);
-
-	ata_port_desc(ap, "cmd %lx ctl %lx", io, ctl);
-
-	/*
-	 *	Hook in a private data structure per channel
-	 */
-	ap->private_data = &qdi_data[nr_qdi_host];
-
-	qdi_data[nr_qdi_host].timing = port;
-	qdi_data[nr_qdi_host].fast = fast;
-	qdi_data[nr_qdi_host].platform_dev = pdev;
-
-	printk(KERN_INFO DRV_NAME": qd%d at 0x%lx.\n", type, io);
-
-	/* activate */
-	ret = ata_host_activate(host, irq, ata_sff_interrupt, 0, &qdi_sht);
-	if (ret)
-		goto fail;
-
-	qdi_host[nr_qdi_host++] = dev_get_drvdata(&pdev->dev);
-	return 0;
-
- fail:
-	platform_device_unregister(pdev);
-	return ret;
-}
-
-/**
- *	qdi_init		-	attach qdi interfaces
- *
- *	Attach qdi IDE interfaces by scanning the ports it may occupy.
- */
-
-static __init int qdi_init(void)
-{
-	unsigned long flags;
-	static const unsigned long qd_port[2] = { 0x30, 0xB0 };
-	static const unsigned long ide_port[2] = { 0x170, 0x1F0 };
-	static const int ide_irq[2] = { 14, 15 };
-
-	int ct = 0;
-	int i;
-
-	if (probe_qdi == 0)
-		return -ENODEV;
-
-	/*
- 	 *	Check each possible QD65xx base address
-	 */
-
-	for (i = 0; i < 2; i++) {
-		unsigned long port = qd_port[i];
-		u8 r, res;
-
-
-		if (request_region(port, 2, "pata_qdi")) {
-			/* Check for a card */
-			local_irq_save(flags);
-			r = inb_p(port);
-			outb_p(0x19, port);
-			res = inb_p(port);
-			outb_p(r, port);
-			local_irq_restore(flags);
-
-			/* Fail */
-			if (res == 0x19)
-			{
-				release_region(port, 2);
-				continue;
-			}
-
-			/* Passes the presence test */
-			r = inb_p(port + 1);	/* Check port agrees with port set */
-			if ((r & 2) >> 1 != i) {
-				release_region(port, 2);
-				continue;
-			}
-
-			/* Check card type */
-			if ((r & 0xF0) == 0xC0) {
-				/* QD6500: single channel */
-				if (r & 8) {
-					/* Disabled ? */
-					release_region(port, 2);
-					continue;
-				}
-				if (qdi_init_one(port, 6500, ide_port[r & 0x01], ide_irq[r & 0x01], r & 0x04) == 0)
-					ct++;
-			}
-			if (((r & 0xF0) == 0xA0) || (r & 0xF0) == 0x50) {
-				/* QD6580: dual channel */
-				if (!request_region(port + 2 , 2, "pata_qdi"))
-				{
-					release_region(port, 2);
-					continue;
-				}
-				res = inb(port + 3);
-				if (res & 1) {
-					/* Single channel mode */
-					if (qdi_init_one(port, 6580, ide_port[r & 0x01], ide_irq[r & 0x01], r & 0x04) == 0)
-						ct++;
-				} else {
-					/* Dual channel mode */
-					if (qdi_init_one(port, 6580, 0x1F0, 14, r & 0x04) == 0)
-						ct++;
-					if (qdi_init_one(port + 2, 6580, 0x170, 15, r & 0x04) == 0)
-						ct++;
-				}
-			}
-		}
-	}
-	if (ct != 0)
-		return 0;
-	return -ENODEV;
-}
-
-static __exit void qdi_exit(void)
-{
-	int i;
-
-	for (i = 0; i < nr_qdi_host; i++) {
-		ata_host_detach(qdi_host[i]);
-		/* Free the control resource. The 6580 dual channel has the resources
-		 * claimed as a pair of 2 byte resources so we need no special cases...
-		 */
-		release_region(qdi_data[i].timing, 2);
-		platform_device_unregister(qdi_data[i].platform_dev);
-	}
-}
-
-MODULE_AUTHOR("Alan Cox");
-MODULE_DESCRIPTION("low-level driver for qdi ATA");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(DRV_VERSION);
-
-module_init(qdi_init);
-module_exit(qdi_exit);
-
-module_param(probe_qdi, int, 0);
-

[PATCH 52/86] libata: remove no longer needed pata_winbond driver

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] libata: remove no longer needed pata_winbond driver

Winbond W83759A controller is fully supported by pata_legacy driver
so remove no longer needed pata_winbond driver.

Leave PATA_WINBOND_VLB config option for compatibility reasons
and teach pata_legacy to preserve the old behavior of pata_winbond
driver.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/Kconfig        |    1 
 drivers/ata/Makefile       |    1 
 drivers/ata/pata_legacy.c  |   13 +-
 drivers/ata/pata_winbond.c |  282 ---------------------------------------------
 4 files changed, 12 insertions(+), 285 deletions(-)

Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -695,6 +695,7 @@ config PATA_WINBOND
 config PATA_WINBOND_VLB
 	tristate "Winbond W83759A VLB PATA support (Experimental)"
 	depends on ISA && EXPERIMENTAL
+	select PATA_LEGACY
 	help
 	  Support for the Winbond W83759A controller on Vesa Local Bus
 	  systems.
Index: b/drivers/ata/Makefile
===================================================================
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -64,7 +64,6 @@ obj-$(CONFIG_PATA_SERVERWORKS)	+= pata_s
 obj-$(CONFIG_PATA_SIL680)	+= pata_sil680.o
 obj-$(CONFIG_PATA_VIA)		+= pata_via.o
 obj-$(CONFIG_PATA_WINBOND)	+= pata_sl82c105.o
-obj-$(CONFIG_PATA_WINBOND_VLB)	+= pata_winbond.o
 obj-$(CONFIG_PATA_SIS)		+= pata_sis.o
 obj-$(CONFIG_PATA_TRIFLEX)	+= pata_triflex.o
 obj-$(CONFIG_PATA_IXP4XX_CF)	+= pata_ixp4xx_cf.o
Index: b/drivers/ata/pata_legacy.c
===================================================================
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -44,6 +44,9 @@
  *  Specific support is included for the ht6560a/ht6560b/opti82c611a/
  *  opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A
  *
+ *  Support for the Winbond 83759A when operating in advanced mode.
+ *  Multichip mode is not currently supported.
+ *
  *  Use the autospeed and pio_mask options with:
  *	Appian ADI/2 aka CLPD7220 or AIC25VL01.
  *  Use the jumpers, autospeed and set pio_mask to the mode on the jumpers with
@@ -139,8 +142,12 @@ static int qdi = 1;
 #else
 static int qdi;
 #endif
-static int winbond;		/* Set to probe Winbond controllers,
-					give I/O port if non standard */
+/* Set to probe Winbond controllers, give I/O port if non standard */
+#ifdef PATA_WINBOND_VLB_MODULE
+static int winbond = 1;
+#else
+static int winbond;
+#endif
 static int autospeed;		/* Chip present which snoops speed changes */
 static int pio_mask = ATA_PIO4;	/* PIO range for autospeed devices */
 static int iordy_mask = 0xFFFFFFFF;	/* Use iordy if available */
@@ -1251,6 +1258,7 @@ MODULE_DESCRIPTION("low-level driver for
 MODULE_LICENSE("GPL");
 MODULE_VERSION(DRV_VERSION);
 MODULE_ALIAS("pata_qdi");
+MODULE_ALIAS("pata_winbond");
 
 module_param(probe_all, int, 0);
 module_param(autospeed, int, 0);
@@ -1260,6 +1268,7 @@ module_param(opti82c611a, int, 0);
 module_param(opti82c46x, int, 0);
 module_param(qdi, int, 0);
 module_param_named(probe_qdi, qdi, int, 0);
+module_param_named(probe_winbond, winbond, int, 0);
 module_param(pio_mask, int, 0);
 module_param(iordy_mask, int, 0);
 
Index: b/drivers/ata/pata_winbond.c
===================================================================
--- a/drivers/ata/pata_winbond.c
+++ /dev/null
@@ -1,282 +0,0 @@
-/*
- *    pata_winbond.c - Winbond VLB ATA controllers
- *	(C) 2006 Red Hat
- *
- *    Support for the Winbond 83759A when operating in advanced mode.
- *    Multichip mode is not currently supported.
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/blkdev.h>
-#include <linux/delay.h>
-#include <scsi/scsi_host.h>
-#include <linux/libata.h>
-#include <linux/platform_device.h>
-
-#define DRV_NAME "pata_winbond"
-#define DRV_VERSION "0.0.3"
-
-#define NR_HOST 4	/* Two winbond controllers, two channels each */
-
-struct winbond_data {
-	unsigned long config;
-	struct platform_device *platform_dev;
-};
-
-static struct ata_host *winbond_host[NR_HOST];
-static struct winbond_data winbond_data[NR_HOST];
-static int nr_winbond_host;
-
-#ifdef MODULE
-static int probe_winbond = 1;
-#else
-static int probe_winbond;
-#endif
-
-static DEFINE_SPINLOCK(winbond_lock);
-
-static void winbond_writecfg(unsigned long port, u8 reg, u8 val)
-{
-	unsigned long flags;
-	spin_lock_irqsave(&winbond_lock, flags);
-	outb(reg, port + 0x01);
-	outb(val, port + 0x02);
-	spin_unlock_irqrestore(&winbond_lock, flags);
-}
-
-static u8 winbond_readcfg(unsigned long port, u8 reg)
-{
-	u8 val;
-
-	unsigned long flags;
-	spin_lock_irqsave(&winbond_lock, flags);
-	outb(reg, port + 0x01);
-	val = inb(port + 0x02);
-	spin_unlock_irqrestore(&winbond_lock, flags);
-
-	return val;
-}
-
-static void winbond_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
-	struct ata_timing t;
-	struct winbond_data *winbond = ap->host->private_data;
-	int active, recovery;
-	u8 reg;
-	int timing = 0x88 + (ap->port_no * 4) + (adev->devno * 2);
-
-	reg = winbond_readcfg(winbond->config, 0x81);
-
-	/* Get the timing data in cycles */
-	if (reg & 0x40)		/* Fast VLB bus, assume 50MHz */
-		ata_timing_compute(adev, adev->pio_mode, &t, 20000, 1000);
-	else
-		ata_timing_compute(adev, adev->pio_mode, &t, 30303, 1000);
-
-	active = (clamp_val(t.active, 3, 17) - 1) & 0x0F;
-	recovery = (clamp_val(t.recover, 1, 15) + 1) & 0x0F;
-	timing = (active << 4) | recovery;
-	winbond_writecfg(winbond->config, timing, reg);
-
-	/* Load the setup timing */
-
-	reg = 0x35;
-	if (adev->class != ATA_DEV_ATA)
-		reg |= 0x08;	/* FIFO off */
-	if (!ata_pio_need_iordy(adev))
-		reg |= 0x02;	/* IORDY off */
-	reg |= (clamp_val(t.setup, 0, 3) << 6);
-	winbond_writecfg(winbond->config, timing + 1, reg);
-}
-
-
-static unsigned int winbond_data_xfer(struct ata_device *dev,
-			unsigned char *buf, unsigned int buflen, int rw)
-{
-	struct ata_port *ap = dev->link->ap;
-	int slop = buflen & 3;
-
-	if (ata_id_has_dword_io(dev->id)) {
-		if (rw == READ)
-			ioread32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
-		else
-			iowrite32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
-
-		if (unlikely(slop)) {
-			__le32 pad;
-			if (rw == READ) {
-				pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
-				memcpy(buf + buflen - slop, &pad, slop);
-			} else {
-				memcpy(&pad, buf + buflen - slop, slop);
-				iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
-			}
-			buflen += 4 - slop;
-		}
-	} else
-		buflen = ata_sff_data_xfer(dev, buf, buflen, rw);
-
-	return buflen;
-}
-
-static struct scsi_host_template winbond_sht = {
-	ATA_PIO_SHT(DRV_NAME),
-};
-
-static struct ata_port_operations winbond_port_ops = {
-	.inherits	= &ata_sff_port_ops,
-	.sff_data_xfer	= winbond_data_xfer,
-	.cable_detect	= ata_cable_40wire,
-	.set_piomode	= winbond_set_piomode,
-};
-
-/**
- *	winbond_init_one		-	attach a winbond interface
- *	@type: Type to display
- *	@io: I/O port start
- *	@irq: interrupt line
- *	@fast: True if on a > 33Mhz VLB
- *
- *	Register a VLB bus IDE interface. Such interfaces are PIO and we
- *	assume do not support IRQ sharing.
- */
-
-static __init int winbond_init_one(unsigned long port)
-{
-	struct platform_device *pdev;
-	u8 reg;
-	int i, rc;
-
-	reg = winbond_readcfg(port, 0x81);
-	reg |= 0x80;	/* jumpered mode off */
-	winbond_writecfg(port, 0x81, reg);
-	reg = winbond_readcfg(port, 0x83);
-	reg |= 0xF0;	/* local control */
-	winbond_writecfg(port, 0x83, reg);
-	reg = winbond_readcfg(port, 0x85);
-	reg |= 0xF0;	/* programmable timing */
-	winbond_writecfg(port, 0x85, reg);
-
-	reg = winbond_readcfg(port, 0x81);
-
-	if (!(reg & 0x03))		/* Disabled */
-		return -ENODEV;
-
-	for (i = 0; i < 2 ; i ++) {
-		unsigned long cmd_port = 0x1F0 - (0x80 * i);
-		unsigned long ctl_port = cmd_port + 0x206;
-		struct ata_host *host;
-		struct ata_port *ap;
-		void __iomem *cmd_addr, *ctl_addr;
-
-		if (!(reg & (1 << i)))
-			continue;
-
-		pdev = platform_device_register_simple(DRV_NAME, nr_winbond_host, NULL, 0);
-		if (IS_ERR(pdev))
-			return PTR_ERR(pdev);
-
-		rc = -ENOMEM;
-		host = ata_host_alloc(&pdev->dev, 1);
-		if (!host)
-			goto err_unregister;
-		ap = host->ports[0];
-
-		rc = -ENOMEM;
-		cmd_addr = devm_ioport_map(&pdev->dev, cmd_port, 8);
-		ctl_addr = devm_ioport_map(&pdev->dev, ctl_port, 1);
-		if (!cmd_addr || !ctl_addr)
-			goto err_unregister;
-
-		ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx", cmd_port, ctl_port);
-
-		ap->ops = &winbond_port_ops;
-		ap->pio_mask = ATA_PIO4;
-		ap->flags |= ATA_FLAG_SLAVE_POSS;
-		ap->ioaddr.cmd_addr = cmd_addr;
-		ap->ioaddr.altstatus_addr = ctl_addr;
-		ap->ioaddr.ctl_addr = ctl_addr;
-		ata_sff_std_ports(&ap->ioaddr);
-
-		/* hook in a private data structure per channel */
-		host->private_data = &winbond_data[nr_winbond_host];
-		winbond_data[nr_winbond_host].config = port;
-		winbond_data[nr_winbond_host].platform_dev = pdev;
-
-		/* activate */
-		rc = ata_host_activate(host, 14 + i, ata_sff_interrupt, 0,
-				       &winbond_sht);
-		if (rc)
-			goto err_unregister;
-
-		winbond_host[nr_winbond_host++] = dev_get_drvdata(&pdev->dev);
-	}
-
-	return 0;
-
- err_unregister:
-	platform_device_unregister(pdev);
-	return rc;
-}
-
-/**
- *	winbond_init		-	attach winbond interfaces
- *
- *	Attach winbond IDE interfaces by scanning the ports it may occupy.
- */
-
-static __init int winbond_init(void)
-{
-	static const unsigned long config[2] = { 0x130, 0x1B0 };
-
-	int ct = 0;
-	int i;
-
-	if (probe_winbond == 0)
-		return -ENODEV;
-
-	/*
- 	 *	Check both base addresses
-	 */
-
-	for (i = 0; i < 2; i++) {
-		if (probe_winbond & (1<<i)) {
-			int ret = 0;
-			unsigned long port = config[i];
-
-			if (request_region(port, 2, "pata_winbond")) {
-				ret = winbond_init_one(port);
-				if (ret <= 0)
-					release_region(port, 2);
-				else ct+= ret;
-			}
-		}
-	}
-	if (ct != 0)
-		return 0;
-	return -ENODEV;
-}
-
-static __exit void winbond_exit(void)
-{
-	int i;
-
-	for (i = 0; i < nr_winbond_host; i++) {
-		ata_host_detach(winbond_host[i]);
-		release_region(winbond_data[i].config, 2);
-		platform_device_unregister(winbond_data[i].platform_dev);
-	}
-}
-
-MODULE_AUTHOR("Alan Cox");
-MODULE_DESCRIPTION("low-level driver for Winbond VL ATA");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(DRV_VERSION);
-
-module_init(winbond_init);
-module_exit(winbond_exit);
-
-module_param(probe_winbond, int, 0);
-

[PATCH 53/86] pata_marvell: fix marvell_pre_reset() documentation

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_marvell: fix marvell_pre_reset() documentation

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_marvell.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_marvell.c
===================================================================
--- a/drivers/ata/pata_marvell.c
+++ b/drivers/ata/pata_marvell.c
@@ -58,7 +58,7 @@ static int marvell_pata_active(struct pc
 }
 
 /**
- *	marvell_pre_reset	-	check for 40/80 pin
+ *	marvell_pre_reset	-	probe begin
  *	@link: link
  *	@deadline: deadline jiffies for the operation
  *

[PATCH 54/86] pata_ns87415: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_ns87415: add 32-bit PIO support

There shouldn't be any problems with it as IDE ns87415 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_ns87415.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_ns87415.c
===================================================================
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -300,7 +300,7 @@ static u8 ns87560_bmdma_status(struct at
 #endif		/* 87560 SuperIO Support */
 
 static struct ata_port_operations ns87415_pata_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 
 	.check_atapi_dma	= ns87415_check_atapi_dma,
 	.bmdma_setup		= ns87415_bmdma_setup,

[PATCH 55/86] pata_ns87415: Power Management fix

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_ns87415: Power Management fix

Fix ->resume method to do chipset specific setup.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_ns87415.c |   32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

Index: b/drivers/ata/pata_ns87415.c
===================================================================
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -325,6 +325,13 @@ static struct scsi_host_template ns87415
 	ATA_BMDMA_SHT(DRV_NAME),
 };
 
+static void ns87415_fixup(struct pci_dev *pdev)
+{
+	/* Select 512 byte sectors */
+	pci_write_config_byte(pdev, 0x55, 0xEE);
+	/* Select PIO0 8bit clocking */
+	pci_write_config_byte(pdev, 0x54, 0xB7);
+}
 
 /**
  *	ns87415_init_one - Register 87415 ATA PCI device with kernel services
@@ -371,10 +378,8 @@ static int ns87415_init_one (struct pci_
 	if (rc)
 		return rc;
 
-	/* Select 512 byte sectors */
-	pci_write_config_byte(pdev, 0x55, 0xEE);
-	/* Select PIO0 8bit clocking */
-	pci_write_config_byte(pdev, 0x54, 0xB7);
+	ns87415_fixup(pdev);
+
 	return ata_pci_sff_init_one(pdev, ppi, &ns87415_sht, NULL);
 }
 
@@ -384,6 +389,23 @@ static const struct pci_device_id ns8741
 	{ }	/* terminate list */
 };
 
+#ifdef CONFIG_PM
+static int ns87415_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	ns87415_fixup(pdev);
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 static struct pci_driver ns87415_pci_driver = {
 	.name			= DRV_NAME,
 	.id_table		= ns87415_pci_tbl,
@@ -391,7 +413,7 @@ static struct pci_driver ns87415_pci_dri
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= ata_pci_device_resume,
+	.resume			= ns87415_reinit_one,
 #endif
 };
 

[PATCH 56/86] pata_oldpiix: unify code for programming PIO and MWDMA timings

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_oldpiix: unify code for programming PIO and MWDMA timings

It results in ~12% decrease in the driver LOC count and also ~5%
decrease in the driver binary size (as measured on x86-32).

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_oldpiix.c |   88 +++++++++++++--------------------------------
 1 file changed, 27 insertions(+), 61 deletions(-)

Index: b/drivers/ata/pata_oldpiix.c
===================================================================
--- a/drivers/ata/pata_oldpiix.c
+++ b/drivers/ata/pata_oldpiix.c
@@ -50,20 +50,9 @@ static int oldpiix_pre_reset(struct ata_
 	return ata_sff_prereset(link, deadline);
 }
 
-/**
- *	oldpiix_set_piomode - Initialize host controller PATA PIO timings
- *	@ap: Port whose timings we are configuring
- *	@adev: Device whose timings we are configuring
- *
- *	Set PIO mode for device, in host controller PCI config space.
- *
- *	LOCKING:
- *	None (inherited from caller).
- */
-
-static void oldpiix_set_piomode (struct ata_port *ap, struct ata_device *adev)
+static void oldpiix_set_timings(struct ata_port *ap, struct ata_device *adev,
+				u8 pio, bool use_mwdma)
 {
-	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	unsigned int idetm_port= ap->port_no ? 0x42 : 0x40;
 	u16 idetm_data;
@@ -82,14 +71,18 @@ static void oldpiix_set_piomode (struct 
 			    { 2, 1 },
 			    { 2, 3 }, };
 
-	if (pio > 1)
+	if (pio > 1 || use_mwdma)
 		control |= 1;	/* TIME */
-	if (ata_pio_need_iordy(adev))
+	if (ata_pio_need_iordy(adev) || use_mwdma)
 		control |= 2;	/* IE */
-
 	/* Intel specifies that the prefetch/posting is for disk only */
 	if (adev->class == ATA_DEV_ATA)
 		control |= 4;	/* PPE */
+	/* If the drive MWDMA is faster than it can do PIO then
+	   we must force PIO into PIO0 */
+	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
+		/* Enable DMA timing only */
+		control |= 8;	/* PIO cycles in PIO0 */
 
 	pci_read_config_word(dev, idetm_port, &idetm_data);
 
@@ -113,6 +106,22 @@ static void oldpiix_set_piomode (struct 
 }
 
 /**
+ *	oldpiix_set_piomode - Initialize host controller PATA PIO timings
+ *	@ap: Port whose timings we are configuring
+ *	@adev: Device whose timings we are configuring
+ *
+ *	Set PIO mode for device, in host controller PCI config space.
+ *
+ *	LOCKING:
+ *	None (inherited from caller).
+ */
+
+static void oldpiix_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+	oldpiix_set_timings(ap, adev, adev->pio_mode - XFER_PIO_0, 0);
+}
+
+/**
  *	oldpiix_set_dmamode - Initialize host controller PATA DMA timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device to program
@@ -125,58 +134,15 @@ static void oldpiix_set_piomode (struct 
 
 static void oldpiix_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 {
-	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
-	u8 idetm_port		= ap->port_no ? 0x42 : 0x40;
-	u16 idetm_data;
-
-	static const	 /* ISP  RTC */
-	u8 timings[][2]	= { { 0, 0 },
-			    { 0, 0 },
-			    { 1, 0 },
-			    { 2, 1 },
-			    { 2, 3 }, };
-
-	/*
-	 * MWDMA is driven by the PIO timings. We must also enable
-	 * IORDY unconditionally along with TIME1. PPE has already
-	 * been set when the PIO timing was set.
-	 */
+	/* MWDMA is driven by the PIO timings. */
 
 	unsigned int mwdma	= adev->dma_mode - XFER_MW_DMA_0;
-	unsigned int control;
 	const unsigned int needed_pio[3] = {
 		XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
 	};
 	int pio = needed_pio[mwdma] - XFER_PIO_0;
 
-	pci_read_config_word(dev, idetm_port, &idetm_data);
-
-	control = 3;	/* IORDY|TIME0 */
-	/* Intel specifies that the PPE functionality is for disk only */
-	if (adev->class == ATA_DEV_ATA)
-		control |= 4;	/* PPE enable */
-
-	/* If the drive MWDMA is faster than it can do PIO then
-	   we must force PIO into PIO0 */
-
-	if (adev->pio_mode < needed_pio[mwdma])
-		/* Enable DMA timing only */
-		control |= 8;	/* PIO cycles in PIO0 */
-
-	/* Mask out the relevant control and timing bits we will load. Also
-	   clear the other drive TIME register as a precaution */
-	if (adev->devno == 0) {
-		idetm_data &= 0xCCE0;
-		idetm_data |= control;
-	} else {
-		idetm_data &= 0xCC0E;
-		idetm_data |= (control << 4);
-	}
-	idetm_data |= (timings[pio][0] << 12) | (timings[pio][1] << 8);
-	pci_write_config_word(dev, idetm_port, idetm_data);
-
-	/* Track which port is configured */
-	ap->private_data = adev;
+	oldpiix_set_timings(ap, adev, pio, 1);
 }
 
 /**

[PATCH 57/86] pata_opti: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_opti: add 32-bit PIO support

There shouldn't be any problems with it as IDE opti621 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_opti.c |    2 ++
 1 file changed, 2 insertions(+)

Index: b/drivers/ata/pata_opti.c
===================================================================
--- a/drivers/ata/pata_opti.c
+++ b/drivers/ata/pata_opti.c
@@ -157,6 +157,8 @@ static struct ata_port_operations opti_p
 	.cable_detect	= ata_cable_40wire,
 	.set_piomode	= opti_set_piomode,
 	.prereset	= opti_pre_reset,
+	.sff_data_xfer	= ata_sff_data_xfer32,
+	.port_start	= ata_sff_port_start32,
 };
 
 static int opti_init_one(struct pci_dev *dev, const struct pci_device_id *id)

[PATCH 58/86] pata_pdc2027x: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc2027x: add 32-bit PIO support

There shouldn't be any problems with it as IDE pdc202xx_new host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_pdc2027x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_pdc2027x.c
===================================================================
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -133,7 +133,7 @@ static struct scsi_host_template pdc2027
 };
 
 static struct ata_port_operations pdc2027x_pata100_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.check_atapi_dma	= pdc2027x_check_atapi_dma,
 	.cable_detect		= pdc2027x_cable_detect,
 	.prereset		= pdc2027x_prereset,

[PATCH 59/86] pata_pdc2027x: add Power Management support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc2027x: add Power Management support

There shouldn't be any problems with it as IDE pdc202xx_new host driver
has been supporting Power Management for over year now.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_pdc2027x.c |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

Index: b/drivers/ata/pata_pdc2027x.c
===================================================================
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -63,6 +63,7 @@ enum {
 };
 
 static int pdc2027x_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
+static int pdc2027x_reinit_one(struct pci_dev *pdev);
 static int pdc2027x_prereset(struct ata_link *link, unsigned long deadline);
 static void pdc2027x_set_piomode(struct ata_port *ap, struct ata_device *adev);
 static void pdc2027x_set_dmamode(struct ata_port *ap, struct ata_device *adev);
@@ -126,6 +127,10 @@ static struct pci_driver pdc2027x_pci_dr
 	.id_table		= pdc2027x_pci_tbl,
 	.probe			= pdc2027x_init_one,
 	.remove			= ata_pci_remove_one,
+#ifdef CONFIG_PM
+	.suspend		= ata_pci_device_suspend,
+	.resume			= pdc2027x_reinit_one,
+#endif
 };
 
 static struct scsi_host_template pdc2027x_sht = {
@@ -758,6 +763,31 @@ static int __devinit pdc2027x_init_one(s
 				 IRQF_SHARED, &pdc2027x_sht);
 }
 
+#ifdef CONFIG_PM
+static int pdc2027x_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	unsigned int board_idx;
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	if (pdev->device == PCI_DEVICE_ID_PROMISE_20268 ||
+	    pdev->device == PCI_DEVICE_ID_PROMISE_20270)
+		board_idx = PDC_UDMA_100;
+	else
+		board_idx = PDC_UDMA_133;
+
+	if (pdc_hardware_init(host, board_idx))
+		return -EIO;
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 /**
  * pdc2027x_init - Called after this module is loaded into the kernel.
  */

[PATCH 60/86] pata_pdc202xx_old: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc202xx_old: add 32-bit PIO support

There shouldn't be any problems with it as IDE pdc202xx_old host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_pdc202xx_old.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -240,7 +240,7 @@ static int pdc2026x_port_start(struct at
 		u8 burst = ioread8(bmdma + 0x1f);
 		iowrite8(burst | 0x01, bmdma + 0x1f);
 	}
-	return ata_sff_port_start(ap);
+	return ata_sff_port_start32(ap);
 }
 
 /**
@@ -266,7 +266,7 @@ static struct scsi_host_template pdc202x
 };
 
 static struct ata_port_operations pdc2024x_port_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 
 	.cable_detect		= ata_cable_40wire,
 	.set_piomode		= pdc202xx_set_piomode,

[PATCH 61/86] pata_sis: Power Management fix

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc202xx_old: Power Management fix

Enable burst mode on resume for PDC2026x controllers.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_pdc202xx_old.c |   33 +++++++++++++++++++++++++++++++--
 1 file changed, 31 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -232,14 +232,21 @@ static void pdc2026x_dev_config(struct a
 	adev->max_sectors = 256;
 }
 
-static int pdc2026x_port_start(struct ata_port *ap)
+static void pdc2026x_bmdma_enable_burst(struct ata_port *ap)
 {
 	void __iomem *bmdma = ap->ioaddr.bmdma_addr;
+
 	if (bmdma) {
 		/* Enable burst mode */
 		u8 burst = ioread8(bmdma + 0x1f);
 		iowrite8(burst | 0x01, bmdma + 0x1f);
 	}
+}
+
+static int pdc2026x_port_start(struct ata_port *ap)
+{
+	pdc2026x_bmdma_enable_burst(ap);
+
 	return ata_sff_port_start32(ap);
 }
 
@@ -327,6 +334,28 @@ static int pdc202xx_init_one(struct pci_
 	return ata_pci_sff_init_one(dev, ppi, &pdc202xx_sht, NULL);
 }
 
+#ifdef CONFIG_PM
+static int pdc202xx_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc, i;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	for (i = 0; i < host->n_ports; i++) {
+		struct ata_port *ap = host->ports[i];
+
+		if (ap->udma_mask > ATA_UDMA2)
+			pdc2026x_bmdma_enable_burst(ap);
+	}
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 static const struct pci_device_id pdc202xx[] = {
 	{ PCI_VDEVICE(PROMISE, PCI_DEVICE_ID_PROMISE_20246), 0 },
 	{ PCI_VDEVICE(PROMISE, PCI_DEVICE_ID_PROMISE_20262), 1 },
@@ -344,7 +373,7 @@ static struct pci_driver pdc202xx_pci_dr
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= ata_pci_device_resume,
+	.resume		= pdc202xx_reinit_one,
 #endif
 };
 

[PATCH 62/86] pata_pdc202xx_old: document known issues

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc202xx_old: document known issues

Document known issues with the driver to aid distribution makers,
users and developers in making informed decisions instead of wasting
their time needlessly.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/Kconfig |    4 ++++
 1 file changed, 4 insertions(+)

Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -583,6 +583,10 @@ config PATA_PDC_OLD
 	  This option enables support for the Promise 20246, 20262, 20263,
 	  20265 and 20267 adapters.
 
+	  Known issues:
+	  - UDMA transfers fail mysteriously on some chipsets
+	  - ATAPI DMA is unsupported currently
+
 	  If unsure, say N.
 
 config PATA_QDI

[PATCH 63/86] pata_radisys: fix UDMA handling

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_radisys: fix UDMA handling

Set correct bits to switch between UDMA2 and UDMA4.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_radisys.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_radisys.c
===================================================================
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -139,9 +139,9 @@ static void radisys_set_dmamode (struct 
 		pci_read_config_byte(dev, 0x4A, &udma_mode);
 
 		if (adev->xfer_mode == XFER_UDMA_2)
-			udma_mode &= ~ (1 << adev->devno);
+			udma_mode &= ~(2 << (adev->devno * 4));
 		else /* UDMA 4 */
-			udma_mode |= (1 << adev->devno);
+			udma_mode |= (2 << (adev->devno * 4));
 
 		pci_write_config_byte(dev, 0x4A, udma_mode);
 

[PATCH 64/86] pata_radisys: unify code for programming PIO and MWDMA timings

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_radisys: unify code for programming PIO and MWDMA timings

It results in ~6% decrease in the driver LOC count and also ~1%
decrease in the driver binary size (as measured on x86-32).

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_radisys.c |   66 +++++++++++++++++----------------------------
 1 file changed, 25 insertions(+), 41 deletions(-)

Index: b/drivers/ata/pata_radisys.c
===================================================================
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -26,20 +26,9 @@
 #define DRV_NAME	"pata_radisys"
 #define DRV_VERSION	"0.4.4"
 
-/**
- *	radisys_set_piomode - Initialize host controller PATA PIO timings
- *	@ap: ATA port
- *	@adev: Device whose timings we are configuring
- *
- *	Set PIO mode for device, in host controller PCI config space.
- *
- *	LOCKING:
- *	None (inherited from caller).
- */
-
-static void radisys_set_piomode (struct ata_port *ap, struct ata_device *adev)
+static void radisys_set_timings(struct ata_port *ap, struct ata_device *adev,
+				u8 pio, bool use_mwdma)
 {
-	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	u16 idetm_data;
 	int control = 0;
@@ -52,7 +41,7 @@ static void radisys_set_piomode (struct
 	 */
 
 	static const	 /* ISP  RTC */
-	u8 timings[][2]	= { { 0, 0 },	/* Check me */
+	u8 timings[][2]	= { { 0, 0 },
 			    { 0, 0 },
 			    { 1, 1 },
 			    { 2, 2 },
@@ -62,6 +51,10 @@ static void radisys_set_piomode (struct
 		control |= 1;	/* TIME1 enable */
 	if (ata_pio_need_iordy(adev))
 		control |= 2;	/* IE IORDY */
+	/* If the drive MWDMA is faster than it can do PIO then
+	   we must force PIO0 for PIO cycles. */
+	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
+		control = 1;
 
 	pci_read_config_word(dev, 0x40, &idetm_data);
 
@@ -78,6 +71,22 @@ static void radisys_set_piomode (struct
 }
 
 /**
+ *	radisys_set_piomode - Initialize host controller PATA PIO timings
+ *	@ap: ATA port
+ *	@adev: Device whose timings we are configuring
+ *
+ *	Set PIO mode for device, in host controller PCI config space.
+ *
+ *	LOCKING:
+ *	None (inherited from caller).
+ */
+
+static void radisys_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+	radisys_set_timings(ap, adev, adev->pio_mode - XFER_PIO_0, 0);
+}
+
+/**
  *	radisys_set_dmamode - Initialize host controller PATA DMA timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Device to program
@@ -91,22 +100,10 @@ static void radisys_set_piomode (struct
 static void radisys_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 {
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
-	u16 idetm_data;
 	u8 udma_enable;
 
-	static const	 /* ISP  RTC */
-	u8 timings[][2]	= { { 0, 0 },
-			    { 0, 0 },
-			    { 1, 1 },
-			    { 2, 2 },
-			    { 3, 3 }, };
-
-	/*
-	 * MWDMA is driven by the PIO timings. We must also enable
-	 * IORDY unconditionally.
-	 */
+	/* MWDMA is driven by the PIO timings. */
 
-	pci_read_config_word(dev, 0x40, &idetm_data);
 	pci_read_config_byte(dev, 0x48, &udma_enable);
 
 	if (adev->dma_mode < XFER_UDMA_0) {
@@ -115,20 +112,8 @@ static void radisys_set_dmamode (struct
 			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
 		};
 		int pio = needed_pio[mwdma] - XFER_PIO_0;
-		int control = 3;	/* IORDY|TIME0 */
-
-		/* If the drive MWDMA is faster than it can do PIO then
-		   we must force PIO0 for PIO cycles. */
-
-		if (adev->pio_mode < needed_pio[mwdma])
-			control = 1;
 
-		/* Mask out the relevant control and timing bits we will load. Also
-		   clear the other drive TIME register as a precaution */
-
-		idetm_data &= 0xCCCC;
-		idetm_data |= control << (4 * adev->devno);
-		idetm_data |= (timings[pio][0] << 12) | (timings[pio][1] << 8);
+		radisys_set_timings(ap, adev, pio, 1);
 
 		udma_enable &= ~(1 << adev->devno);
 	} else {
@@ -147,7 +132,6 @@ static void radisys_set_dmamode (struct
 
 		udma_enable |= (1 << adev->devno);
 	}
-	pci_write_config_word(dev, 0x40, idetm_data);
 	pci_write_config_byte(dev, 0x48, udma_enable);
 
 	/* Track which port is configured */

[PATCH 65/86] pata_rdc: unify code for programming PIO and MWDMA timings

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_rdc: unify code for programming PIO and MWDMA timings

It results in ~8% decrease in the driver LOC count and also ~8%
decrease in the driver binary size (as measured on x86-32).

Fix rdc_set_piomode() documentation while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_rdc.c |   99 ++++++++++++++++---------------------------------
 1 file changed, 33 insertions(+), 66 deletions(-)

Index: b/drivers/ata/pata_rdc.c
===================================================================
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -85,20 +85,9 @@ static int rdc_pata_prereset(struct ata_
 	return ata_sff_prereset(link, deadline);
 }
 
-/**
- *	rdc_set_piomode - Initialize host controller PATA PIO timings
- *	@ap: Port whose timings we are configuring
- *	@adev: um
- *
- *	Set PIO mode for device, in host controller PCI config space.
- *
- *	LOCKING:
- *	None (inherited from caller).
- */
-
-static void rdc_set_piomode(struct ata_port *ap, struct ata_device *adev)
+static void rdc_set_timings(struct ata_port *ap, struct ata_device *adev,
+			    u8 pio, bool use_mwdma)
 {
-	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	unsigned int is_slave	= (adev->devno != 0);
 	unsigned int master_port= ap->port_no ? 0x42 : 0x40;
@@ -115,13 +104,17 @@ static void rdc_set_piomode(struct ata_p
 			    { 2, 1 },
 			    { 2, 3 }, };
 
-	if (pio >= 2)
+	if (pio >= 2 || use_mwdma)
 		control |= 1;	/* TIME1 enable */
-	if (ata_pio_need_iordy(adev))
+	if (ata_pio_need_iordy(adev) || use_mwdma)
 		control |= 2;	/* IE enable */
-
 	if (adev->class == ATA_DEV_ATA)
 		control |= 4;	/* PPE enable */
+	/* If the drive MWDMA is faster than it can do PIO then
+	   we must force PIO into PIO0 */
+	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
+		/* Enable DMA timing only */
+		control |= 8;	/* PIO cycles in PIO0 */
 
 	/* PIO configuration clears DTE unconditionally.  It will be
 	 * programmed in set_dmamode which is guaranteed to be called
@@ -163,6 +156,22 @@ static void rdc_set_piomode(struct ata_p
 }
 
 /**
+ *	rdc_set_piomode - Initialize host controller PATA PIO timings
+ *	@ap: Port whose timings we are configuring
+ *	@adev: Drive in question
+ *
+ *	Set PIO mode for device, in host controller PCI config space.
+ *
+ *	LOCKING:
+ *	None (inherited from caller).
+ */
+
+static void rdc_set_piomode(struct ata_port *ap, struct ata_device *adev)
+{
+	rdc_set_timings(ap, adev, adev->pio_mode - XFER_PIO_0, 0);
+}
+
+/**
  *	rdc_set_dmamode - Initialize host controller PATA PIO timings
  *	@ap: Port whose timings we are configuring
  *	@adev: Drive in question
@@ -176,28 +185,18 @@ static void rdc_set_piomode(struct ata_p
 static void rdc_set_dmamode(struct ata_port *ap, struct ata_device *adev)
 {
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
-	u8 master_port		= ap->port_no ? 0x42 : 0x40;
-	u16 master_data;
 	u8 speed		= adev->dma_mode;
 	int devid		= adev->devno + 2 * ap->port_no;
 	u8 udma_enable		= 0;
 
-	static const	 /* ISP  RTC */
-	u8 timings[][2]	= { { 0, 0 },
-			    { 0, 0 },
-			    { 1, 0 },
-			    { 2, 1 },
-			    { 2, 3 }, };
-
-	pci_read_config_word(dev, master_port, &master_data);
-	pci_read_config_byte(dev, 0x48, &udma_enable);
-
 	if (speed >= XFER_UDMA_0) {
-		unsigned int udma = adev->dma_mode - XFER_UDMA_0;
+		unsigned int udma = speed - XFER_UDMA_0;
 		u16 udma_timing;
 		u16 ideconf;
 		int u_clock, u_speed;
 
+		pci_read_config_byte(dev, 0x48, &udma_enable);
+
 		/*
 		 * UDMA is handled by a combination of clock switching and
 		 * selection of dividers
@@ -226,50 +225,18 @@ static void rdc_set_dmamode(struct ata_p
 		ideconf &= ~(0x1001 << devid);
 		ideconf |= u_clock << devid;
 		pci_write_config_word(dev, 0x54, ideconf);
+
+		pci_write_config_byte(dev, 0x48, udma_enable);
 	} else {
-		/*
-		 * MWDMA is driven by the PIO timings. We must also enable
-		 * IORDY unconditionally along with TIME1. PPE has already
-		 * been set when the PIO timing was set.
-		 */
-		unsigned int mwdma	= adev->dma_mode - XFER_MW_DMA_0;
-		unsigned int control;
-		u8 slave_data;
+		/* MWDMA is driven by the PIO timings. */
+		unsigned int mwdma = speed - XFER_MW_DMA_0;
 		const unsigned int needed_pio[3] = {
 			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
 		};
 		int pio = needed_pio[mwdma] - XFER_PIO_0;
 
-		control = 3;	/* IORDY|TIME1 */
-
-		/* If the drive MWDMA is faster than it can do PIO then
-		   we must force PIO into PIO0 */
-
-		if (adev->pio_mode < needed_pio[mwdma])
-			/* Enable DMA timing only */
-			control |= 8;	/* PIO cycles in PIO0 */
-
-		if (adev->devno) {	/* Slave */
-			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
-			master_data |= control << 4;
-			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= (ap->port_no ? 0x0f : 0xf0);
-			/* Load the matching timing */
-			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
-			pci_write_config_byte(dev, 0x44, slave_data);
-		} else { 	/* Master */
-			master_data &= 0xCCF4;	/* Mask out IORDY|TIME1|DMAONLY
-						   and master timing bits */
-			master_data |= control;
-			master_data |=
-				(timings[pio][0] << 12) |
-				(timings[pio][1] << 8);
-		}
-
-		udma_enable &= ~(1 << devid);
-		pci_write_config_word(dev, master_port, master_data);
+		rdc_set_timings(ap, adev, pio, 1);
 	}
-	pci_write_config_byte(dev, 0x48, udma_enable);
 }
 
 static struct ata_port_operations rdc_pata_ops = {

[PATCH 66/86] pata_rz1000: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_rz1000: add 32-bit PIO support

There shouldn't be any problems with it as IDE rz1000 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_rz1000.c |    2 ++
 1 file changed, 2 insertions(+)

Index: b/drivers/ata/pata_rz1000.c
===================================================================
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -58,6 +58,8 @@ static struct ata_port_operations rz1000
 	.inherits	= &ata_sff_port_ops,
 	.cable_detect	= ata_cable_40wire,
 	.set_mode	= rz1000_set_mode,
+	.sff_data_xfer	= ata_sff_data_xfer32,
+	.port_start	= ata_sff_port_start32,
 };
 
 static int rz1000_fifo_disable(struct pci_dev *pdev)

[PATCH 67/86] pata_rz1000: Power Management fix

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_rz1000: Power Management fix

Fix ->resume method to re-enable & re-init PCI device properly
before doing chipset specific setup.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_rz1000.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Index: b/drivers/ata/pata_rz1000.c
===================================================================
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -107,11 +107,20 @@ static int rz1000_init_one (struct pci_d
 #ifdef CONFIG_PM
 static int rz1000_reinit_one(struct pci_dev *pdev)
 {
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
 	/* If this fails on resume (which is a "cant happen" case), we
 	   must stop as any progress risks data loss */
 	if (rz1000_fifo_disable(pdev))
 		panic("rz1000 fifo");
-	return ata_pci_device_resume(pdev);
+
+	ata_host_resume(host);
+	return 0;
 }
 #endif
 

[PATCH 68/86] pata_sc1200: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_sc1200: add 32-bit PIO support

There shouldn't be any problems with it as IDE sc1200 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_sc1200.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_sc1200.c
===================================================================
--- a/drivers/ata/pata_sc1200.c
+++ b/drivers/ata/pata_sc1200.c
@@ -208,7 +208,7 @@ static struct scsi_host_template sc1200_
 };
 
 static struct ata_port_operations sc1200_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.qc_prep 	= ata_sff_dumb_qc_prep,
 	.qc_issue	= sc1200_qc_issue,
 	.qc_defer	= sc1200_qc_defer,

[PATCH 69/86] pata_scc: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_scc: add 32-bit PIO support

There shouldn't be any problems with it as IDE scc_pata host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_scc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_scc.c
===================================================================
--- a/drivers/ata/pata_scc.c
+++ b/drivers/ata/pata_scc.c
@@ -966,7 +966,7 @@ static struct scsi_host_template scc_sht
 };
 
 static struct ata_port_operations scc_pata_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 
 	.set_piomode		= scc_set_piomode,
 	.set_dmamode		= scc_set_dmamode,

[PATCH 70/86] pata_scc: add proper cable detection method

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_scc: add proper cable detection method

Use standard ata_cable_80wire() method for the cable detection,
as a bonus this allows us to use the default ->prereset method.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_scc.c |   14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

Index: b/drivers/ata/pata_scc.c
===================================================================
--- a/drivers/ata/pata_scc.c
+++ b/drivers/ata/pata_scc.c
@@ -865,18 +865,6 @@ static void scc_freeze (struct ata_port
 }
 
 /**
- *	scc_pata_prereset - prepare for reset
- *	@ap: ATA port to be reset
- *	@deadline: deadline jiffies for the operation
- */
-
-static int scc_pata_prereset(struct ata_link *link, unsigned long deadline)
-{
-	link->ap->cbl = ATA_CBL_PATA80;
-	return ata_sff_prereset(link, deadline);
-}
-
-/**
  *	scc_postreset - standard postreset callback
  *	@ap: the target ata_port
  *	@classes: classes of attached devices
@@ -986,7 +974,7 @@ static struct ata_port_operations scc_pa
 	.sff_data_xfer		= scc_data_xfer,
 
 	.freeze			= scc_freeze,
-	.prereset		= scc_pata_prereset,
+	.cable_detect		= ata_cable_80wire,
 	.softreset		= scc_softreset,
 	.postreset		= scc_postreset,
 	.post_internal_cmd	= scc_bmdma_stop,

[PATCH 71/86] pata_sch: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_sch: add 32-bit PIO support

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_sch.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_sch.c
===================================================================
--- a/drivers/ata/pata_sch.c
+++ b/drivers/ata/pata_sch.c
@@ -76,7 +76,7 @@ static struct scsi_host_template sch_sht
 };
 
 static struct ata_port_operations sch_pata_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.cable_detect		= ata_cable_unknown,
 	.set_piomode		= sch_set_piomode,
 	.set_dmamode		= sch_set_dmamode,

[PATCH 72/86] pata_serverworks: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_serverworks: add 32-bit PIO support

There shouldn't be any problems with it as IDE serverworks host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_serverworks.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_serverworks.c
===================================================================
--- a/drivers/ata/pata_serverworks.c
+++ b/drivers/ata/pata_serverworks.c
@@ -300,7 +300,7 @@ static struct scsi_host_template serverw
 };
 
 static struct ata_port_operations serverworks_osb4_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.cable_detect	= serverworks_cable_detect,
 	.mode_filter	= serverworks_osb4_filter,
 	.set_piomode	= serverworks_set_piomode,

[PATCH 73/86] pata_serverworks: use standard cable detection methods

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_serverworks: use standard cable detection methods

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_serverworks.c |   45 ++++++++++-------------------------------
 1 file changed, 12 insertions(+), 33 deletions(-)

Index: b/drivers/ata/pata_serverworks.c
===================================================================
--- a/drivers/ata/pata_serverworks.c
+++ b/drivers/ata/pata_serverworks.c
@@ -64,7 +64,8 @@ static const char *csb_bad_ata100[] = {
  *	bits of the subsystem ID.
  */
 
-static int dell_cable(struct ata_port *ap) {
+static int dell_cable(struct ata_port *ap)
+{
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
 
 	if (pdev->subsystem_device & (1 << (ap->port_no + 14)))
@@ -81,7 +82,8 @@ static int dell_cable(struct ata_port *a
  *	need to extend the Dell one in future
  */
 
-static int sun_cable(struct ata_port *ap) {
+static int sun_cable(struct ata_port *ap)
+{
 	struct pci_dev *pdev = to_pci_dev(ap->host->dev);
 
 	if (pdev->subsystem_device & (1 << (ap->port_no + 14)))
@@ -89,29 +91,6 @@ static int sun_cable(struct ata_port *ap
 	return ATA_CBL_PATA40;
 }
 
-/**
- *	osb4_cable	-	OSB4 cable detect
- *	@ap: ATA port to check
- *
- *	The OSB4 isn't UDMA66 capable so this is easy
- */
-
-static int osb4_cable(struct ata_port *ap) {
-	return ATA_CBL_PATA40;
-}
-
-/**
- *	csb_cable	-	CSB5/6 cable detect
- *	@ap: ATA port to check
- *
- *	Serverworks default arrangement is to use the drive side detection
- *	only.
- */
-
-static int csb_cable(struct ata_port *ap) {
-	return ATA_CBL_PATA_UNK;
-}
-
 struct sv_cable_table {
 	int device;
 	int subvendor;
@@ -124,14 +103,14 @@ struct sv_cable_table {
  */
 
 static struct sv_cable_table cable_detect[] = {
-	{ PCI_DEVICE_ID_SERVERWORKS_CSB5IDE, PCI_VENDOR_ID_DELL, dell_cable },
-	{ PCI_DEVICE_ID_SERVERWORKS_CSB6IDE, PCI_VENDOR_ID_DELL, dell_cable },
-	{ PCI_DEVICE_ID_SERVERWORKS_CSB5IDE, PCI_VENDOR_ID_SUN,  sun_cable },
-	{ PCI_DEVICE_ID_SERVERWORKS_OSB4IDE, PCI_ANY_ID, osb4_cable },
-	{ PCI_DEVICE_ID_SERVERWORKS_CSB5IDE, PCI_ANY_ID, csb_cable },
-	{ PCI_DEVICE_ID_SERVERWORKS_CSB6IDE, PCI_ANY_ID, csb_cable },
-	{ PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2, PCI_ANY_ID, csb_cable },
-	{ PCI_DEVICE_ID_SERVERWORKS_HT1000IDE, PCI_ANY_ID, csb_cable },
+	{ PCI_DEVICE_ID_SERVERWORKS_CSB5IDE,   PCI_VENDOR_ID_DELL, dell_cable },
+	{ PCI_DEVICE_ID_SERVERWORKS_CSB6IDE,   PCI_VENDOR_ID_DELL, dell_cable },
+	{ PCI_DEVICE_ID_SERVERWORKS_CSB5IDE,   PCI_VENDOR_ID_SUN,  sun_cable  },
+	{ PCI_DEVICE_ID_SERVERWORKS_OSB4IDE,   PCI_ANY_ID, ata_cable_40wire  },
+	{ PCI_DEVICE_ID_SERVERWORKS_CSB5IDE,   PCI_ANY_ID, ata_cable_unknown },
+	{ PCI_DEVICE_ID_SERVERWORKS_CSB6IDE,   PCI_ANY_ID, ata_cable_unknown },
+	{ PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2,  PCI_ANY_ID, ata_cable_unknown },
+	{ PCI_DEVICE_ID_SERVERWORKS_HT1000IDE, PCI_ANY_ID, ata_cable_unknown },
 	{ }
 };
 

[PATCH 74/86] pata_serverworks: add serverworks_fixup()

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_serverworks: add serverworks_fixup()

Factor out common code from serverworks_[re]init_one() to
serverworks_fixup().

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_serverworks.c |   57 ++++++++++++++++++++---------------------
 1 file changed, 29 insertions(+), 28 deletions(-)

Index: b/drivers/ata/pata_serverworks.c
===================================================================
--- a/drivers/ata/pata_serverworks.c
+++ b/drivers/ata/pata_serverworks.c
@@ -371,6 +371,31 @@ static void serverworks_fixup_ht1000(str
 	pci_write_config_byte(pdev, 0x5A, btr);
 }
 
+static int serverworks_fixup(struct pci_dev *pdev)
+{
+	int rc = 0;
+
+	/* Force master latency timer to 64 PCI clocks */
+	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
+
+	switch (pdev->device) {
+	case PCI_DEVICE_ID_SERVERWORKS_OSB4IDE:
+		rc = serverworks_fixup_osb4(pdev);
+		break;
+	case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE:
+		ata_pci_bmdma_clear_simplex(pdev);
+		/* fall through */
+	case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE:
+	case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2:
+		rc = serverworks_fixup_csb(pdev);
+		break;
+	case PCI_DEVICE_ID_SERVERWORKS_HT1000IDE:
+		serverworks_fixup_ht1000(pdev);
+		break;
+	}
+
+	return rc;
+}
 
 static int serverworks_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 {
@@ -408,13 +433,12 @@ static int serverworks_init_one(struct p
 	if (rc)
 		return rc;
 
-	/* Force master latency timer to 64 PCI clocks */
-	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
+	rc = serverworks_fixup(pdev);
 
 	/* OSB4 : South Bridge and IDE */
 	if (pdev->device == PCI_DEVICE_ID_SERVERWORKS_OSB4IDE) {
 		/* Select non UDMA capable OSB4 if we can't do fixups */
-		if ( serverworks_fixup_osb4(pdev) < 0)
+		if (rc < 0)
 			ppi[0] = &info[1];
 	}
 	/* setup CSB5/CSB6 : South Bridge and IDE option RAID */
@@ -424,19 +448,13 @@ static int serverworks_init_one(struct p
 
 		 /* If the returned btr is the newer revision then
 		    select the right info block */
-		 if (serverworks_fixup_csb(pdev) == 3)
+		 if (rc == 3)
 		 	ppi[0] = &info[3];
 
 		/* Is this the 3rd channel CSB6 IDE ? */
 		if (pdev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2)
 			ppi[1] = &ata_dummy_port_info;
 	}
-	/* setup HT1000E */
-	else if (pdev->device == PCI_DEVICE_ID_SERVERWORKS_HT1000IDE)
-		serverworks_fixup_ht1000(pdev);
-
-	if (pdev->device == PCI_DEVICE_ID_SERVERWORKS_CSB5IDE)
-		ata_pci_bmdma_clear_simplex(pdev);
 
 	return ata_pci_sff_init_one(pdev, ppi, &serverworks_sht, NULL);
 }
@@ -451,24 +469,7 @@ static int serverworks_reinit_one(struct
 	if (rc)
 		return rc;
 
-	/* Force master latency timer to 64 PCI clocks */
-	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
-
-	switch (pdev->device) {
-		case PCI_DEVICE_ID_SERVERWORKS_OSB4IDE:
-			serverworks_fixup_osb4(pdev);
-			break;
-		case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE:
-			ata_pci_bmdma_clear_simplex(pdev);
-			/* fall through */
-		case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE:
-		case PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2:
-			serverworks_fixup_csb(pdev);
-			break;
-		case PCI_DEVICE_ID_SERVERWORKS_HT1000IDE:
-			serverworks_fixup_ht1000(pdev);
-			break;
-	}
+	(void)serverworks_fixup(pdev);
 
 	ata_host_resume(host);
 	return 0;

[PATCH 75/86] pata_sl82c105: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_sl82c105: add 32-bit PIO support

There shouldn't be any problems with it as IDE sl82c105 host driver
has been using 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_sl82c105.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_sl82c105.c
===================================================================
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -232,7 +232,7 @@ static struct scsi_host_template sl82c10
 };
 
 static struct ata_port_operations sl82c105_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.qc_defer	= sl82c105_qc_defer,
 	.bmdma_start 	= sl82c105_bmdma_start,
 	.bmdma_stop	= sl82c105_bmdma_stop,

[PATCH 76/86] pata_sl82c105: add Power Management support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_sl82c105: add Power Management support

There shouldn't be any problems with it as IDE sl82c105 host driver
has been supporting Power Management for over year now.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_sl82c105.c |   37 ++++++++++++++++++++++++++++++++-----
 1 file changed, 32 insertions(+), 5 deletions(-)

Index: b/drivers/ata/pata_sl82c105.c
===================================================================
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -1,6 +1,7 @@
 /*
  * pata_sl82c105.c 	- SL82C105 PATA for new ATA layer
  *			  (C) 2005 Red Hat Inc
+ *			  (C) 2009 Bartlomiej Zolnierkiewicz
  *
  * Based in part on linux/drivers/ide/pci/sl82c105.c
  * 		SL82C105/Winbond 553 IDE driver
@@ -278,6 +279,14 @@ static int sl82c105_bridge_revision(stru
 	return bridge->revision;
 }
 
+static void sl82c105_fixup(struct pci_dev *pdev)
+{
+	u32 val;
+
+	pci_read_config_dword(pdev, 0x40, &val);
+	val |= CTRL_P0EN | CTRL_P0F16 | CTRL_P1F16;
+	pci_write_config_dword(pdev, 0x40, val);
+}
 
 static int sl82c105_init_one(struct pci_dev *dev, const struct pci_device_id *id)
 {
@@ -295,7 +304,6 @@ static int sl82c105_init_one(struct pci_
 	/* for now use only the first port */
 	const struct ata_port_info *ppi[] = { &info_early,
 					       NULL };
-	u32 val;
 	int rev;
 	int rc;
 
@@ -312,13 +320,28 @@ static int sl82c105_init_one(struct pci_
 	else
 		ppi[0] = &info_dma;
 
-	pci_read_config_dword(dev, 0x40, &val);
-	val |= CTRL_P0EN | CTRL_P0F16 | CTRL_P1F16;
-	pci_write_config_dword(dev, 0x40, val);
+	sl82c105_fixup(dev);
 
 	return ata_pci_sff_init_one(dev, ppi, &sl82c105_sht, NULL);
 }
 
+#ifdef CONFIG_PM
+static int sl82c105_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	sl82c105_fixup(pdev);
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 static const struct pci_device_id sl82c105[] = {
 	{ PCI_VDEVICE(WINBOND, PCI_DEVICE_ID_WINBOND_82C105), },
 
@@ -329,7 +352,11 @@ static struct pci_driver sl82c105_pci_dr
 	.name 		= DRV_NAME,
 	.id_table	= sl82c105,
 	.probe 		= sl82c105_init_one,
-	.remove		= ata_pci_remove_one
+	.remove		= ata_pci_remove_one,
+#ifdef CONFIG_PM
+	.suspend	= ata_pci_device_suspend,
+	.resume		= sl82c105_reinit_one,
+#endif
 };
 
 static int __init sl82c105_init(void)

[PATCH 77/86] pata_sis: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_sis: add 32-bit PIO support

There shouldn't be any problems with it as IDE sis5513 host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_sis.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_sis.c
===================================================================
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -504,14 +504,14 @@ static struct scsi_host_template sis_sht
 };
 
 static struct ata_port_operations sis_133_for_sata_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.set_piomode		= sis_133_set_piomode,
 	.set_dmamode		= sis_133_set_dmamode,
 	.cable_detect		= sis_133_cable_detect,
 };
 
 static struct ata_port_operations sis_base_ops = {
-	.inherits		= &ata_bmdma_port_ops,
+	.inherits		= &ata_bmdma32_port_ops,
 	.prereset		= sis_pre_reset,
 };
 

[PATCH 78/86] pata_sis: Power Management fix

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_sis: Power Management fix

Call sis_fixup() on resume.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_sis.c |   21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_sis.c
===================================================================
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -2,7 +2,7 @@
  *    pata_sis.c - SiS ATA driver
  *
  *	(C) 2005 Red Hat
- *	(C) 2007 Bartlomiej Zolnierkiewicz
+ *	(C) 2007,2009 Bartlomiej Zolnierkiewicz
  *
  *    Based upon linux/drivers/ide/pci/sis5513.c
  * Copyright (C) 1999-2000	Andre Hedrick <andre@linux-ide.org>
@@ -829,6 +829,23 @@ static int sis_init_one (struct pci_dev 
 	return ata_pci_sff_init_one(pdev, ppi, &sis_sht, chipset);
 }
 
+#ifdef CONFIG_PM
+static int sis_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	sis_fixup(pdev, host->private_data);
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 static const struct pci_device_id sis_pci_tbl[] = {
 	{ PCI_VDEVICE(SI, 0x5513), },	/* SiS 5513 */
 	{ PCI_VDEVICE(SI, 0x5518), },	/* SiS 5518 */
@@ -844,7 +861,7 @@ static struct pci_driver sis_pci_driver 
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= ata_pci_device_resume,
+	.resume			= sis_reinit_one,
 #endif
 };
 

[PATCH 79/86] pata_triflex: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_triflex: add 32-bit PIO support

There shouldn't be any problems with it as IDE triflex host driver
has been allowing 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_triflex.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_triflex.c
===================================================================
--- a/drivers/ata/pata_triflex.c
+++ b/drivers/ata/pata_triflex.c
@@ -179,7 +179,7 @@ static struct scsi_host_template triflex
 };
 
 static struct ata_port_operations triflex_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.bmdma_start 	= triflex_bmdma_start,
 	.bmdma_stop	= triflex_bmdma_stop,
 	.cable_detect	= ata_cable_40wire,

[PATCH 80/86] libata: make ata_sff_data_xfer_noirq() work with 32-bit PIO

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] libata: make ata_sff_data_xfer_noirq() work with 32-bit PIO

Always use ata_sff_data_xfer32() in ata_sff_data_xfer_noirq()
so the latter can be also used for host controllers supporting
32-bit PIO operations.

[ It is safe since if 32-bit PIO is not supported or enabled
  ata_sff_data_xfer32() will fallback to a standard method. ]

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/libata-sff.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/libata-sff.c
===================================================================
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -838,7 +838,7 @@ unsigned int ata_sff_data_xfer_noirq(str
 	unsigned int consumed;
 
 	local_irq_save(flags);
-	consumed = ata_sff_data_xfer(dev, buf, buflen, rw);
+	consumed = ata_sff_data_xfer32(dev, buf, buflen, rw);
 	local_irq_restore(flags);
 
 	return consumed;

[PATCH 81/86] pata_via: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_via: add 32-bit PIO support

There shouldn't be any problems with it as IDE via82cxxx host driver
has been using 32-bit PIO operations for years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_via.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -420,7 +420,7 @@ static struct scsi_host_template via_sht
 };
 
 static struct ata_port_operations via_port_ops = {
-	.inherits	= &ata_bmdma_port_ops,
+	.inherits	= &ata_bmdma32_port_ops,
 	.cable_detect	= via_cable_detect,
 	.set_piomode	= via_set_piomode,
 	.set_dmamode	= via_set_dmamode,

[PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

Fix register naming while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_via.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -296,14 +296,21 @@ static void via_do_set_mode(struct ata_p
 	}
 
 	/* Set UDMA unless device is not UDMA capable */
-	if (udma_type && t.udma) {
-		u8 cable80_status;
+	if (udma_type) {
+		u8 udma_etc;
 
-		/* Get 80-wire cable detection bit */
-		pci_read_config_byte(pdev, 0x50 + offset, &cable80_status);
-		cable80_status &= 0x10;
+		pci_read_config_byte(pdev, 0x50 + offset, &udma_etc);
 
-		pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status);
+		/* clear transfer mode bit */
+		udma_etc &= ~0x20;
+
+		if (t.udma) {
+			/* preserve 80-wire cable detection bit */
+			udma_etc &= 0x10;
+			udma_etc |= ut;
+		}
+
+		pci_write_config_byte(pdev, 0x50 + offset, udma_etc);
 	}
 }
 

[PATCH 83/86] pata_via: add via_fixup()

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_via: add via_fixup()

Factor out common code from via_[re]init_one() to via_fixup().

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_via.c |   53 +++++++++++++++++++++----------------------------
 1 file changed, 23 insertions(+), 30 deletions(-)

Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -468,6 +468,27 @@ static void via_config_fifo(struct pci_d
 	}
 }
 
+static void via_fixup(struct pci_dev *pdev, const struct via_isa_bridge *config)
+{
+	u32 timing;
+
+	/* Initialise the FIFO for the enabled channels. */
+	via_config_fifo(pdev, config->flags);
+
+	if ((config->flags & VIA_UDMA) == VIA_UDMA_66) {
+		/* The 66 MHz devices require we enable the clock */
+		pci_read_config_dword(pdev, 0x50, &timing);
+		timing |= 0x80008;
+		pci_write_config_dword(pdev, 0x50, timing);
+	}
+	if (config->flags & VIA_BAD_CLK66) {
+		/* Disable the 66MHz clock on problem devices */
+		pci_read_config_dword(pdev, 0x50, &timing);
+		timing &= ~0x80008;
+		pci_write_config_dword(pdev, 0x50, timing);
+	}
+}
+
 /**
  *	via_init_one		-	discovery callback
  *	@pdev: PCI device
@@ -530,7 +551,6 @@ static int via_init_one(struct pci_dev *
 	const struct via_isa_bridge *config;
 	static int printed_version;
 	u8 enable;
-	u32 timing;
 	unsigned long flags = id->driver_data;
 	int rc;
 
@@ -568,9 +588,6 @@ static int via_init_one(struct pci_dev *
 			return -ENODEV;
 	}
 
-	/* Initialise the FIFO for the enabled channels. */
-	via_config_fifo(pdev, config->flags);
-
 	/* Clock set up */
 	switch(config->flags & VIA_UDMA) {
 		case VIA_UDMA_NONE:
@@ -584,10 +601,6 @@ static int via_init_one(struct pci_dev *
 			break;
 		case VIA_UDMA_66:
 			ppi[0] = &via_udma66_info;
-			/* The 66 MHz devices require we enable the clock */
-			pci_read_config_dword(pdev, 0x50, &timing);
-			timing |= 0x80008;
-			pci_write_config_dword(pdev, 0x50, timing);
 			break;
 		case VIA_UDMA_100:
 			ppi[0] = &via_udma100_info;
@@ -600,12 +613,7 @@ static int via_init_one(struct pci_dev *
 			return -ENODEV;
 	}
 
-	if (config->flags & VIA_BAD_CLK66) {
-		/* Disable the 66MHz clock on problem devices */
-		pci_read_config_dword(pdev, 0x50, &timing);
-		timing &= ~0x80008;
-		pci_write_config_dword(pdev, 0x50, timing);
-	}
+	via_fixup(pdev, config);
 
 	/* We have established the device type, now fire it up */
 	return ata_pci_sff_init_one(pdev, ppi, &via_sht, (void *)config);
@@ -624,29 +632,14 @@ static int via_init_one(struct pci_dev *
 
 static int via_reinit_one(struct pci_dev *pdev)
 {
-	u32 timing;
 	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	const struct via_isa_bridge *config = host->private_data;
 	int rc;
 
 	rc = ata_pci_device_do_resume(pdev);
 	if (rc)
 		return rc;
 
-	via_config_fifo(pdev, config->flags);
-
-	if ((config->flags & VIA_UDMA) == VIA_UDMA_66) {
-		/* The 66 MHz devices require we enable the clock */
-		pci_read_config_dword(pdev, 0x50, &timing);
-		timing |= 0x80008;
-		pci_write_config_dword(pdev, 0x50, timing);
-	}
-	if (config->flags & VIA_BAD_CLK66) {
-		/* Disable the 66MHz clock on problem devices */
-		pci_read_config_dword(pdev, 0x50, &timing);
-		timing &= ~0x80008;
-		pci_write_config_dword(pdev, 0x50, timing);
-	}
+	via_fixup(pdev, host->private_data);
 
 	ata_host_resume(host);
 	return 0;

[PATCH 84/86] libata: add ata_mwdma_to_pio() inline helper

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] libata: add ata_mwdma_to_pio() inline helper

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/ata_piix.c     |   11 ++---------
 drivers/ata/pata_efar.c    |    8 +-------
 drivers/ata/pata_it8213.c  |    8 +-------
 drivers/ata/pata_oldpiix.c |    9 +--------
 drivers/ata/pata_radisys.c |   12 +++---------
 drivers/ata/pata_rdc.c     |   11 ++---------
 include/linux/ata.h        |   11 +++++++++++
 7 files changed, 21 insertions(+), 49 deletions(-)

Index: b/drivers/ata/ata_piix.c
===================================================================
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -831,16 +831,9 @@ static void do_pata_set_dmamode(struct a
 		pci_write_config_byte(dev, 0x48, udma_enable);
 
 		spin_unlock_irqrestore(&piix_lock, flags);
-	} else {
+	} else
 		/* MWDMA is driven by the PIO timings. */
-		unsigned int mwdma = speed - XFER_MW_DMA_0;
-		const unsigned int needed_pio[3] = {
-			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
-		};
-		int pio = needed_pio[mwdma] - XFER_PIO_0;
-
-		piix_set_timings(ap, adev, pio, 1);
-	}
+		piix_set_timings(ap, adev, ata_mwdma_to_pio(speed), 1);
 }
 
 /**
Index: b/drivers/ata/pata_efar.c
===================================================================
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -176,13 +176,7 @@ static void efar_set_dmamode (struct ata
 		pci_write_config_word(dev, 0x4A, udma_timing);
 	} else {
 		/* MWDMA is driven by the PIO timings. */
-		unsigned int mwdma = speed - XFER_MW_DMA_0;
-		const unsigned int needed_pio[3] = {
-			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
-		};
-		int pio = needed_pio[mwdma] - XFER_PIO_0;
-
-		efar_set_timings(ap, adev, pio, 1);
+		efar_set_timings(ap, adev, ata_mwdma_to_pio(speed), 1);
 
 		udma_enable &= ~(1 << devid);
 	}
Index: b/drivers/ata/pata_it8213.c
===================================================================
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -186,13 +186,7 @@ static void it8213_set_dmamode (struct a
 		pci_write_config_word(dev, 0x54, ideconf);
 	} else {
 		/* MWDMA is driven by the PIO timings. */
-		unsigned int mwdma = speed - XFER_MW_DMA_0;
-		static const unsigned int needed_pio[3] = {
-			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
-		};
-		int pio = needed_pio[mwdma] - XFER_PIO_0;
-
-		it8213_set_timings(ap, adev, pio, 1);
+		it8213_set_timings(ap, adev, ata_mwdma_to_pio(speed), 1);
 
 		udma_enable &= ~(1 << devid);
 	}
Index: b/drivers/ata/pata_oldpiix.c
===================================================================
--- a/drivers/ata/pata_oldpiix.c
+++ b/drivers/ata/pata_oldpiix.c
@@ -135,14 +135,7 @@ static void oldpiix_set_piomode(struct a
 static void oldpiix_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 {
 	/* MWDMA is driven by the PIO timings. */
-
-	unsigned int mwdma	= adev->dma_mode - XFER_MW_DMA_0;
-	const unsigned int needed_pio[3] = {
-		XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
-	};
-	int pio = needed_pio[mwdma] - XFER_PIO_0;
-
-	oldpiix_set_timings(ap, adev, pio, 1);
+	oldpiix_set_timings(ap, adev, ata_mwdma_to_pio(adev->dma_mode), 1);
 }
 
 /**
Index: b/drivers/ata/pata_radisys.c
===================================================================
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -102,18 +102,12 @@ static void radisys_set_dmamode (struct
 	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
 	u8 udma_enable;
 
-	/* MWDMA is driven by the PIO timings. */
-
 	pci_read_config_byte(dev, 0x48, &udma_enable);
 
 	if (adev->dma_mode < XFER_UDMA_0) {
-		unsigned int mwdma	= adev->dma_mode - XFER_MW_DMA_0;
-		const unsigned int needed_pio[3] = {
-			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
-		};
-		int pio = needed_pio[mwdma] - XFER_PIO_0;
-
-		radisys_set_timings(ap, adev, pio, 1);
+		/* MWDMA is driven by the PIO timings. */
+		radisys_set_timings(ap, adev,
+				    ata_mwdma_to_pio(adev->dma_mode), 1);
 
 		udma_enable &= ~(1 << adev->devno);
 	} else {
Index: b/drivers/ata/pata_rdc.c
===================================================================
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -227,16 +227,9 @@ static void rdc_set_dmamode(struct ata_p
 		pci_write_config_word(dev, 0x54, ideconf);
 
 		pci_write_config_byte(dev, 0x48, udma_enable);
-	} else {
+	} else
 		/* MWDMA is driven by the PIO timings. */
-		unsigned int mwdma = speed - XFER_MW_DMA_0;
-		const unsigned int needed_pio[3] = {
-			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
-		};
-		int pio = needed_pio[mwdma] - XFER_PIO_0;
-
-		rdc_set_timings(ap, adev, pio, 1);
-	}
+		rdc_set_timings(ap, adev, ata_mwdma_to_pio(speed), 1);
 }
 
 static struct ata_port_operations rdc_pata_ops = {
Index: b/include/linux/ata.h
===================================================================
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -1012,4 +1012,15 @@ static inline int lba_48_ok(u64 block, u
 #define sata_pmp_gscr_rev(gscr)		(((gscr)[SATA_PMP_GSCR_REV] >> 8) & 0xff)
 #define sata_pmp_gscr_ports(gscr)	((gscr)[SATA_PMP_GSCR_PORT_INFO] & 0xf)
 
+/* returns PIO number matching given MWDMA mode */
+static inline u8 ata_mwdma_to_pio(u8 mwdma_mode)
+{
+	unsigned int mwdma = mwdma_mode - XFER_MW_DMA_0;
+	const unsigned int needed_pio[3] = {
+		XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
+	};
+
+	return needed_pio[mwdma] - XFER_PIO_0;
+}
+
 #endif /* __LINUX_ATA_H__ */

[PATCH 85/86] libata: add ->init_host method

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] libata: add ->init_host method

Add ->init_host method for re-initialization of the controller
in ata_pci_device_resume().

Then teach ata_pci_sff_init_one() and host drivers about it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/libata-core.c   |   14 ++++++++++---
 drivers/ata/libata-sff.c    |   10 ++++++---
 drivers/ata/pata_ali.c      |   29 ++++++++-------------------
 drivers/ata/pata_amd.c      |   45 +++++++++++++++++--------------------------
 drivers/ata/pata_artop.c    |   30 ++++++++--------------------
 drivers/ata/pata_cmd640.c   |   27 +++++++------------------
 drivers/ata/pata_cmd64x.c   |   29 +++++++--------------------
 drivers/ata/pata_cs5530.c   |   31 ++++++-----------------------
 drivers/ata/pata_hpt366.c   |   30 +++++++++-------------------
 drivers/ata/pata_hpt3x3.c   |   32 ++++++++++--------------------
 drivers/ata/pata_it821x.c   |   31 +++++++++++------------------
 drivers/ata/pata_ninja32.c  |   30 ++++++++++------------------
 drivers/ata/pata_ns87415.c  |   30 ++++++++--------------------
 drivers/ata/pata_pdc2027x.c |   46 ++++++++++++++------------------------------
 drivers/ata/pata_sl82c105.c |   29 +++++++--------------------
 drivers/ata/sata_sil.c      |   33 ++++++++-----------------------
 include/linux/libata.h      |   14 ++++++++++---
 17 files changed, 173 insertions(+), 317 deletions(-)

Index: b/drivers/ata/libata-core.c
===================================================================
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6426,9 +6426,17 @@ int ata_pci_device_resume(struct pci_dev
 	int rc;
 
 	rc = ata_pci_device_do_resume(pdev);
-	if (rc == 0)
-		ata_host_resume(host);
-	return rc;
+	if (rc)
+		return rc;
+
+	if (host->init_host) {
+		rc = host->init_host(&pdev->dev);
+		if (rc)
+			return rc;
+	}
+
+	ata_host_resume(host);
+	return 0;
 }
 #endif /* CONFIG_PM */
 
Index: b/drivers/ata/libata-sff.c
===================================================================
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -3003,11 +3003,12 @@ out:
 EXPORT_SYMBOL_GPL(ata_pci_sff_activate_host);
 
 /**
- *	ata_pci_sff_init_one - Initialize/register PCI IDE host controller
+ *	__ata_pci_sff_init_one - Initialize/register PCI IDE host controller
  *	@pdev: Controller to be initialized
  *	@ppi: array of port_info, must be enough for two ports
  *	@sht: scsi_host_template to use when registering the host
  *	@host_priv: host private_data
+ *	@init_host: host initialization method (optional)
  *
  *	This is a helper function which can be called from a driver's
  *	xxx_init_one() probe function if the hardware uses traditional
@@ -3027,9 +3028,10 @@ EXPORT_SYMBOL_GPL(ata_pci_sff_activate_h
  *	RETURNS:
  *	Zero on success, negative on errno-based value on error.
  */
-int ata_pci_sff_init_one(struct pci_dev *pdev,
+int __ata_pci_sff_init_one(struct pci_dev *pdev,
 			 const struct ata_port_info * const *ppi,
-			 struct scsi_host_template *sht, void *host_priv)
+			 struct scsi_host_template *sht, void *host_priv,
+			 int (*init_host)(struct device *dev))
 {
 	struct device *dev = &pdev->dev;
 	const struct ata_port_info *pi = NULL;
@@ -3063,7 +3065,9 @@ int ata_pci_sff_init_one(struct pci_dev
 	rc = ata_pci_sff_prepare_host(pdev, ppi, &host);
 	if (rc)
 		goto out;
+
 	host->private_data = host_priv;
+	host->init_host = init_host;
 
 	pci_set_master(pdev);
 	rc = ata_pci_sff_activate_host(host, ata_sff_interrupt, sht);
Index: b/drivers/ata/pata_ali.c
===================================================================
--- a/drivers/ata/pata_ali.c
+++ b/drivers/ata/pata_ali.c
@@ -424,14 +424,15 @@ static struct ata_port_operations ali_c5
 
 /**
  *	ali_init_chipset	-	chip setup function
- *	@pdev: PCI device of ATA controller
+ *	@dev: device of ATA controller
  *
  *	Perform the setup on the device that must be done both at boot
  *	and at resume time.
  */
 
-static void ali_init_chipset(struct pci_dev *pdev)
+static int ali_init_chipset(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
 	u8 tmp;
 	struct pci_dev *north;
 
@@ -478,7 +479,9 @@ static void ali_init_chipset(struct pci_
 	}
 	pci_dev_put(north);
 	ata_pci_bmdma_clear_simplex(pdev);
+	return 0;
 }
+
 /**
  *	ali_init_one		-	discovery callback
  *	@pdev: PCI device ID
@@ -574,7 +577,7 @@ static int ali_init_one(struct pci_dev *
 	} else
         	ppi[0] = &info_c5;
 
-	ali_init_chipset(pdev);
+	ali_init_chipset(&pdev->dev);
 
 	if (ali_isa_bridge && pdev->revision >= 0x20 && pdev->revision < 0xC2) {
 		/* Are we paired with a UDMA capable chip */
@@ -583,23 +586,9 @@ static int ali_init_one(struct pci_dev *
 	        	ppi[0] = &info_20_udma;
 	}
 
-	return ata_pci_sff_init_one(pdev, ppi, &ali_sht, NULL);
-}
-
-#ifdef CONFIG_PM
-static int ali_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-	ali_init_chipset(pdev);
-	ata_host_resume(host);
-	return 0;
+	return __ata_pci_sff_init_one(pdev, ppi, &ali_sht, NULL,
+				      ali_init_chipset);
 }
-#endif
 
 static const struct pci_device_id ali[] = {
 	{ PCI_VDEVICE(AL, PCI_DEVICE_ID_AL_M5228), },
@@ -615,7 +604,7 @@ static struct pci_driver ali_pci_driver
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= ali_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_amd.c
===================================================================
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -455,6 +455,20 @@ static void amd_clear_fifo(struct pci_de
 	pci_write_config_byte(pdev, 0x41, fifo);
 }
 
+static int amd_fixup(struct device *dev)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+
+	if (pdev->vendor == PCI_VENDOR_ID_AMD) {
+		amd_clear_fifo(pdev);
+		if (pdev->device == PCI_DEVICE_ID_AMD_VIPER_7409 ||
+		    pdev->device == PCI_DEVICE_ID_AMD_COBRA_7401)
+			ata_pci_bmdma_clear_simplex(pdev);
+	}
+
+	return 0;
+}
+
 static int amd_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	static const struct ata_port_info info[10] = {
@@ -559,10 +573,8 @@ static int amd_init_one(struct pci_dev *
 	 */
 	ppi[0] = &info[type];
 
-	if (type < 3)
-		ata_pci_bmdma_clear_simplex(pdev);
-	if (pdev->vendor == PCI_VENDOR_ID_AMD)
-		amd_clear_fifo(pdev);
+	amd_fixup(&pdev->dev);
+
 	/* Cable detection on Nvidia chips doesn't work too well,
 	 * cache BIOS programmed UDMA mode.
 	 */
@@ -574,30 +586,9 @@ static int amd_init_one(struct pci_dev *
 	}
 
 	/* And fire it up */
-	return ata_pci_sff_init_one(pdev, ppi, &amd_sht, hpriv);
+	return __ata_pci_sff_init_one(pdev, ppi, &amd_sht, hpriv, amd_fixup);
 }
 
-#ifdef CONFIG_PM
-static int amd_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-
-	if (pdev->vendor == PCI_VENDOR_ID_AMD) {
-		amd_clear_fifo(pdev);
-		if (pdev->device == PCI_DEVICE_ID_AMD_VIPER_7409 ||
-		    pdev->device == PCI_DEVICE_ID_AMD_COBRA_7401)
-			ata_pci_bmdma_clear_simplex(pdev);
-	}
-	ata_host_resume(host);
-	return 0;
-}
-#endif
-
 static const struct pci_device_id amd[] = {
 	{ PCI_VDEVICE(AMD,	PCI_DEVICE_ID_AMD_COBRA_7401),		0 },
 	{ PCI_VDEVICE(AMD,	PCI_DEVICE_ID_AMD_VIPER_7409),		1 },
@@ -630,7 +621,7 @@ static struct pci_driver amd_pci_driver
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= amd_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_artop.c
===================================================================
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -302,8 +302,10 @@ static struct ata_port_operations atp86x
 	.prereset		= atp8xx_prereset,
 };
 
-static void atp8xx_fixup(struct pci_dev *pdev)
+static int atp8xx_fixup(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
+
 	if (pdev->device == 0x0005)
 		/* BIOS may have left us in UDMA, clear it before probe */
 		pci_write_config_byte(pdev, 0x54, 0);
@@ -328,6 +330,8 @@ static void atp8xx_fixup(struct pci_dev
 		pci_read_config_byte(pdev, 0x4a, &reg);
 		pci_write_config_byte(pdev, 0x4a, (reg & ~0x01) | 0x80);
 	}
+
+	return 0;
 }
 
 /**
@@ -400,28 +404,12 @@ static int artop_init_one (struct pci_de
 
 	BUG_ON(ppi[0] == NULL);
 
-	atp8xx_fixup(pdev);
+	atp8xx_fixup(&pdev->dev);
 
-	return ata_pci_sff_init_one(pdev, ppi, &artop_sht, NULL);
+	return __ata_pci_sff_init_one(pdev, ppi, &artop_sht, NULL,
+				      atp8xx_fixup);
 }
 
-#ifdef CONFIG_PM
-static int atp8xx_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-
-	atp8xx_fixup(pdev);
-
-	ata_host_resume(host);
-	return 0;
-}
-#endif
-
 static const struct pci_device_id artop_pci_tbl[] = {
 	{ PCI_VDEVICE(ARTOP, 0x0005), 0 },
 	{ PCI_VDEVICE(ARTOP, 0x0006), 1 },
@@ -439,7 +427,7 @@ static struct pci_driver artop_pci_drive
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= atp8xx_reinit_one,
+	.resume			= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_cmd640.c
===================================================================
--- a/drivers/ata/pata_cmd640.c
+++ b/drivers/ata/pata_cmd640.c
@@ -178,8 +178,9 @@ static struct ata_port_operations cmd640
 	.port_start	= cmd640_port_start,
 };
 
-static void cmd640_hardware_init(struct pci_dev *pdev)
+static int cmd640_hardware_init(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
 	u8 r;
 	u8 ctrl;
 
@@ -205,6 +206,8 @@ static void cmd640_hardware_init(struct
 	pci_read_config_byte(pdev, ARTIM23, &ctrl);
 	ctrl |= 0x0C;
 	pci_write_config_byte(pdev, ARTIM23, ctrl);
+
+	return 0;
 }
 
 static int cmd640_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
@@ -221,25 +224,11 @@ static int cmd640_init_one(struct pci_de
 	if (rc)
 		return rc;
 
-	cmd640_hardware_init(pdev);
-
-	return ata_pci_sff_init_one(pdev, ppi, &cmd640_sht, NULL);
-}
-
-#ifdef CONFIG_PM
-static int cmd640_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
+	cmd640_hardware_init(&pdev->dev);
 
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-	cmd640_hardware_init(pdev);
-	ata_host_resume(host);
-	return 0;
+	return __ata_pci_sff_init_one(pdev, ppi, &cmd640_sht, NULL,
+				      cmd640_hardware_init);
 }
-#endif
 
 static const struct pci_device_id cmd640[] = {
 	{ PCI_VDEVICE(CMD, 0x640), 0 },
@@ -253,7 +242,7 @@ static struct pci_driver cmd640_pci_driv
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= cmd640_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_cmd64x.c
===================================================================
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -328,8 +328,9 @@ static struct ata_port_operations cmd648
 	.cable_detect	= cmd648_cable_detect,
 };
 
-static void cmd64x_fixup(struct pci_dev *pdev)
+static int cmd64x_fixup(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
 	u8 mrdmode;
 
 	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 64);
@@ -342,6 +343,8 @@ static void cmd64x_fixup(struct pci_dev
 #ifdef CONFIG_PPC
 	pci_write_config_byte(pdev, UDIDETCR0, 0xF0);
 #endif
+
+	return 0;
 }
 
 static int cmd64x_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
@@ -411,27 +414,11 @@ static int cmd64x_init_one(struct pci_de
 			ppi[0] = &cmd_info[3];
 	}
 
-	cmd64x_fixup(pdev);
-
-	return ata_pci_sff_init_one(pdev, ppi, &cmd64x_sht, NULL);
-}
-
-#ifdef CONFIG_PM
-static int cmd64x_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
+	cmd64x_fixup(&pdev->dev);
 
-	cmd64x_fixup(pdev);
-
-	ata_host_resume(host);
-	return 0;
+	return __ata_pci_sff_init_one(pdev, ppi, &cmd64x_sht, NULL,
+				      cmd64x_fixup);
 }
-#endif
 
 static const struct pci_device_id cmd64x[] = {
 	{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_643), 0 },
@@ -449,7 +436,7 @@ static struct pci_driver cmd64x_pci_driv
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= cmd64x_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_cs5530.c
===================================================================
--- a/drivers/ata/pata_cs5530.c
+++ b/drivers/ata/pata_cs5530.c
@@ -198,12 +198,13 @@ static int cs5530_is_palmax(void)
 
 /**
  *	cs5530_init_chip	-	Chipset init
+ *	@gendev: device
  *
  *	Perform the chip initialisation work that is shared between both
  *	setup and resume paths
  */
 
-static int cs5530_init_chip(void)
+static int cs5530_init_chip(struct device *gendev)
 {
 	struct pci_dev *master_0 = NULL, *cs5530_0 = NULL, *dev = NULL;
 
@@ -281,7 +282,7 @@ fail_put:
 		pci_dev_put(master_0);
 	if (cs5530_0)
 		pci_dev_put(cs5530_0);
-	return -ENODEV;
+	return -EIO;
 }
 
 /**
@@ -317,35 +318,17 @@ static int cs5530_init_one(struct pci_de
 		return rc;
 
 	/* Chip initialisation */
-	if (cs5530_init_chip())
+	if (cs5530_init_chip(NULL))
 		return -ENODEV;
 
 	if (cs5530_is_palmax())
 		ppi[1] = &info_palmax_secondary;
 
 	/* Now kick off ATA set up */
-	return ata_pci_sff_init_one(pdev, ppi, &cs5530_sht, NULL);
+	return __ata_pci_sff_init_one(pdev, ppi, &cs5530_sht, NULL,
+				      cs5530_init_chip);
 }
 
-#ifdef CONFIG_PM
-static int cs5530_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-
-	/* If we fail on resume we are doomed */
-	if (cs5530_init_chip())
-		return -EIO;
-
-	ata_host_resume(host);
-	return 0;
-}
-#endif /* CONFIG_PM */
-
 static const struct pci_device_id cs5530[] = {
 	{ PCI_VDEVICE(CYRIX, PCI_DEVICE_ID_CYRIX_5530_IDE), },
 
@@ -359,7 +342,7 @@ static struct pci_driver cs5530_pci_driv
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= cs5530_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_hpt366.c
===================================================================
--- a/drivers/ata/pata_hpt366.c
+++ b/drivers/ata/pata_hpt366.c
@@ -292,15 +292,17 @@ static struct ata_port_operations hpt366
 
 /**
  *	hpt36x_init_chipset	-	common chip setup
- *	@dev: PCI device
+ *	@gendev: device
  *
  *	Perform the chip setup work that must be done at both init and
  *	resume time
  */
 
-static void hpt36x_init_chipset(struct pci_dev *dev)
+static int hpt36x_init_chipset(struct device *gendev)
 {
+	struct pci_dev *dev = to_pci_dev(gendev);
 	u8 drive_fast;
+
 	pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, (L1_CACHE_BYTES / 4));
 	pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x78);
 	pci_write_config_byte(dev, PCI_MIN_GNT, 0x08);
@@ -309,6 +311,8 @@ static void hpt36x_init_chipset(struct p
 	pci_read_config_byte(dev, 0x51, &drive_fast);
 	if (drive_fast & 0x80)
 		pci_write_config_byte(dev, 0x51, drive_fast & ~0x80);
+
+	return 0;
 }
 
 /**
@@ -360,7 +364,7 @@ static int hpt36x_init_one(struct pci_de
 	if (class_rev > 2)
 			return -ENODEV;
 
-	hpt36x_init_chipset(dev);
+	hpt36x_init_chipset(&dev->dev);
 
 	pci_read_config_dword(dev, 0x40,  &reg1);
 
@@ -378,23 +382,9 @@ static int hpt36x_init_one(struct pci_de
 			break;
 	}
 	/* Now kick off ATA set up */
-	return ata_pci_sff_init_one(dev, ppi, &hpt36x_sht, hpriv);
-}
-
-#ifdef CONFIG_PM
-static int hpt36x_reinit_one(struct pci_dev *dev)
-{
-	struct ata_host *host = dev_get_drvdata(&dev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(dev);
-	if (rc)
-		return rc;
-	hpt36x_init_chipset(dev);
-	ata_host_resume(host);
-	return 0;
+	return __ata_pci_sff_init_one(dev, ppi, &hpt36x_sht, hpriv,
+				      hpt36x_init_chipset);
 }
-#endif
 
 static const struct pci_device_id hpt36x[] = {
 	{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT366), },
@@ -408,7 +398,7 @@ static struct pci_driver hpt36x_pci_driv
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= hpt36x_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_hpt3x3.c
===================================================================
--- a/drivers/ata/pata_hpt3x3.c
+++ b/drivers/ata/pata_hpt3x3.c
@@ -156,14 +156,16 @@ static struct ata_port_operations hpt3x3
 
 /**
  *	hpt3x3_init_chipset	-	chip setup
- *	@dev: PCI device
+ *	@gendev: device
  *
  *	Perform the setup required at boot and on resume.
  */
 
-static void hpt3x3_init_chipset(struct pci_dev *dev)
+static int hpt3x3_init_chipset(struct device *gendev)
 {
+	struct pci_dev *dev = to_pci_dev(gendev);
 	u16 cmd;
+
 	/* Initialize the board */
 	pci_write_config_word(dev, 0x80, 0x00);
 	/* Check if it is a 343 or a 363. 363 has COMMAND_MEMORY set */
@@ -172,6 +174,8 @@ static void hpt3x3_init_chipset(struct p
 		pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0xF0);
 	else
 		pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x20);
+
+	return 0;
 }
 
 /**
@@ -204,7 +208,7 @@ static int hpt3x3_init_one(struct pci_de
 	int i, rc;
 	void __iomem *base;
 
-	hpt3x3_init_chipset(pdev);
+	hpt3x3_init_chipset(&pdev->dev);
 
 	if (!printed_version++)
 		dev_printk(KERN_DEBUG, &pdev->dev, "version " DRV_VERSION "\n");
@@ -212,6 +216,9 @@ static int hpt3x3_init_one(struct pci_de
 	host = ata_host_alloc_pinfo(&pdev->dev, ppi, 2);
 	if (!host)
 		return -ENOMEM;
+
+	host->init_host = hpt3x3_init_chipset;
+
 	/* acquire resources and fill host */
 	rc = pcim_enable_device(pdev);
 	if (rc)
@@ -252,23 +259,6 @@ static int hpt3x3_init_one(struct pci_de
 				 IRQF_SHARED, &hpt3x3_sht);
 }
 
-#ifdef CONFIG_PM
-static int hpt3x3_reinit_one(struct pci_dev *dev)
-{
-	struct ata_host *host = dev_get_drvdata(&dev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(dev);
-	if (rc)
-		return rc;
-
-	hpt3x3_init_chipset(dev);
-
-	ata_host_resume(host);
-	return 0;
-}
-#endif
-
 static const struct pci_device_id hpt3x3[] = {
 	{ PCI_VDEVICE(TTI, PCI_DEVICE_ID_TTI_HPT343), },
 
@@ -282,7 +272,7 @@ static struct pci_driver hpt3x3_pci_driv
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= hpt3x3_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_it821x.c
===================================================================
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -868,6 +868,15 @@ static void it821x_disable_raid(struct p
 	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x20);
 }
 
+static int it821x_fixup(struct device *dev)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+
+	if (pdev->vendor != PCI_VENDOR_ID_RDC && it8212_noraid)
+		it821x_disable_raid(pdev);
+
+	return 0;
+}
 
 static int it821x_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 {
@@ -932,26 +941,10 @@ static int it821x_init_one(struct pci_de
 		else
 			ppi[0] = &info_smart;
 	}
-	return ata_pci_sff_init_one(pdev, ppi, &it821x_sht, NULL);
+	return __ata_pci_sff_init_one(pdev, ppi, &it821x_sht, NULL,
+				      it821x_fixup);
 }
 
-#ifdef CONFIG_PM
-static int it821x_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-	/* Resume - turn raid back off if need be */
-	if (it8212_noraid)
-		it821x_disable_raid(pdev);
-	ata_host_resume(host);
-	return rc;
-}
-#endif
-
 static const struct pci_device_id it821x[] = {
 	{ PCI_VDEVICE(ITE, PCI_DEVICE_ID_ITE_8211), },
 	{ PCI_VDEVICE(ITE, PCI_DEVICE_ID_ITE_8212), },
@@ -967,7 +960,7 @@ static struct pci_driver it821x_pci_driv
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= it821x_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_ninja32.c
===================================================================
--- a/drivers/ata/pata_ninja32.c
+++ b/drivers/ata/pata_ninja32.c
@@ -89,8 +89,11 @@ static struct ata_port_operations ninja3
 	.sff_data_xfer	= ata_sff_data_xfer32
 };
 
-static void ninja32_program(void __iomem *base)
+static int ninja32_program(struct device *dev)
 {
+	struct ata_host *host = dev_get_drvdata(dev);
+	void __iomem *base = host->iomap[0];
+
 	iowrite8(0x05, base + 0x01);	/* Enable interrupt lines */
 	iowrite8(0xBE, base + 0x02);	/* Burst, ?? setup */
 	iowrite8(0x01, base + 0x03);	/* Unknown */
@@ -98,6 +101,8 @@ static void ninja32_program(void __iomem
 	iowrite8(0x8f, base + 0x05);	/* Unknown */
 	iowrite8(0xa4, base + 0x1c);	/* Unknown */
 	iowrite8(0x83, base + 0x1d);	/* BMDMA control: WAIT0 */
+
+	return 0;
 }
 
 static int ninja32_init_one(struct pci_dev *dev, const struct pci_device_id *id)
@@ -110,6 +115,8 @@ static int ninja32_init_one(struct pci_d
 	host = ata_host_alloc(&dev->dev, 1);
 	if (!host)
 		return -ENOMEM;
+
+	host->init_host = ninja32_program;
 	ap = host->ports[0];
 
 	/* Set up the PCI device */
@@ -147,28 +154,13 @@ static int ninja32_init_one(struct pci_d
 	ata_sff_std_ports(&ap->ioaddr);
 	ap->pflags = ATA_PFLAG_PIO32 | ATA_PFLAG_PIO32CHANGE;
 
-	ninja32_program(base);
+	ninja32_program(&dev->dev);
+
 	/* FIXME: Should we disable them at remove ? */
 	return ata_host_activate(host, dev->irq, ata_sff_interrupt,
 				 IRQF_SHARED, &ninja32_sht);
 }
 
-#ifdef CONFIG_PM
-
-static int ninja32_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-	ninja32_program(host->iomap[0]);
-	ata_host_resume(host);
-	return 0;			
-}
-#endif
-
 static const struct pci_device_id ninja32[] = {
 	{ 0x10FC, 0x0003, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
 	{ 0x1145, 0x8008, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
@@ -186,7 +178,7 @@ static struct pci_driver ninja32_pci_dri
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= ninja32_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_ns87415.c
===================================================================
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -325,12 +325,16 @@ static struct scsi_host_template ns87415
 	ATA_BMDMA_SHT(DRV_NAME),
 };
 
-static void ns87415_fixup(struct pci_dev *pdev)
+static int ns87415_fixup(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
+
 	/* Select 512 byte sectors */
 	pci_write_config_byte(pdev, 0x55, 0xEE);
 	/* Select PIO0 8bit clocking */
 	pci_write_config_byte(pdev, 0x54, 0xB7);
+
+	return 0;
 }
 
 /**
@@ -378,9 +382,10 @@ static int ns87415_init_one (struct pci_
 	if (rc)
 		return rc;
 
-	ns87415_fixup(pdev);
+	ns87415_fixup(&pdev->dev);
 
-	return ata_pci_sff_init_one(pdev, ppi, &ns87415_sht, NULL);
+	return __ata_pci_sff_init_one(pdev, ppi, &ns87415_sht, NULL,
+				      ns87415_fixup);
 }
 
 static const struct pci_device_id ns87415_pci_tbl[] = {
@@ -389,23 +394,6 @@ static const struct pci_device_id ns8741
 	{ }	/* terminate list */
 };
 
-#ifdef CONFIG_PM
-static int ns87415_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-
-	ns87415_fixup(pdev);
-
-	ata_host_resume(host);
-	return 0;
-}
-#endif
-
 static struct pci_driver ns87415_pci_driver = {
 	.name			= DRV_NAME,
 	.id_table		= ns87415_pci_tbl,
@@ -413,7 +401,7 @@ static struct pci_driver ns87415_pci_dri
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= ns87415_reinit_one,
+	.resume			= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/pata_pdc2027x.c
===================================================================
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -63,7 +63,6 @@ enum {
 };
 
 static int pdc2027x_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
-static int pdc2027x_reinit_one(struct pci_dev *pdev);
 static int pdc2027x_prereset(struct ata_link *link, unsigned long deadline);
 static void pdc2027x_set_piomode(struct ata_port *ap, struct ata_device *adev);
 static void pdc2027x_set_dmamode(struct ata_port *ap, struct ata_device *adev);
@@ -129,7 +128,7 @@ static struct pci_driver pdc2027x_pci_dr
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= pdc2027x_reinit_one,
+	.resume			= ata_pci_device_resume,
 #endif
 };
 
@@ -647,13 +646,21 @@ static long pdc_detect_pll_input_clock(s
 
 /**
  * pdc_hardware_init - Initialize the hardware.
- * @host: target ATA host
- * @board_idx: board identifier
+ * @dev: device
  */
-static int pdc_hardware_init(struct ata_host *host, unsigned int board_idx)
+static int pdc_hardware_init(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
+	struct ata_host *host = dev_get_drvdata(dev);
+	unsigned int board_idx;
 	long pll_clock;
 
+	if (pdev->device == PCI_DEVICE_ID_PROMISE_20268 ||
+	    pdev->device == PCI_DEVICE_ID_PROMISE_20270)
+		board_idx = PDC_UDMA_100;
+	else
+		board_idx = PDC_UDMA_133;
+
 	/*
 	 * Detect PLL input clock rate.
 	 * On some system, where PCI bus is running at non-standard clock rate.
@@ -722,6 +729,8 @@ static int __devinit pdc2027x_init_one(s
 	if (!host)
 		return -ENOMEM;
 
+	host->init_host = pdc_hardware_init;
+
 	/* acquire resources and fill host */
 	rc = pcim_enable_device(pdev);
 	if (rc)
@@ -755,7 +764,7 @@ static int __devinit pdc2027x_init_one(s
 	//pci_enable_intx(pdev);
 
 	/* initialize adapter */
-	if (pdc_hardware_init(host, board_idx) != 0)
+	if (pdc_hardware_init(&pdev->dev))
 		return -EIO;
 
 	pci_set_master(pdev);
@@ -763,31 +772,6 @@ static int __devinit pdc2027x_init_one(s
 				 IRQF_SHARED, &pdc2027x_sht);
 }
 
-#ifdef CONFIG_PM
-static int pdc2027x_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	unsigned int board_idx;
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-
-	if (pdev->device == PCI_DEVICE_ID_PROMISE_20268 ||
-	    pdev->device == PCI_DEVICE_ID_PROMISE_20270)
-		board_idx = PDC_UDMA_100;
-	else
-		board_idx = PDC_UDMA_133;
-
-	if (pdc_hardware_init(host, board_idx))
-		return -EIO;
-
-	ata_host_resume(host);
-	return 0;
-}
-#endif
-
 /**
  * pdc2027x_init - Called after this module is loaded into the kernel.
  */
Index: b/drivers/ata/pata_sl82c105.c
===================================================================
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -279,13 +279,16 @@ static int sl82c105_bridge_revision(stru
 	return bridge->revision;
 }
 
-static void sl82c105_fixup(struct pci_dev *pdev)
+static int sl82c105_fixup(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
 	u32 val;
 
 	pci_read_config_dword(pdev, 0x40, &val);
 	val |= CTRL_P0EN | CTRL_P0F16 | CTRL_P1F16;
 	pci_write_config_dword(pdev, 0x40, val);
+
+	return 0;
 }
 
 static int sl82c105_init_one(struct pci_dev *dev, const struct pci_device_id *id)
@@ -320,27 +323,11 @@ static int sl82c105_init_one(struct pci_
 	else
 		ppi[0] = &info_dma;
 
-	sl82c105_fixup(dev);
-
-	return ata_pci_sff_init_one(dev, ppi, &sl82c105_sht, NULL);
-}
-
-#ifdef CONFIG_PM
-static int sl82c105_reinit_one(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
+	sl82c105_fixup(&dev->dev);
 
-	sl82c105_fixup(pdev);
-
-	ata_host_resume(host);
-	return 0;
+	return __ata_pci_sff_init_one(dev, ppi, &sl82c105_sht, NULL,
+				      sl82c105_fixup);
 }
-#endif
 
 static const struct pci_device_id sl82c105[] = {
 	{ PCI_VDEVICE(WINBOND, PCI_DEVICE_ID_WINBOND_82C105), },
@@ -355,7 +342,7 @@ static struct pci_driver sl82c105_pci_dr
 	.remove		= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend	= ata_pci_device_suspend,
-	.resume		= sl82c105_reinit_one,
+	.resume		= ata_pci_device_resume,
 #endif
 };
 
Index: b/drivers/ata/sata_sil.c
===================================================================
--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -114,9 +114,6 @@ enum {
 };
 
 static int sil_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
-#ifdef CONFIG_PM
-static int sil_pci_device_resume(struct pci_dev *pdev);
-#endif
 static void sil_dev_config(struct ata_device *dev);
 static int sil_scr_read(struct ata_link *link, unsigned int sc_reg, u32 *val);
 static int sil_scr_write(struct ata_link *link, unsigned int sc_reg, u32 val);
@@ -169,7 +166,7 @@ static struct pci_driver sil_pci_driver
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= sil_pci_device_resume,
+	.resume			= ata_pci_device_resume,
 #endif
 };
 
@@ -663,9 +660,10 @@ static void sil_dev_config(struct ata_de
 	}
 }
 
-static void sil_init_controller(struct ata_host *host)
+static int sil_init_controller(struct device *dev)
 {
-	struct pci_dev *pdev = to_pci_dev(host->dev);
+	struct ata_host *host = dev_get_drvdata(dev);
+	struct pci_dev *pdev = to_pci_dev(dev);
 	void __iomem *mmio_base = host->iomap[SIL_MMIO_BAR];
 	u8 cls;
 	u32 tmp;
@@ -707,6 +705,8 @@ static void sil_init_controller(struct a
 			writel(tmp | SIL_INTR_STEERING,
 			       mmio_base + sil_port[2].bmdma);
 	}
+
+	return 0;
 }
 
 static bool sil_broken_system_poweroff(struct pci_dev *pdev)
@@ -765,6 +765,8 @@ static int sil_init_one(struct pci_dev *
 	if (!host)
 		return -ENOMEM;
 
+	host->init_host = sil_init_controller;
+
 	/* acquire resources and fill host */
 	rc = pcim_enable_device(pdev);
 	if (rc)
@@ -802,30 +804,13 @@ static int sil_init_one(struct pci_dev *
 	}
 
 	/* initialize and activate */
-	sil_init_controller(host);
+	sil_init_controller(&pdev->dev);
 
 	pci_set_master(pdev);
 	return ata_host_activate(host, pdev->irq, sil_interrupt, IRQF_SHARED,
 				 &sil_sht);
 }
 
-#ifdef CONFIG_PM
-static int sil_pci_device_resume(struct pci_dev *pdev)
-{
-	struct ata_host *host = dev_get_drvdata(&pdev->dev);
-	int rc;
-
-	rc = ata_pci_device_do_resume(pdev);
-	if (rc)
-		return rc;
-
-	sil_init_controller(host);
-	ata_host_resume(host);
-
-	return 0;
-}
-#endif
-
 static int __init sil_init(void)
 {
 	return pci_register_driver(&sil_pci_driver);
Index: b/include/linux/libata.h
===================================================================
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -526,6 +526,7 @@ struct ata_host {
 	unsigned int		n_ports;
 	void			*private_data;
 	struct ata_port_operations *ops;
+	int			(*init_host)(struct device *dev);
 	unsigned long		flags;
 #ifdef CONFIG_ATA_ACPI
 	acpi_handle		acpi_handle;
@@ -1637,9 +1638,16 @@ extern int ata_pci_sff_prepare_host(stru
 extern int ata_pci_sff_activate_host(struct ata_host *host,
 				     irq_handler_t irq_handler,
 				     struct scsi_host_template *sht);
-extern int ata_pci_sff_init_one(struct pci_dev *pdev,
-				const struct ata_port_info * const * ppi,
-				struct scsi_host_template *sht, void *host_priv);
+extern int __ata_pci_sff_init_one(struct pci_dev *pdev,
+				const struct ata_port_info * const *ppi,
+				struct scsi_host_template *sht, void *host_priv,
+				int (*init_host)(struct device *dev));
+static inline int ata_pci_sff_init_one(struct pci_dev *pdev,
+				const struct ata_port_info * const *ppi,
+				struct scsi_host_template *sht, void *host_priv)
+{
+	return __ata_pci_sff_init_one(pdev, ppi, sht, host_priv, NULL);
+}
 #endif /* CONFIG_PCI */
 
 /**

Re: [PATCH 03/86] pata_artop: add 32-bit PIO support

[Alan Cox]

On Wed, 25 Nov 2009 18:02:39 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_artop: add 32-bit PIO support
> 
> There shouldn't be any problems with it as IDE aec62xx host driver
> has been allowing 32-bit PIO operations for years.

Allowing or defaulting too ?

[PATCH 86/86] libata: add private driver field to struct ata_device

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] libata: add private driver field to struct ata_device

This brings struct ata_device in-line with struct ata_{port,host}.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 include/linux/libata.h |    1 +
 1 file changed, 1 insertion(+)

Index: b/include/linux/libata.h
===================================================================
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -585,6 +585,7 @@ struct ata_device {
 	unsigned int		horkage;	/* List of broken features */
 	unsigned long		flags;		/* ATA_DFLAG_xxx */
 	struct scsi_device	*sdev;		/* attached SCSI device */
+	void			*private_data;
 #ifdef CONFIG_ATA_ACPI
 	acpi_handle		acpi_handle;
 	union acpi_object	*gtf_cache;

Re: [PATCH 12/86] pata_atiixp: add proper ->prereset method

[Alan Cox]

On Wed, 25 Nov 2009 18:03:44 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_atiixp: add proper ->prereset method
> 

The original seems cleaner here.

Re: [PATCH 03/86] pata_artop: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:12:42 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:02:39 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] pata_artop: add 32-bit PIO support
> > 
> > There shouldn't be any problems with it as IDE aec62xx host driver
> > has been allowing 32-bit PIO operations for years.
> 
> Allowing or defaulting too ?

For aec62xx: allowing, for some other drivers: defaulting ('using'
in the patch description instead of 'allowing').  However some
popular distributions have been defaulting to always enabling it
if was supported by the driver.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> I've been going through PATA drivers for the last few days to make
> sure that we offer similar level of hardware support in the new PATA
> drivers as with the old IDE subsystem and the following patchset is
> the end result of said audit.

Thanks!

> - add 32-bit PIO support for more controllers
>
>    ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
>      pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
>      pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
>      pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
>      pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
>      pata_sis, pata_triflex&  pata_via )

This should be all in one patch.

I'll let the comments from Alan and others trickle in before applying...

> - add ->init_host method for abstracting host specific controller
>   initialization and then use it to cleanup Power Managment code
>   resulting in over 100 LOC gone
>
>   ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
>     pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
>     pata_ns87415, pata_pdc2027x & sata_sil )

hmmmm....  will reserve comment until I review it thoroughly, but I am a 
bit reluctant to move away from the current struct-driver style driver 
init/setup model.

	Jeff

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:19:49 pm Jeff Garzik wrote:
> On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > I've been going through PATA drivers for the last few days to make
> > sure that we offer similar level of hardware support in the new PATA
> > drivers as with the old IDE subsystem and the following patchset is
> > the end result of said audit.
> 
> Thanks!
> 
> > - add 32-bit PIO support for more controllers
> >
> >    ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
> >      pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
> >      pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
> >      pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
> >      pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
> >      pata_sis, pata_triflex&  pata_via )
> 
> This should be all in one patch.

For review & testing purposes it is better do it this way, I can merge
individual patches easily later if desirable.

> I'll let the comments from Alan and others trickle in before applying...

See comment above.

> > - add ->init_host method for abstracting host specific controller
> >   initialization and then use it to cleanup Power Managment code
> >   resulting in over 100 LOC gone
> >
> >   ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
> >     pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
> >     pata_ns87415, pata_pdc2027x & sata_sil )
> 
> hmmmm....  will reserve comment until I review it thoroughly, but I am a 
> bit reluctant to move away from the current struct-driver style driver 
> init/setup model.

This change is not moving away from it.  On the contrary -- it enhances
the current model by adding another possibility of doing things as the new
->init_host method is completely optional.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 17/86] pata_efar: fix register naming used in efar_set_piomode()

[Alan Cox]

> Rename 'idetm_port' and 'idetm_data' variables to 'master_port'
> and 'master_data' respectively to match register naming used in
> efar_set_dma_mode() and in ata_piix.c.

Probably better to do the reverse to match the docs ?

> -	u16 idetm_data;
> +	u8 master_port		= ap->port_no ? 0x42 : 0x40;
> +	u16 master_data;

Please don't drop undocumented type changes in. And btw it uses unsigned
int here as all over the kernel because it produced better code in many
cases

These patches seem to spend a lot of time renaming everything in drivers
which is usually pointless churn (eg the atp grand renaming), but the bug
fixes all look good

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Alan Cox]

On Wed, 25 Nov 2009 18:04:15 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_efar: MWDMA0 is unsupported
> 
> MWDMA0 timings cannot be met with the PIIX based controller
> programming interface.

The efar documentation makes no reference to not being capable of MWDMA0,
so where does this come from ? No MWDMA0 is an Intel erratum it appears.

Re: [PATCH 09/86] pata_atiixp: no need to program PIO timings for MWDMA

[Alan Cox]

On Wed, 25 Nov 2009 18:03:23 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_atiixp: no need to program PIO timings for MWDMA
> 
> Moreover the code to do it was buggy and programmed PIO timings
> even if they were already set to a desired values.
> 
> There shouldn't be any problems with it as IDE atiixp host driver
> has been allowing separate PIO/MWDMA timings for last two years.

I need to take a look at the history of this - it got put there for a
reason I am sure. Whether a right one I don't know. Needs running past
AMD/ATI's maintainer anyway who should know.

Re: [PATCH 19/86] pata_cmd640: document known issues

[Alan Cox]

On Wed, 25 Nov 2009 18:04:36 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_cmd640: document known issues
> 
> Document known issues with the driver to aid distribution makers,
> users and developers in making informed decisions instead of wasting
> their time needlessly.

Umm. its a) under CONFIG_PCI, and b) says CMD640 PCI IDE...

Re: [PATCH 24/86] pata_cs5520: remove dead VDMA support

[Alan Cox]

On Wed, 25 Nov 2009 18:05:11 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_cs5520: remove dead VDMA support
> 
> It has been dead for the last three years (== since the initial driver
> merge) and probability that it will ever get fixed is quite low.

Agreed entirely. SIL680 VDMA might be worth doing and in turn CS5520 in
passing but CS5520 is mostly an ex-chip

Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present

[Alan Cox]

On Wed, 25 Nov 2009 18:07:40 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_legacy: do not probe extra ports automatically if PCI is not present
> 
> It can be problematic if there are other ISA/VLB devices using
> those ports.

NAK. You made a rather peculiar set of changes in the IDE layer but the
PCI handling in pata_legacy includes knowledge of the various half-pci
devices and on a non PCI system 0x1E8/0x168 are reserved for extra IDE.

We've had no complaints at all, ever about this.

> This is a forward port of bugfix from IDE ide-generic host driver.

Of a bug.

Alan

Re: [PATCH 17/86] pata_efar: fix register naming used in efar_set_piomode()

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:25:41 pm Alan Cox wrote:
> > Rename 'idetm_port' and 'idetm_data' variables to 'master_port'
> > and 'master_data' respectively to match register naming used in
> > efar_set_dma_mode() and in ata_piix.c.
> 
> Probably better to do the reverse to match the docs ?

It just matches ata_piix.c code currently.

> > -	u16 idetm_data;
> > +	u8 master_port		= ap->port_no ? 0x42 : 0x40;
> > +	u16 master_data;
> 
> Please don't drop undocumented type changes in. And btw it uses unsigned

Oh, I forgot to document it in this patch.  Others should have it documented.

[ Will fix later. ]

> int here as all over the kernel because it produced better code in many
> cases

Better code is smaller code in this situation and this is clearly minor
issue anyway (since the code is not performance critical having cleaner
code wins over).

> These patches seem to spend a lot of time renaming everything in drivers

It just prepares the code for unification of code programming PIO and MWDMA
methods, see patch #18.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 19/86] pata_cmd640: document known issues

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:26:33 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:04:36 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] pata_cmd640: document known issues
> > 
> > Document known issues with the driver to aid distribution makers,
> > users and developers in making informed decisions instead of wasting
> > their time needlessly.
> 
> Umm. its a) under CONFIG_PCI, and b) says CMD640 PCI IDE...

c)

 *      This drives only the PCI version of the controller. If you have a
 *      VLB one then we have enough docs to support it but you can write
 *      your own code.

Then what has happened to CMD640 VLB IDE support in libata?

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 11/86] pata_atiixp: remove custom BMDMA methods

[Alan Cox]

On Wed, 25 Nov 2009 18:03:37 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_atiixp: remove custom BMDMA methods
> 
> Enable/disable UDMA bit only once in ->set_dmamode method
> and then remove custom ->bmdma_[start,stop] methods.
> 
> There shouldn't be any problems with it as IDE atiixp host driver
> has been doing it this way for last two years.

This comes from the original ATI code so should be double checked with
ATI but seems reasonable if it works.

Re: [PATCH 19/86] pata_cmd640: document known issues

[Jeff Garzik]

On 11/25/2009 12:26 PM, Alan Cox wrote:
> On Wed, 25 Nov 2009 18:04:36 +0100
> Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>  wrote:
>
>> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
>> Subject: [PATCH] pata_cmd640: document known issues
>>
>> Document known issues with the driver to aid distribution makers,
>> users and developers in making informed decisions instead of wasting
>> their time needlessly.
>
> Umm. its a) under CONFIG_PCI, and b) says CMD640 PCI IDE...

Agreed, that's a bit redundant.

Also, as I noted in another email, known issues should be listed in the 
driver source code at the top of the file, not in Kconfig.

That way the list of known issues actually follows the implementation, 
as the source code is copied around various kernel trees.

	Jeff

Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation

[Alan Cox]

> + *	QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c
> + *	Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by
> + *	Samuel Thibault <samuel.thibault@ens-lyon.org>

It's not drivers/ide/legacy/qd65xx.c - because you moved it back in the
old IDE code.

Re: [PATCH 51/86] libata: remove no longer needed pata_qdi driver

[Alan Cox]

On Wed, 25 Nov 2009 18:08:23 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] libata: remove no longer needed pata_qdi driver
> 
> QDI65x0 controllers are fully supported by pata_legacy driver
> so remove no longer needed pata_qdi driver.
> 
> Leave PATA_QDI config option for compatibility reasons and teach
> pata_legacy to preserve the old behavior of pata_qdi driver. 

Just delete it nobody will care. I sent Jeff patches to delete it a
couple of times before but they got dropped

Re: [PATCH 19/86] pata_cmd640: document known issues

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:37:19 pm Jeff Garzik wrote:
> On 11/25/2009 12:26 PM, Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:04:36 +0100
> > Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>  wrote:
> >
> >> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> >> Subject: [PATCH] pata_cmd640: document known issues
> >>
> >> Document known issues with the driver to aid distribution makers,
> >> users and developers in making informed decisions instead of wasting
> >> their time needlessly.
> >
> > Umm. its a) under CONFIG_PCI, and b) says CMD640 PCI IDE...
> 
> Agreed, that's a bit redundant.
> 
> Also, as I noted in another email, known issues should be listed in the 
> driver source code at the top of the file, not in Kconfig.

Agreed, since virtually everybody should be looking into source
code of each single driver before compiling kernel and/or deciding
to include it into distribution kernel.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:38:52 pm Alan Cox wrote:
> > + *	QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c
> > + *	Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by
> > + *	Samuel Thibault <samuel.thibault@ens-lyon.org>
> 
> It's not drivers/ide/legacy/qd65xx.c - because you moved it back in the
> old IDE code.

It was the correct path/driver when the aforementioned code was added.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:32:15 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:07:40 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] pata_legacy: do not probe extra ports automatically if PCI is not present
> > 
> > It can be problematic if there are other ISA/VLB devices using
> > those ports.
> 
> NAK. You made a rather peculiar set of changes in the IDE layer but the

Please give commit numbers and describe such 'peculiar set of changes in
the IDE layer' in more details or skip such baseless, unjust and pointless
comments from your mails.

> PCI handling in pata_legacy includes knowledge of the various half-pci
> devices and on a non PCI system 0x1E8/0x168 are reserved for extra IDE.
> 
> We've had no complaints at all, ever about this.

OTOH We had. :)

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Alan Cox]

On Wed, 25 Nov 2009 18:09:48 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_pdc202xx_old: document known issues
> 
> Document known issues with the driver to aid distribution makers,
> users and developers in making informed decisions instead of wasting
> their time needlessly.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
>  drivers/ata/Kconfig |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> Index: b/drivers/ata/Kconfig
> ===================================================================
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -583,6 +583,10 @@ config PATA_PDC_OLD
>  	  This option enables support for the Promise 20246, 20262, 20263,
>  	  20265 and 20267 adapters.
>  
> +	  Known issues:
> +	  - UDMA transfers fail mysteriously on some chipsets
> +	  - ATAPI DMA is unsupported currently

Not sure this is useful, because the reports of UDMA failures are lower
than most other reports. Should IPV6 have "known issues, mysterious timer
list corruption" for example which occurs far more. Not do we list 'no
atapi dma' in the help for the IDE SII driver ?

Would be useful to fix (may actually just work now) but comments belong
in the driver code.

Re: [PATCH 69/86] pata_scc: add 32-bit PIO support

[Alan Cox]

On Wed, 25 Nov 2009 18:10:39 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_scc: add 32-bit PIO support
> 
> There shouldn't be any problems with it as IDE scc_pata host driver
> has been allowing 32-bit PIO operations for years.

NAK; Read the code - it uses its own private data_xfer handler anyway

Re: [PATCH 69/86] pata_scc: add 32-bit PIO support

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:48:44 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:10:39 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] pata_scc: add 32-bit PIO support
> > 
> > There shouldn't be any problems with it as IDE scc_pata host driver
> > has been allowing 32-bit PIO operations for years.
> 
> NAK; Read the code - it uses its own private data_xfer handler anyway

Ah, this one can be indeed dropped.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Jeff Garzik]

On 11/25/2009 12:46 PM, Alan Cox wrote:
> On Wed, 25 Nov 2009 18:09:48 +0100
> Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>  wrote:
>
>> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
>> Subject: [PATCH] pata_pdc202xx_old: document known issues
>>
>> Document known issues with the driver to aid distribution makers,
>> users and developers in making informed decisions instead of wasting
>> their time needlessly.
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
>> ---
>>   drivers/ata/Kconfig |    4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> Index: b/drivers/ata/Kconfig
>> ===================================================================
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -583,6 +583,10 @@ config PATA_PDC_OLD
>>   	  This option enables support for the Promise 20246, 20262, 20263,
>>   	  20265 and 20267 adapters.
>>
>> +	  Known issues:
>> +	  - UDMA transfers fail mysteriously on some chipsets
>> +	  - ATAPI DMA is unsupported currently
>
> Not sure this is useful, because the reports of UDMA failures are lower
> than most other reports. Should IPV6 have "known issues, mysterious timer
> list corruption" for example which occurs far more. Not do we list 'no
> atapi dma' in the help for the IDE SII driver ?

If the chip can support ATAPI DMI, but the driver does not, that 
deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or 
"ATAPI DMA would require much more code to support, so we did not bother 
for now"

Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x") 
and other would-be-nice-to-have ideas.  These can serve as projects for 
newbies, or reminders for old-timers.

Space in the driver source code comment header is cheap.  Use liberally 
:)  Write a Shakespearean soliloquy on a chip's hardware bugs, if you'd 
like.

	Jeff

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:50:26 pm Jeff Garzik wrote:
> On 11/25/2009 12:46 PM, Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:09:48 +0100
> > Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>  wrote:
> >
> >> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> >> Subject: [PATCH] pata_pdc202xx_old: document known issues
> >>
> >> Document known issues with the driver to aid distribution makers,
> >> users and developers in making informed decisions instead of wasting
> >> their time needlessly.
> >>
> >> Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> >> ---
> >>   drivers/ata/Kconfig |    4 ++++
> >>   1 file changed, 4 insertions(+)
> >>
> >> Index: b/drivers/ata/Kconfig
> >> ===================================================================
> >> --- a/drivers/ata/Kconfig
> >> +++ b/drivers/ata/Kconfig
> >> @@ -583,6 +583,10 @@ config PATA_PDC_OLD
> >>   	  This option enables support for the Promise 20246, 20262, 20263,
> >>   	  20265 and 20267 adapters.
> >>
> >> +	  Known issues:
> >> +	  - UDMA transfers fail mysteriously on some chipsets
> >> +	  - ATAPI DMA is unsupported currently
> >
> > Not sure this is useful, because the reports of UDMA failures are lower
> > than most other reports. Should IPV6 have "known issues, mysterious timer
> > list corruption" for example which occurs far more. Not do we list 'no
> > atapi dma' in the help for the IDE SII driver ?
> 
> If the chip can support ATAPI DMI, but the driver does not, that 
> deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or 
> "ATAPI DMA would require much more code to support, so we did not bother 
> for now"
> 
> Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x") 
> and other would-be-nice-to-have ideas.  These can serve as projects for 
> newbies, or reminders for old-timers.

The problem is that the old driver supported ATAPI DMA so people may have
quite different expectations than in case of never-ever-implemented-ideas.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

[Alan Cox]

>  	/* Set UDMA unless device is not UDMA capable */
> -	if (udma_type && t.udma) {
> -		u8 cable80_status;
> +	if (udma_type) {
> +		u8 udma_etc;

This seems odd the original test is that we are a udma controller and
have a udma timing specified. Otherwise there is no point doing any work.

The rest seems to be gratuitious register renaming and makes the patches
hard to review. Please split this sort of stuff up.

Re: [PATCH 85/86] libata: add ->init_host method

[Alan Cox]

On Wed, 25 Nov 2009 18:12:40 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] libata: add ->init_host method
> 
> Add ->init_host method for re-initialization of the controller
> in ata_pci_device_resume().

Would be much cleaner if the init_host method was in the ops stuff
somewhere rather than assigned all over the place separately - because
then folks forget and its not part of the inheriting.

Definitely a good thing though

Re: [PATCH 86/86] libata: add private driver field to struct ata_device

[Alan Cox]

On Wed, 25 Nov 2009 18:12:48 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] libata: add private driver field to struct ata_device
> 
> This brings struct ata_device in-line with struct ata_{port,host}.

Do we need it for anything yet - whoever first needs it can add it,
otherwise its just waste.

Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:52:57 pm Alan Cox wrote:
> >  	/* Set UDMA unless device is not UDMA capable */
> > -	if (udma_type && t.udma) {
> > -		u8 cable80_status;
> > +	if (udma_type) {
> > +		u8 udma_etc;
> 
> This seems odd the original test is that we are a udma controller and
> have a udma timing specified. Otherwise there is no point doing any work.

The patch is based on the data sheet and is needed.

We may not hit the problem with the current chipset tuning model but things
are not set in the stone and one day we may pay a price for embedding such
undocumented assumptions into our drivers.

> The rest seems to be gratuitious register renaming and makes the patches
> hard to review. Please split this sort of stuff up.

The name now matches documentation.

Do you really find such tidy patch hard to review?

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

Fix register naming while at it.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_via.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

Index: b/drivers/ata/pata_via.c
===================================================================
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -296,14 +296,21 @@ static void via_do_set_mode(struct ata_p
 	}
 
 	/* Set UDMA unless device is not UDMA capable */
-	if (udma_type && t.udma) {
-		u8 cable80_status;
+	if (udma_type) {
+		u8 udma_etc;
 
-		/* Get 80-wire cable detection bit */
-		pci_read_config_byte(pdev, 0x50 + offset, &cable80_status);
-		cable80_status &= 0x10;
+		pci_read_config_byte(pdev, 0x50 + offset, &udma_etc);
 
-		pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status);
+		/* clear transfer mode bit */
+		udma_etc &= ~0x20;
+
+		if (t.udma) {
+			/* preserve 80-wire cable detection bit */
+			udma_etc &= 0x10;
+			udma_etc |= ut;
+		}
+
+		pci_write_config_byte(pdev, 0x50 + offset, udma_etc);
 	}
 }
 


--
Bartlomiej Zolnierkiewicz

Re: [PATCH 03/86] pata_artop: add 32-bit PIO support

[Alan Cox]

On Wed, 25 Nov 2009 18:18:18 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 25 November 2009 06:12:42 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:02:39 +0100
> > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > 
> > > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > > Subject: [PATCH] pata_artop: add 32-bit PIO support
> > > 
> > > There shouldn't be any problems with it as IDE aec62xx host driver
> > > has been allowing 32-bit PIO operations for years.
> > 
> > Allowing or defaulting too ?
> 
> For aec62xx: allowing, for some other drivers: defaulting ('using'
> in the patch description instead of 'allowing').  However some
> popular distributions have been defaulting to always enabling it
> if was supported by the driver.

I wonder what their coverage of old devices is like though and what they
enabled. No problem with those that defaulted, would be nice to get the
rest tested more systematically

Re: [PATCH 00/86] PATA fixes

[Alan Cox]

Summary would be lots of really good stuff and review.

> hmmmm....  will reserve comment until I review it thoroughly, but I am a 
> bit reluctant to move away from the current struct-driver style driver 
> init/setup model.

I think the model is right - I'd prefer it to be in the driver structs
somewhere but the basic point that init and resume often do the same job
is a very sound one.

Re: [PATCH 86/86] libata: add private driver field to struct ata_device

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:56:50 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:12:48 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] libata: add private driver field to struct ata_device
> > 
> > This brings struct ata_device in-line with struct ata_{port,host}.
> 
> Do we need it for anything yet - whoever first needs it can add it,
> otherwise its just waste.

There is a new driver using it (to be posted later) and it makes libata API
more coherent for driver developers..

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Jeff Garzik]

On 11/25/2009 12:52 PM, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 25 November 2009 06:50:26 pm Jeff Garzik wrote:
>> On 11/25/2009 12:46 PM, Alan Cox wrote:
>>> On Wed, 25 Nov 2009 18:09:48 +0100
>>> Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>   wrote:
>>>
>>>> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
>>>> Subject: [PATCH] pata_pdc202xx_old: document known issues
>>>>
>>>> Document known issues with the driver to aid distribution makers,
>>>> users and developers in making informed decisions instead of wasting
>>>> their time needlessly.
>>>>
>>>> Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
>>>> ---
>>>>    drivers/ata/Kconfig |    4 ++++
>>>>    1 file changed, 4 insertions(+)
>>>>
>>>> Index: b/drivers/ata/Kconfig
>>>> ===================================================================
>>>> --- a/drivers/ata/Kconfig
>>>> +++ b/drivers/ata/Kconfig
>>>> @@ -583,6 +583,10 @@ config PATA_PDC_OLD
>>>>    	  This option enables support for the Promise 20246, 20262, 20263,
>>>>    	  20265 and 20267 adapters.
>>>>
>>>> +	  Known issues:
>>>> +	  - UDMA transfers fail mysteriously on some chipsets
>>>> +	  - ATAPI DMA is unsupported currently
>>>
>>> Not sure this is useful, because the reports of UDMA failures are lower
>>> than most other reports. Should IPV6 have "known issues, mysterious timer
>>> list corruption" for example which occurs far more. Not do we list 'no
>>> atapi dma' in the help for the IDE SII driver ?
>>
>> If the chip can support ATAPI DMI, but the driver does not, that
>> deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or
>> "ATAPI DMA would require much more code to support, so we did not bother
>> for now"
>>
>> Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x")
>> and other would-be-nice-to-have ideas.  These can serve as projects for
>> newbies, or reminders for old-timers.
>
> The problem is that the old driver supported ATAPI DMA so people may have
> quite different expectations than in case of never-ever-implemented-ideas.

This is not rocket science :)  Have one section "known issues" and 
another section "fun ideas to explore."  This is English code comments, 
you may set any level of expectations.

	Jeff

Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

[Alan Cox]

> Do you really find such tidy patch hard to review?

When doing it at speed - yes.

>  	/* Set UDMA unless device is not UDMA capable */
> -	if (udma_type && t.udma) {
> -		u8 cable80_status;
> +	if (udma_type) {
> +		u8 udma_etc;

Ok that makes sense - we in fact could hit this case on a failure
changedown from UDMA to PIO.

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Alan Cox]

> Space in the driver source code comment header is cheap.  Use liberally 
> :)  Write a Shakespearean soliloquy on a chip's hardware bugs, if you'd 
> like.

[Don't tempt me, I've sneaked other little ditties and bits of filk into
 the kernel before now, but "Lost Andre" is probably a bit too long and
 lost on non-Hawkwind fans]

This isnt the driver source code comment at the moment.

Alan

Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 07:06:48 pm Alan Cox wrote:
> > Do you really find such tidy patch hard to review?
> 
> When doing it at speed - yes.

Do you review everybody else patches 'at speed' or only mine?

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present

[Alan Cox]

> > NAK. You made a rather peculiar set of changes in the IDE layer but the
> 
> Please give commit numbers and describe such 'peculiar set of changes in
> the IDE layer' in more details or skip such baseless, unjust and pointless

Disabling what can be a safe probe

> comments from your mails.

The old IDE code didn't do the full PCI check that libata did at the time
there were public complaints. Libata legacy also doesn't fall for the bug
where legacy loads and blocks PCI adapters as it has a smart check in it,
including for weirdness like the CS55x0 and the MPIIX.

So I'm firmly of the opinion that
- We should leave it as is
- If it causes a problem we should look at the exact case involved.
  Possibly it would need a CONFIG_X86 but thats sort of implied as
  embedded use pata_platform in preference.

The fact it just works by default is very very important.

Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation

[Alan Cox]

On Wed, 25 Nov 2009 18:44:59 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 25 November 2009 06:38:52 pm Alan Cox wrote:
> > > + *	QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c
> > > + *	Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by
> > > + *	Samuel Thibault <samuel.thibault@ens-lyon.org>
> > 
> > It's not drivers/ide/legacy/qd65xx.c - because you moved it back in the
> > old IDE code.
> 
> It was the correct path/driver when the aforementioned code was added.

Sure but the path has changed so its more helpful for anyone looking back
to have the right path.

Re: [PATCH 19/86] pata_cmd640: document known issues

[Alan Cox]

On Wed, 25 Nov 2009 18:34:04 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 25 November 2009 06:26:33 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:04:36 +0100
> > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > 
> > > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > > Subject: [PATCH] pata_cmd640: document known issues
> > > 
> > > Document known issues with the driver to aid distribution makers,
> > > users and developers in making informed decisions instead of wasting
> > > their time needlessly.
> > 
> > Umm. its a) under CONFIG_PCI, and b) says CMD640 PCI IDE...
> 
> c)
> 
>  *      This drives only the PCI version of the controller. If you have a
>  *      VLB one then we have enough docs to support it but you can write
>  *      your own code.
> 
> Then what has happened to CMD640 VLB IDE support in libata?

There is none. Nobody has complained about that either, and in fact I've
not even been able to find a board on ebay to test either driver with
VLB !

Re: [PATCH 86/86] libata: add private driver field to struct ata_device

[Alan Cox]

On Wed, 25 Nov 2009 19:02:44 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 25 November 2009 06:56:50 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:12:48 +0100
> > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > 
> > > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > > Subject: [PATCH] libata: add private driver field to struct ata_device
> > > 
> > > This brings struct ata_device in-line with struct ata_{port,host}.
> > 
> > Do we need it for anything yet - whoever first needs it can add it,
> > otherwise its just waste.
> 
> There is a new driver using it (to be posted later) and it makes libata API
> more coherent for driver developers..

Ok by me

Re: [PATCH 45/86] pata_legacy: do not probe extra ports automatically if PCI is not present

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 07:12:05 pm Alan Cox wrote:
> > > NAK. You made a rather peculiar set of changes in the IDE layer but the
> > 
> > Please give commit numbers and describe such 'peculiar set of changes in
> > the IDE layer' in more details or skip such baseless, unjust and pointless
> 
> Disabling what can be a safe probe

In many of your comments recent you're referring to IDE state from five or
more years ago.

> > comments from your mails.
> 
> The old IDE code didn't do the full PCI check that libata did at the time
> there were public complaints. Libata legacy also doesn't fall for the bug
> where legacy loads and blocks PCI adapters as it has a smart check in it,
> including for weirdness like the CS55x0 and the MPIIX.

This was fixed long time ago and the needed checks were added
(despite complete lack of code input from you).

> So I'm firmly of the opinion that
> - We should leave it as is

We may as well decide to do it before we have more data or more recent
bug-report at hand.  No big deal.

> - If it causes a problem we should look at the exact case involved.

While it was being fixed a year or two ago you were on cc: for original
patch (+ asked whether the same should be needed for pata_legacy) and
the bug-report from mikpe was on linux-ide ML.

IOW You were not interested into it the issue back when it was reported.

>   Possibly it would need a CONFIG_X86 but thats sort of implied as
>   embedded use pata_platform in preference.
> 
> The fact it just works by default is very very important.

Agreed on this one.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 48/86] pata_legacy: add pointers to QDI65x0 documentation

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 07:12:53 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:44:59 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > On Wednesday 25 November 2009 06:38:52 pm Alan Cox wrote:
> > > > + *	QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c
> > > > + *	Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by
> > > > + *	Samuel Thibault <samuel.thibault@ens-lyon.org>
> > > 
> > > It's not drivers/ide/legacy/qd65xx.c - because you moved it back in the
> > > old IDE code.
> > 
> > It was the correct path/driver when the aforementioned code was added.
> 
> Sure but the path has changed so its more helpful for anyone looking back
> to have the right path.

I disagree.  The code from back then is not the same code as today and we
have git log --follow for this.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 07:04:20 pm Jeff Garzik wrote:
> On 11/25/2009 12:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 25 November 2009 06:50:26 pm Jeff Garzik wrote:
> >> On 11/25/2009 12:46 PM, Alan Cox wrote:
> >>> On Wed, 25 Nov 2009 18:09:48 +0100
> >>> Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>   wrote:
> >>>
> >>>> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> >>>> Subject: [PATCH] pata_pdc202xx_old: document known issues
> >>>>
> >>>> Document known issues with the driver to aid distribution makers,
> >>>> users and developers in making informed decisions instead of wasting
> >>>> their time needlessly.
> >>>>
> >>>> Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> >>>> ---
> >>>>    drivers/ata/Kconfig |    4 ++++
> >>>>    1 file changed, 4 insertions(+)
> >>>>
> >>>> Index: b/drivers/ata/Kconfig
> >>>> ===================================================================
> >>>> --- a/drivers/ata/Kconfig
> >>>> +++ b/drivers/ata/Kconfig
> >>>> @@ -583,6 +583,10 @@ config PATA_PDC_OLD
> >>>>    	  This option enables support for the Promise 20246, 20262, 20263,
> >>>>    	  20265 and 20267 adapters.
> >>>>
> >>>> +	  Known issues:
> >>>> +	  - UDMA transfers fail mysteriously on some chipsets
> >>>> +	  - ATAPI DMA is unsupported currently
> >>>
> >>> Not sure this is useful, because the reports of UDMA failures are lower
> >>> than most other reports. Should IPV6 have "known issues, mysterious timer
> >>> list corruption" for example which occurs far more. Not do we list 'no
> >>> atapi dma' in the help for the IDE SII driver ?
> >>
> >> If the chip can support ATAPI DMI, but the driver does not, that
> >> deserves a comment, even if it's "hardware bugs prevent ATAPI DMA" or
> >> "ATAPI DMA would require much more code to support, so we did not bother
> >> for now"
> >>
> >> Ditto for things like useful ideas ("consider PIO-over-DMA in SiI 311x")
> >> and other would-be-nice-to-have ideas.  These can serve as projects for
> >> newbies, or reminders for old-timers.
> >
> > The problem is that the old driver supported ATAPI DMA so people may have
> > quite different expectations than in case of never-ever-implemented-ideas.
> 
> This is not rocket science :)  Have one section "known issues" and 
> another section "fun ideas to explore."  This is English code comments, 
> you may set any level of expectations.

I think it is the best to leave up to the driver maintainer
(once we find out who this person is, MAINTAINERS file still
lacks info about PATA drivers in -rc8).

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

[Alan Cox]

On Wed, 25 Nov 2009 19:10:06 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 25 November 2009 07:06:48 pm Alan Cox wrote:
> > > Do you really find such tidy patch hard to review?
> > 
> > When doing it at speed - yes.
> 
> Do you review everybody else patches 'at speed' or only mine?

All of them when I've got a lot of stuff to do. Owing to a lack of time
machine and 500 hour days it's neccessary.

Also btw take it is a compliment - there are some people's patches I
always review in detail and it isn't the patches you expect to be *right*
that you spend the time on...

Re: [PATCH 82/86] pata_via: clear UDMA transfer mode bit for PIO and MWDMA

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 08:34:19 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 19:10:06 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > On Wednesday 25 November 2009 07:06:48 pm Alan Cox wrote:
> > > > Do you really find such tidy patch hard to review?
> > > 
> > > When doing it at speed - yes.
> > 
> > Do you review everybody else patches 'at speed' or only mine?
> 
> All of them when I've got a lot of stuff to do. Owing to a lack of time
> machine and 500 hour days it's neccessary.
> 
> Also btw take it is a compliment - there are some people's patches I
> always review in detail and it isn't the patches you expect to be *right*
> that you spend the time on...

Well, you don't really have to review every single patch touching areas
that  you're just interested in (and if you're maintaining those drivers
please document it in MAINTAINERS file, thanks).

The problem is that in case you're not entirely correct, which is much
more likely when doing things 'at speed', you're will be wasting time
for everybody (not that I really care that much about  others' time but
I do care about mine).

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Jeff Garzik]

On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
> I think it is the best to leave up to the driver maintainer
> (once we find out who this person is, MAINTAINERS file still
> lacks info about PATA drivers in -rc8).


The important thing is taking two minutes to write a relevant comment, 
not determining who is wearing a crown on his head.

	Jeff

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 09:38:27 pm Jeff Garzik wrote:
> On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
> > I think it is the best to leave up to the driver maintainer
> > (once we find out who this person is, MAINTAINERS file still
> > lacks info about PATA drivers in -rc8).
> 
> 
> The important thing is taking two minutes to write a relevant comment, 

If you want something changed in the code of pata_pdc202xx_old feel free to
make said changes.  I'm neither the author nor the maintainer of this driver.

It will only take two minutes of your time anyway.

> not determining who is wearing a crown on his head.

>From the fact that it takes years to make a tiny clarification for PATA
support maintainer I'm guessing that by "a crown" you've actually meant
"a crown of thorns"..

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Jeff Garzik]

On 11/25/2009 05:02 PM, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 25 November 2009 09:38:27 pm Jeff Garzik wrote:
>> On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
>>> I think it is the best to leave up to the driver maintainer
>>> (once we find out who this person is, MAINTAINERS file still
>>> lacks info about PATA drivers in -rc8).
>>
>>
>> The important thing is taking two minutes to write a relevant comment,
>
> If you want something changed in the code of pata_pdc202xx_old feel free to
> make said changes.  I'm neither the author nor the maintainer of this driver.

You don't need to be the author or maintainer of a driver to submit changes.

	Jeff

Re: [PATCH 62/86] pata_pdc202xx_old: document known issues

[Bartlomiej Zolnierkiewicz]

On Thursday 26 November 2009 04:14:58 am Jeff Garzik wrote:
> On 11/25/2009 05:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 25 November 2009 09:38:27 pm Jeff Garzik wrote:
> >> On 11/25/2009 01:29 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> I think it is the best to leave up to the driver maintainer
> >>> (once we find out who this person is, MAINTAINERS file still
> >>> lacks info about PATA drivers in -rc8).
> >>
> >>
> >> The important thing is taking two minutes to write a relevant comment,
> >
> > If you want something changed in the code of pata_pdc202xx_old feel free to
> > make said changes.  I'm neither the author nor the maintainer of this driver.
> 
> You don't need to be the author or maintainer of a driver to submit changes.

I have neither any obligation nor any motivation to do it and you've already
wasted much more than said two minutes for everybody.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
> On Wed, 25 Nov 2009 18:04:15 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] pata_efar: MWDMA0 is unsupported
> > 
> > MWDMA0 timings cannot be met with the PIIX based controller
> > programming interface.
> 
> The efar documentation makes no reference to not being capable of MWDMA0,
> so where does this come from ? No MWDMA0 is an Intel erratum it appears.

No MWDMA0 support is a common issue on all 'PIIX-like' controllers.

In case of this chipset while the (preliminary) documentation claims MWDMA0
support on the 'FEATURES' page the later 'programming guide' part describes
only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

> There shouldn't be any problems with it as IDE it8213 host driver
> has been supporting UDMA100 and UDMA133 for years.

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

> Index: b/drivers/ata/pata_it8213.c
> ===================================================================
> --- a/drivers/ata/pata_it8213.c
> +++ b/drivers/ata/pata_it8213.c
> @@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a
>  
>  		/* Clocks follow the PIIX style */
>  		u_speed = min(2 - (udma & 1), udma);
> -		if (udma == 5)
> +		if (udma > 4)
>  			u_clock = 0x1000;	/* 100Mhz */
>  		else if (udma > 2)
>  			u_clock = 1;		/* 66Mhz */
> @@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d
>  		.flags		= ATA_FLAG_SLAVE_POSS,
>  		.pio_mask	= ATA_PIO4,
>  		.mwdma_mask	= ATA_MWDMA2,
> -		.udma_mask 	= ATA_UDMA4, /* FIXME: want UDMA 100? */
> +		.udma_mask 	= ATA_UDMA6,
>  		.port_ops	= &it8213_ops,
>  	};
>  	/* Current IT8213 stuff is single port */

    Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in disguise... 
though u_speed would be 2 instead of 1 which should correspond to either 3 
clocks or 1 clock according to Intel's documentation (different Intel docs 
give different figures and even ICH PRM gives *both* clocks).
    IOW, I doubt that 'it8213' is correct. Anybody has the datasheet?

MBR, Sergei

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Alan Cox]

On Thu, 26 Nov 2009 15:53:58 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
> > On Wed, 25 Nov 2009 18:04:15 +0100
> > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > 
> > > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > > Subject: [PATCH] pata_efar: MWDMA0 is unsupported
> > > 
> > > MWDMA0 timings cannot be met with the PIIX based controller
> > > programming interface.
> > 
> > The efar documentation makes no reference to not being capable of MWDMA0,
> > so where does this come from ? No MWDMA0 is an Intel erratum it appears.
> 
> No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
> 
> In case of this chipset while the (preliminary) documentation claims MWDMA0
> support on the 'FEATURES' page the later 'programming guide' part describes
> only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.

Cool - I only have the original docs.

Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support

[Sergei Shtylyov]

Hello, I wrote:

>> There shouldn't be any problems with it as IDE it8213 host driver
>> has been supporting UDMA100 and UDMA133 for years.

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

>> Index: b/drivers/ata/pata_it8213.c
>> ===================================================================
>> --- a/drivers/ata/pata_it8213.c
>> +++ b/drivers/ata/pata_it8213.c
>> @@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a
>>  
>>          /* Clocks follow the PIIX style */
>>          u_speed = min(2 - (udma & 1), udma);
>> -        if (udma == 5)
>> +        if (udma > 4)
>>              u_clock = 0x1000;    /* 100Mhz */
>>          else if (udma > 2)
>>              u_clock = 1;        /* 66Mhz */
>> @@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d
>>          .flags        = ATA_FLAG_SLAVE_POSS,
>>          .pio_mask    = ATA_PIO4,
>>          .mwdma_mask    = ATA_MWDMA2,
>> -        .udma_mask     = ATA_UDMA4, /* FIXME: want UDMA 100? */
>> +        .udma_mask     = ATA_UDMA6,
>>          .port_ops    = &it8213_ops,
>>      };
>>      /* Current IT8213 stuff is single port */

>    Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in 
> disguise... though u_speed would be 2 instead of 1 which should 
> correspond to either 3 clocks or 1 clock according to Intel's 
> documentation (different Intel docs give different figures and even ICH 
> PRM gives *both* clocks).

    If we take 3 clocks as correct (1 clock doesn't seem correct anyways, as 
with UDMA mode 5 UDMA cycle must be 20 ns and 1 clock gives only 10 ns). 
Well, then UDMA5 doesn't seem different from UDMA4 with ICH controllers and 
it's not clear why all the fuss about 100 MHz bit was necessary... :-/
    Returning to IT8213, with UDMA6 we have 'u_speed' of 2 that should 
correspond to 2 clocks which is 20 ns at 100 MHz and really is an UDMA5 
speed. Well, given UDMA5's slowness, that's definitely a gain. The question 
remains however, isn't this value reserved like on original ICH?

MBR, Sergei

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Sergei Shtylyov]

Hello.

Alan Cox wrote:

>>On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:

>>>On Wed, 25 Nov 2009 18:04:15 +0100
>>>Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

>>>>From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
>>>>Subject: [PATCH] pata_efar: MWDMA0 is unsupported

>>>>MWDMA0 timings cannot be met with the PIIX based controller
>>>>programming interface.

>>>The efar documentation makes no reference to not being capable of MWDMA0,
>>>so where does this come from ? No MWDMA0 is an Intel erratum it appears.

>>No MWDMA0 support is a common issue on all 'PIIX-like' controllers.

>>In case of this chipset while the (preliminary) documentation claims MWDMA0
>>support on the 'FEATURES' page the later 'programming guide' part describes
>>only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.

> Cool - I only have the original docs.

    Hm, me too... perhaps worth putting in Jeff's documentation archive?

MBR, Sergei

Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support

[Bartlomiej Zolnierkiewicz]

On Thursday 26 November 2009 04:17:51 pm Sergei Shtylyov wrote:
> Hello, I wrote:
> 
> >> There shouldn't be any problems with it as IDE it8213 host driver
> >> has been supporting UDMA100 and UDMA133 for years.
> 
> >> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> 
> >> Index: b/drivers/ata/pata_it8213.c
> >> ===================================================================
> >> --- a/drivers/ata/pata_it8213.c
> >> +++ b/drivers/ata/pata_it8213.c
> >> @@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a
> >>  
> >>          /* Clocks follow the PIIX style */
> >>          u_speed = min(2 - (udma & 1), udma);
> >> -        if (udma == 5)
> >> +        if (udma > 4)
> >>              u_clock = 0x1000;    /* 100Mhz */
> >>          else if (udma > 2)
> >>              u_clock = 1;        /* 66Mhz */
> >> @@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d
> >>          .flags        = ATA_FLAG_SLAVE_POSS,
> >>          .pio_mask    = ATA_PIO4,
> >>          .mwdma_mask    = ATA_MWDMA2,
> >> -        .udma_mask     = ATA_UDMA4, /* FIXME: want UDMA 100? */
> >> +        .udma_mask     = ATA_UDMA6,
> >>          .port_ops    = &it8213_ops,
> >>      };
> >>      /* Current IT8213 stuff is single port */
> 
> >    Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in 
> > disguise... though u_speed would be 2 instead of 1 which should 
> > correspond to either 3 clocks or 1 clock according to Intel's 
> > documentation (different Intel docs give different figures and even ICH 
> > PRM gives *both* clocks).
> 
>     If we take 3 clocks as correct (1 clock doesn't seem correct anyways, as 
> with UDMA mode 5 UDMA cycle must be 20 ns and 1 clock gives only 10 ns). 
> Well, then UDMA5 doesn't seem different from UDMA4 with ICH controllers and 
> it's not clear why all the fuss about 100 MHz bit was necessary... :-/

Sergei, please remember that IT8213 is a _custom_ spin-off from ICH chipset
and it gets some things in rather radically different way (i.e. value of PPE
bit is reversed on IT8213).

>     Returning to IT8213, with UDMA6 we have 'u_speed' of 2 that should 
> correspond to 2 clocks which is 20 ns at 100 MHz and really is an UDMA5 
> speed. Well, given UDMA5's slowness, that's definitely a gain. The question 
> remains however, isn't this value reserved like on original ICH?

It is not according to the official documentation for IT8213 (+ the chip
officially claims to support UDMA6) and pata_it8213 behavior now matches
the behavior of it8213 host driver.

I would love to be able to explain IT8213 chip internals in more detail
but unfortunately the documentation is rather cryptic in this regard as
it only gives you specific values that you should program into specific
registers to get chip properly configured for specific transfer modes...

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Bartlomiej Zolnierkiewicz]

On Thursday 26 November 2009 04:33:13 pm Sergei Shtylyov wrote:
> Hello.
> 
> Alan Cox wrote:
> 
> >>On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
> 
> >>>On Wed, 25 Nov 2009 18:04:15 +0100
> >>>Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> >>>>From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> >>>>Subject: [PATCH] pata_efar: MWDMA0 is unsupported
> 
> >>>>MWDMA0 timings cannot be met with the PIIX based controller
> >>>>programming interface.
> 
> >>>The efar documentation makes no reference to not being capable of MWDMA0,
> >>>so where does this come from ? No MWDMA0 is an Intel erratum it appears.
> 
> >>No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
> 
> >>In case of this chipset while the (preliminary) documentation claims MWDMA0
> >>support on the 'FEATURES' page the later 'programming guide' part describes
> >>only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
> 
> > Cool - I only have the original docs.
> 
>     Hm, me too... perhaps worth putting in Jeff's documentation archive?

Me too?  I just have what 'The Good Uncle Google' has..

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

>>>>>>MWDMA0 timings cannot be met with the PIIX based controller
>>>>>>programming interface.

>>>>>The efar documentation makes no reference to not being capable of MWDMA0,
>>>>>so where does this come from ? No MWDMA0 is an Intel erratum it appears.

>>>>No MWDMA0 support is a common issue on all 'PIIX-like' controllers.

>>>>In case of this chipset while the (preliminary) documentation claims MWDMA0
>>>>support on the 'FEATURES' page the later 'programming guide' part describes
>>>>only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.

>>>Cool - I only have the original docs.

>>    Hm, me too... perhaps worth putting in Jeff's documentation archive?

> Me too?  I just have what 'The Good Uncle Google' has..

    Well, I've googled for it and was unable to find any valid links even to 
my preliminary version anymore. Perhaps I haven't looked hard enough...

> --
> Bartlomiej Zolnierkiewicz

MBR, Sergei

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Bartlomiej Zolnierkiewicz]

On Thursday 26 November 2009 05:17:00 pm Sergei Shtylyov wrote:
> Hello.
> 
> Bartlomiej Zolnierkiewicz wrote:
> 
> >>>>>>MWDMA0 timings cannot be met with the PIIX based controller
> >>>>>>programming interface.
> 
> >>>>>The efar documentation makes no reference to not being capable of MWDMA0,
> >>>>>so where does this come from ? No MWDMA0 is an Intel erratum it appears.
> 
> >>>>No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
> 
> >>>>In case of this chipset while the (preliminary) documentation claims MWDMA0
> >>>>support on the 'FEATURES' page the later 'programming guide' part describes
> >>>>only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
> 
> >>>Cool - I only have the original docs.
> 
> >>    Hm, me too... perhaps worth putting in Jeff's documentation archive?
> 
> > Me too?  I just have what 'The Good Uncle Google' has..
> 
>     Well, I've googled for it and was unable to find any valid links even to 
> my preliminary version anymore. Perhaps I haven't looked hard enough...

Maybe... ;)

FWIW my file is called 38384_SMSC_SLC90E66.pdf

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:

>>>>>>>>MWDMA0 timings cannot be met with the PIIX based controller
>>>>>>>>programming interface.

>>>>>>>The efar documentation makes no reference to not being capable of MWDMA0,
>>>>>>>so where does this come from ? No MWDMA0 is an Intel erratum it appears.

>>>>>>No MWDMA0 support is a common issue on all 'PIIX-like' controllers.

>>>>>>In case of this chipset while the (preliminary) documentation claims MWDMA0
>>>>>>support on the 'FEATURES' page the later 'programming guide' part describes
>>>>>>only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.

>>>>>Cool - I only have the original docs.

>>>>   Hm, me too... perhaps worth putting in Jeff's documentation archive?

>>>Me too?  I just have what 'The Good Uncle Google' has..

>>    Well, I've googled for it and was unable to find any valid links even to 
>>my preliminary version anymore. Perhaps I haven't looked hard enough...

> Maybe... ;)

> FWIW my file is called 38384_SMSC_SLC90E66.pdf

    Well, that brought me to some Chinese site with 07/10/2002 version 
(which I've already found minutes before that). But it still claims support 
for MWDMA0 under the features... ah, I need to look further down... no 
"programming guide" part, hm... but thanks anyway. :-)

> --
> Bartlomiej Zolnierkiewicz

WBR, Sergei

Re: [PATCH 36/86] pata_it8213: add UDMA100 and UDMA133 support

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

>>Hello, I wrote:

>>>>There shouldn't be any problems with it as IDE it8213 host driver
>>>>has been supporting UDMA100 and UDMA133 for years.

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

>>>>Index: b/drivers/ata/pata_it8213.c
>>>>===================================================================
>>>>--- a/drivers/ata/pata_it8213.c
>>>>+++ b/drivers/ata/pata_it8213.c
>>>>@@ -164,7 +164,7 @@ static void it8213_set_dmamode (struct a
>>>> 
>>>>         /* Clocks follow the PIIX style */
>>>>         u_speed = min(2 - (udma & 1), udma);
>>>>-        if (udma == 5)
>>>>+        if (udma > 4)
>>>>             u_clock = 0x1000;    /* 100Mhz */
>>>>         else if (udma > 2)
>>>>             u_clock = 1;        /* 66Mhz */
>>>>@@ -264,7 +264,7 @@ static int it8213_init_one (struct pci_d
>>>>         .flags        = ATA_FLAG_SLAVE_POSS,
>>>>         .pio_mask    = ATA_PIO4,
>>>>         .mwdma_mask    = ATA_MWDMA2,
>>>>-        .udma_mask     = ATA_UDMA4, /* FIXME: want UDMA 100? */
>>>>+        .udma_mask     = ATA_UDMA6,
>>>>         .port_ops    = &it8213_ops,
>>>>     };
>>>>     /* Current IT8213 stuff is single port */

>>>   Well, at 100 MHz it's probably not really UDMA6 but UDMA5 in 
>>>disguise... though u_speed would be 2 instead of 1 which should 
>>>correspond to either 3 clocks or 1 clock according to Intel's 
>>>documentation (different Intel docs give different figures and even ICH 
>>>PRM gives *both* clocks).

>>    If we take 3 clocks as correct (1 clock doesn't seem correct anyways, as 
>>with UDMA mode 5 UDMA cycle must be 20 ns and 1 clock gives only 10 ns). 
>>Well, then UDMA5 doesn't seem different from UDMA4 with ICH controllers and 
>>it's not clear why all the fuss about 100 MHz bit was necessary... :-/

    Unless it's 133 MHz bit in reality... :-)

> Sergei, please remember that IT8213 is a _custom_ spin-off from ICH chipset

    Well, I don't have IT8213 docs, so have to interpolate from PIIX/ICH 
documentation...

> and it gets some things in rather radically different way (i.e. value of PPE
> bit is reversed on IT8213).

    Perhaps then this bit shouldn't be called PPE (concerning your outher 
patch)?

>>    Returning to IT8213, with UDMA6 we have 'u_speed' of 2 that should 
>>correspond to 2 clocks which is 20 ns at 100 MHz and really is an UDMA5 
>>speed. Well, given UDMA5's slowness, that's definitely a gain. The question 
>>remains however, isn't this value reserved like on original ICH?

> It is not according to the official documentation for IT8213 (+ the chip

    Ah, good to know at least soembody has the damn datasheet! :-)

> officially claims to support UDMA6) and pata_it8213 behavior now matches
> the behavior of it8213 host driver.

    OK, fine then...

> I would love to be able to explain IT8213 chip internals in more detail
> but unfortunately the documentation is rather cryptic in this regard as
> it only gives you specific values that you should program into specific
> registers to get chip properly configured for specific transfer modes...

    At least something... :-)

> --
> Bartlomiej Zolnierkiewicz

MBR, Sergei

Re: [PATCH 41/86] pata_efar: unify code for programming PIO and MWDMA timings

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:

> It results in ~9% decrease in the driver LOC count and also ~6%
> decrease in the driver binary size (as measured on x86-32).

> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
>  drivers/ata/pata_it8213.c |   87 +++++++++++++++-------------------------------
>  1 file changed, 29 insertions(+), 58 deletions(-)

> Index: b/drivers/ata/pata_it8213.c
> ===================================================================
> --- a/drivers/ata/pata_it8213.c
> +++ b/drivers/ata/pata_it8213.c
> @@ -61,20 +61,9 @@ static int it8213_cable_detect(struct at
>  	return ATA_CBL_PATA80;
>  }
>  
> -/**
> - *	it8213_set_piomode - Initialize host controller PATA PIO timings
> - *	@ap: Port whose timings we are configuring
> - *	@adev: Device whose timings we are configuring
> - *
> - *	Set PIO mode for device, in host controller PCI config space.
> - *
> - *	LOCKING:
> - *	None (inherited from caller).
> - */
> -
> -static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev)
> +static void it8213_set_timings(struct ata_port *ap, struct ata_device *adev,
> +			       u8 pio, bool use_mwdma)

    Perhaps 'set_mwdma' would be a better name...

>  {
> -	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
>  	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
>  	u8 master_port		= ap->port_no ? 0x42 : 0x40;
>  	u16 master_data;
> @@ -92,13 +81,18 @@ static void it8213_set_piomode (struct a
>  			    { 2, 1 },
>  			    { 2, 3 }, };
>  
> -	if (pio > 1)
> +	if (pio > 1 || use_mwdma)
>  		control |= 1;	/* TIME */
> -	if (ata_pio_need_iordy(adev))	/* PIO 3/4 require IORDY */
> +	if (ata_pio_need_iordy(adev) || use_mwdma)

    I believe this "IORDY for MWDMA" stupidity results from the table 35 in 
ICH PRD which for some reason insists on setting IE bit with DMA, and I 
believe this is wrong -- IORDY shouldn't have anything to with DMA.

>  		control |= 2;	/* IE */
>  	/* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */
>  	if (adev->class != ATA_DEV_ATA)
>  		control |= 4;	/* PPE */
> +	/* If the drive MWDMA is faster than it can do PIO then
> +	   we must force PIO into PIO0 */
> +	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))

    Parens not needed...

> +		/* Enable DMA timing only */
> +		control |= 8;	/* PIO cycles in PIO0 */
>  
>  	pci_read_config_word(dev, master_port, &master_data);

MBR, Sergei

Re: [PATCH 64/86] pata_radisys: unify code for programming PIO and MWDMA timings

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:

> It results in ~6% decrease in the driver LOC count and also ~1%
> decrease in the driver binary size (as measured on x86-32).

> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
>  drivers/ata/pata_radisys.c |   66 +++++++++++++++++----------------------------
>  1 file changed, 25 insertions(+), 41 deletions(-)

> Index: b/drivers/ata/pata_radisys.c
> ===================================================================
> --- a/drivers/ata/pata_radisys.c
> +++ b/drivers/ata/pata_radisys.c
> @@ -26,20 +26,9 @@
>  #define DRV_NAME	"pata_radisys"
>  #define DRV_VERSION	"0.4.4"
>  
> -/**
> - *	radisys_set_piomode - Initialize host controller PATA PIO timings
> - *	@ap: ATA port
> - *	@adev: Device whose timings we are configuring
> - *
> - *	Set PIO mode for device, in host controller PCI config space.
> - *
> - *	LOCKING:
> - *	None (inherited from caller).
> - */
> -
> -static void radisys_set_piomode (struct ata_port *ap, struct ata_device *adev)
> +static void radisys_set_timings(struct ata_port *ap, struct ata_device *adev,
> +				u8 pio, bool use_mwdma)
>  {
> -	unsigned int pio	= adev->pio_mode - XFER_PIO_0;
>  	struct pci_dev *dev	= to_pci_dev(ap->host->dev);
>  	u16 idetm_data;
>  	int control = 0;
> @@ -52,7 +41,7 @@ static void radisys_set_piomode (struct
>  	 */
>  
>  	static const	 /* ISP  RTC */
> -	u8 timings[][2]	= { { 0, 0 },	/* Check me */
> +	u8 timings[][2]	= { { 0, 0 },
>  			    { 0, 0 },
>  			    { 1, 1 },
>  			    { 2, 2 },
> @@ -62,6 +51,10 @@ static void radisys_set_piomode (struct
>  		control |= 1;	/* TIME1 enable */
>  	if (ata_pio_need_iordy(adev))
>  		control |= 2;	/* IE IORDY */
> +	/* If the drive MWDMA is faster than it can do PIO then
> +	   we must force PIO0 for PIO cycles. */

    Multi-line comment style should preferrably be:

	/*
	 * blah
	 * blah
	 */

> +	if (use_mwdma && adev->pio_mode < (XFER_PIO_0 + pio))
> +		control = 1;

    Hm, shouldn't that be 8?

> @@ -115,20 +112,8 @@ static void radisys_set_dmamode (struct
>  			XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
>  		};
>  		int pio = needed_pio[mwdma] - XFER_PIO_0;
> -		int control = 3;	/* IORDY|TIME0 */
> -
> -		/* If the drive MWDMA is faster than it can do PIO then
> -		   we must force PIO0 for PIO cycles. */
> -
> -		if (adev->pio_mode < needed_pio[mwdma])
> -			control = 1;

    Perhaps there's a bug here?

MBR, Sergei

Re: [PATCH 07/86] pata_artop: remove dead 34MHz PCI clock support

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

> It has been dead for the last three years (== since the initial driver
> merge) and probability that it will ever get fixed is quite low.

> Since there is no reason to keep this dead code around any longer just
> remove it (it can still be retrieved from the git history if necessary).

> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
>  drivers/ata/pata_artop.c |   29 ++++++++---------------------
>  1 file changed, 8 insertions(+), 21 deletions(-)

> Index: b/drivers/ata/pata_artop.c
> ===================================================================
> --- a/drivers/ata/pata_artop.c
> +++ b/drivers/ata/pata_artop.c
> @@ -30,15 +30,6 @@
>  #define DRV_NAME	"pata_artop"
>  #define DRV_VERSION	"0.4.5"
>  
> -/*
> - *	The ARTOP has 33 Mhz and "over clocked" timing tables. Until we
> - *	get PCI bus speed functionality we leave this as 0. Its a variable
> - *	for when we get the functionality and also for folks wanting to
> - *	test stuff.
> - */
> -
> -static int clock = 0;
> -
>  /**
>   *	atp8xx_prereset	-	probe begin
>   *	@link: link
[...]
> @@ -223,7 +210,7 @@ static void atp850_set_dmamode(struct at
>  
>  	/* Add ultra DMA bits if in UDMA mode */
>  	if (adev->dma_mode >= XFER_UDMA_0) {
> -		u8 mode = (adev->dma_mode - XFER_UDMA_0) + 1 - clock;
> +		u8 mode = (adev->dma_mode - XFER_UDMA_0) + 1;
>  		if (mode == 0)
>  			mode = 1;

    Note that 'mode' can't be 0 anymore, so this check can be removed.

>  		ultra |= (mode << (2 * dn));
> @@ -261,7 +248,7 @@ static void atp86x_set_dmamode(struct at
>  	pci_read_config_byte(pdev, 0x44 + ap->port_no, &ultra);
>  	ultra &= ~(7 << (4  * adev->devno));	/* One nibble per drive */
>  	if (adev->dma_mode >= XFER_UDMA_0) {
> -		u8 mode = adev->dma_mode - XFER_UDMA_0 + 1 - clock;
> +		u8 mode = adev->dma_mode - XFER_UDMA_0 + 1;
>  		if (mode == 0)
>  			mode = 1;

    Same here...

MBR, Sergei

Re: [PATCH 05/86] pata_artop: add Power Management support

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:

> There shouldn't be any problems with it as IDE aec62xx host driver
> has been supporting Power Management for over year now.

> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
>  drivers/ata/pata_artop.c |   72 +++++++++++++++++++++++++++++++++--------------
>  1 file changed, 51 insertions(+), 21 deletions(-)

> Index: b/drivers/ata/pata_artop.c
> ===================================================================
> --- a/drivers/ata/pata_artop.c
> +++ b/drivers/ata/pata_artop.c
[...]
> @@ -330,6 +330,33 @@ static struct ata_port_operations atp86x
>  	.prereset		= atp86x_pre_reset,
>  };
>  
> +static void atp8xx_fixup(struct pci_dev *pdev)
> +{
> +	if (pdev->device == 0x0005)
> +		/* BIOS may have left us in UDMA, clear it before probe */
> +		pci_write_config_byte(pdev, 0x54, 0);
> +	else if (pdev->device == 0x0008 || pdev->device == 0x0009) {
> +		u8 reg;
> +
> +		/* Mac systems come up with some registers not set as we
> +		   will need them */
> +
> +		/* Clear reset & test bits */
> +		pci_read_config_byte(pdev, 0x49, &reg);
> +		pci_write_config_byte(pdev, 0x49, reg & ~ 0x30);

    Space not needed between ~ and 0x30...

MBR, Sergei

Re: [PATCH 86/86] libata: add private driver field to struct ata_device

[Jeff Garzik]

On 11/25/2009 12:12 PM, Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> Subject: [PATCH] libata: add private driver field to struct ata_device
>
> This brings struct ata_device in-line with struct ata_{port,host}.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> ---
>   include/linux/libata.h |    1 +
>   1 file changed, 1 insertion(+)
>
> Index: b/include/linux/libata.h
> ===================================================================
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -585,6 +585,7 @@ struct ata_device {
>   	unsigned int		horkage;	/* List of broken features */
>   	unsigned long		flags;		/* ATA_DFLAG_xxx */
>   	struct scsi_device	*sdev;		/* attached SCSI device */
> +	void			*private_data;
>   #ifdef CONFIG_ATA_ACPI
>   	acpi_handle		acpi_handle;
>   	union acpi_object	*gtf_cache;

I'm fine with this, and would like to merge this sooner rather than later.

However, BIG FAT WARNING:  you must take special care to be sure you 
don't leak as devices appear and disappear, etc.  IOW, watch your object 
lifetimes carefully.  Object lifetime was the reason this was not added 
until now.

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> I've been going through PATA drivers for the last few days to make
> sure that we offer similar level of hardware support in the new PATA
> drivers as with the old IDE subsystem and the following patchset is
> the end result of said audit.
>
>
> Inside:
>
> - many bugfixes
>
>    ( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x,
>      pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis,
>      pata_radisys, pata_rz1000&  pata_via )
>
> - add Power Management support for more controllers
>
>    ( pata_artop, pata_pdc2027x, pata_sl82c105 )
>
> - add 32-bit PIO support for more controllers
>
>    ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
>      pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
>      pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
>      pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
>      pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
>      pata_sis, pata_triflex&  pata_via )
>
> - fix QDI65x0 support in pata_legacy driver so pata_qdi driver can
>    be finally removed
>
> - remove pata_qdi and pata_winbond drivers resulting in 600 LOC gone
>
>    (affected hardware is fully supported by pata_legacy driver now)
>
> - unify code for programming PIO and MWDMA timings for 'PIIX-like'
>    controllers resulting in 200 LOC gone
>
>    ( ata_piix, pata_efar, pata_it8213, pata_oldpiix, pata_radisys&
>      pata_rdc )
>
> - add ->init_host method for abstracting host specific controller
>    initialization and then use it to cleanup Power Managment code
>    resulting in over 100 LOC gone
>
>    ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
>      pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
>      pata_ns87415, pata_pdc2027x&  sata_sil )
>
> - misc fixes and cleanups

What are your plans for 2.6.33?

The merge window is upon us, which by strict rules means that anything 
not already in libata-dev.git#upstream needs to wait until 2.6.34.

However, bug fixes and the like should definitely be in 2.6.33. 
->init_host is definitely 2.6.34 material.  Some of the other stuff 
could go either way.

	Jeff

Re: [PATCH 86/86] libata: add private driver field to struct ata_device

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 09:04:40 am Jeff Garzik wrote:
> On 11/25/2009 12:12 PM, Bartlomiej Zolnierkiewicz wrote:
> > From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> > Subject: [PATCH] libata: add private driver field to struct ata_device
> >
> > This brings struct ata_device in-line with struct ata_{port,host}.
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> > ---
> >   include/linux/libata.h |    1 +
> >   1 file changed, 1 insertion(+)
> >
> > Index: b/include/linux/libata.h
> > ===================================================================
> > --- a/include/linux/libata.h
> > +++ b/include/linux/libata.h
> > @@ -585,6 +585,7 @@ struct ata_device {
> >   	unsigned int		horkage;	/* List of broken features */
> >   	unsigned long		flags;		/* ATA_DFLAG_xxx */
> >   	struct scsi_device	*sdev;		/* attached SCSI device */
> > +	void			*private_data;
> >   #ifdef CONFIG_ATA_ACPI
> >   	acpi_handle		acpi_handle;
> >   	union acpi_object	*gtf_cache;
> 
> I'm fine with this, and would like to merge this sooner rather than later.
> 
> However, BIG FAT WARNING:  you must take special care to be sure you 
> don't leak as devices appear and disappear, etc.  IOW, watch your object 
> lifetimes carefully.  Object lifetime was the reason this was not added 
> until now.

It should be fine for now as the only user is pata_ep93xx and it gets it
right.  Though it would definitely be nice to see the underlying issue
(which is the lack of dynamic allocation for struct ata_device objects)
fixed one day in libata.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> On 11/25/2009 12:02 PM, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > I've been going through PATA drivers for the last few days to make
> > sure that we offer similar level of hardware support in the new PATA
> > drivers as with the old IDE subsystem and the following patchset is
> > the end result of said audit.
> >
> >
> > Inside:
> >
> > - many bugfixes
> >
> >    ( ata_piix, pata_artop, pata_atiixp, pata_efar, pata_cmd64x,
> >      pata_hpt3x3, pata_it8213, pata_legacy, pata_ns87415, pata_sis,
> >      pata_radisys, pata_rz1000&  pata_via )
> >
> > - add Power Management support for more controllers
> >
> >    ( pata_artop, pata_pdc2027x, pata_sl82c105 )
> >
> > - add 32-bit PIO support for more controllers
> >
> >    ( pata_artop, pata_atiixp, pata_efar, pata_cmd64x, pata_cs5520,
> >      pata_cs5530, pata_cs5535, pata_cypress, pata_hpt366, pata_hpt37x,
> >      pata_hpt3x2n, pata_it8213, pata_it821x, pata_jmicron, pata_ns87415,
> >      pata_opti, pata_pdc2027x, pata_pdc202xx_old, pata_rz1000,
> >      pata_sc1200, pata_scc, pata_sch, pata_serverworks, pata_sl82c105,
> >      pata_sis, pata_triflex&  pata_via )
> >
> > - fix QDI65x0 support in pata_legacy driver so pata_qdi driver can
> >    be finally removed
> >
> > - remove pata_qdi and pata_winbond drivers resulting in 600 LOC gone
> >
> >    (affected hardware is fully supported by pata_legacy driver now)
> >
> > - unify code for programming PIO and MWDMA timings for 'PIIX-like'
> >    controllers resulting in 200 LOC gone
> >
> >    ( ata_piix, pata_efar, pata_it8213, pata_oldpiix, pata_radisys&
> >      pata_rdc )
> >
> > - add ->init_host method for abstracting host specific controller
> >    initialization and then use it to cleanup Power Managment code
> >    resulting in over 100 LOC gone
> >
> >    ( pata_ali, pata_amd, pata_artop, pata_cmd640, pata_cmd64x,
> >      pata_cs5530, pata_hpt366, pata_hpt3x3, pata_it821x, pata_ninja32,
> >      pata_ns87415, pata_pdc2027x&  sata_sil )
> >
> > - misc fixes and cleanups
> 
> What are your plans for 2.6.33?

All past patches have been posted for review and have review issues addressed
already so right now I'm all busy with working on future patches.

> The merge window is upon us, which by strict rules means that anything 
> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>
> However, bug fixes and the like should definitely be in 2.6.33. 
> ->init_host is definitely 2.6.34 material.  Some of the other stuff 
> could go either way.

If you would like to apply some of my patches to 2.6.33 you are more than
welcome to do it.  I can even prepare separate git tree with specific changes
to make it easier for you once you tell me which changes you would like to
see in it.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Alan Cox]

> The merge window is upon us, which by strict rules means that anything 
> not already in libata-dev.git#upstream needs to wait until 2.6.34.

Not quite yet - Linus hasn't said "go"

> However, bug fixes and the like should definitely be in 2.6.33. 
> ->init_host is definitely 2.6.34 material.  Some of the other stuff 
> could go either way.

The bits that probably should be delayed a bit more (if any) IMHO are the
32bit enables for hardware that doesn't use 32bit by default on the
drivers/ide stack, and tweaks for obscure old hardware that won't get
much testing.

The sooner it's all upstream the better.

Alan

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 11:59 AM, Alan Cox wrote:
>> The merge window is upon us, which by strict rules means that anything
>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>
> Not quite yet - Linus hasn't said "go"

He rarely if ever says "go."  The kernel X is released, and people send 
pull requests to Linus for X+1.  He typically merges immediately, but 
does not push out the first set of merges for a few days.

The stuff pushed to Linus for kernel X+1 should have already been living 
in linux-next (libata-dev.git#NEXT, to us).


> The bits that probably should be delayed a bit more (if any) IMHO are the
> 32bit enables for hardware that doesn't use 32bit by default on the
> drivers/ide stack, and tweaks for obscure old hardware that won't get
> much testing.

Agreed mostly...  I still want to push fixes even if for obscure hardware.

	Jeff

Re: [PATCH 86/86] libata: add private driver field to struct ata_device

[Jeff Garzik]

On 11/25/2009 12:12 PM, Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> Subject: [PATCH] libata: add private driver field to struct ata_device
>
> This brings struct ata_device in-line with struct ata_{port,host}.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> ---
>   include/linux/libata.h |    1 +
>   1 file changed, 1 insertion(+)
>
> Index: b/include/linux/libata.h
> ===================================================================
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -585,6 +585,7 @@ struct ata_device {
>   	unsigned int		horkage;	/* List of broken features */
>   	unsigned long		flags;		/* ATA_DFLAG_xxx */
>   	struct scsi_device	*sdev;		/* attached SCSI device */
> +	void			*private_data;
>   #ifdef CONFIG_ATA_ACPI
>   	acpi_handle		acpi_handle;
>   	union acpi_object	*gtf_cache;

applied

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>> The merge window is upon us, which by strict rules means that anything
>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>
>> However, bug fixes and the like should definitely be in 2.6.33.
>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
>> could go either way.

> If you would like to apply some of my patches to 2.6.33 you are more than
> welcome to do it.  I can even prepare separate git tree with specific changes
> to make it easier for you once you tell me which changes you would like to
> see in it.

OK, great.

Can you prepare a patchset containing only fixes?  Comment-only changes 
are acceptable too.  Trivial changes too, if they are extremely trivial :)

Include nothing that adds features, removes or unifies drivers, etc.

Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and 
all-in-one diff.

	Jeff

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >> The merge window is upon us, which by strict rules means that anything
> >> not already in libata-dev.git#upstream needs to wait until 2.6.34.
> >>
> >> However, bug fixes and the like should definitely be in 2.6.33.
> >> ->init_host is definitely 2.6.34 material.  Some of the other stuff
> >> could go either way.
> 
> > If you would like to apply some of my patches to 2.6.33 you are more than
> > welcome to do it.  I can even prepare separate git tree with specific changes
> > to make it easier for you once you tell me which changes you would like to
> > see in it.
> 
> OK, great.
> 
> Can you prepare a patchset containing only fixes?  Comment-only changes 
> are acceptable too.  Trivial changes too, if they are extremely trivial :)
> 
> Include nothing that adds features, removes or unifies drivers, etc.

Since this is pretty high-level description and some changes fall into
many categories at once (i.e. addition of proper PCI Power Management
handling could be considered both as a fix and as a feature) I prepared
a rather conservative set of changes (which means that unfortunately
it misses many enhancements available in my tree):

> Please do it in standard kernel submit form, which is either
> (a) repost the patches (yes, again) being submitted for 2.6.33, or
> (b) a standard git pull request, which includes shortlog, diffstat, and 
> all-in-one diff.

Thank you for the detailed explanation of the standard kernel submit
form (I wonder how would I know this otherwise :) but the thing is that
at the current moment I'm not submitting anything to the upstream.

That's it.  While this may sound strange to some people it turns out
that in practice it is much less hassle for me personally to keep some
of trees outside of the (sometimes greatly overrated) upstream.

If knowing the above you still would like to include the aforementioned
set of changes in your libata-dev tree they are at kernel.org now.


The following changes since commit 184b8405d5d3e8510163d66efbac99d351faba2e:
  Bartlomiej Zolnierkiewicz (1):
        libata: add private driver field to struct ata_device

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-for-2.6.33

Bartlomiej Zolnierkiewicz (28):
      ide-pci-generic: build fix
      ata_piix: fix MWDMA handling on PIIX3
      pata_efar: fix wrong PIO timings being programmed
      pata_efar: fix wrong MWDMA timings being programmed
      pata_efar: MWDMA0 is unsupported
      pata_cmd640: document known issues
      pata_cs5520: remove dead VDMA support
      pata_cypress: document known issues
      pata_hpt3x2n: fix overclocked MWDMA0 timing
      pata_hpt3x3: Power Management fix
      pata_it8213: fix UDMA handling
      pata_it8213: fix wrong PIO timings being programmed
      pata_it8213: fix PIO2 underclocking
      pata_it8213: fix wrong MWDMA timings being programmed
      pata_it8213: fix it8213_pre_reset() documentation
      pata_it8213: MWDMA0 is unsupported
      pata_legacy: fix QDI6580DP support
      pata_legacy: fix access to control register for QDI6580
      pata_legacy: add pointers to QDI65x0 documentation
      pata_marvell: fix marvell_pre_reset() documentation
      pata_ns87415: Power Management fix
      pata_oldpiix: MWDMA0 is unsupported
      pata_pdc202xx_old: document known issues
      pata_radisys: fix UDMA handling
      pata_rdc: MWDMA0 is unsupported
      pata_rz1000: Power Management fix
      pata_sis: Power Management fix
      pata_via: clear UDMA transfer mode bit for PIO and MWDMA

 drivers/ata/Kconfig           |   14 ++++++++++++--
 drivers/ata/ata_piix.c        |    6 +++---
 drivers/ata/pata_cs5520.c     |   39 +--------------------------------------
 drivers/ata/pata_efar.c       |    9 +++++----
 drivers/ata/pata_hpt3x2n.c    |    3 +--
 drivers/ata/pata_hpt3x3.c     |   11 ++++++++++-
 drivers/ata/pata_it8213.c     |   27 +++++++++++++--------------
 drivers/ata/pata_legacy.c     |   14 +++++++++++---
 drivers/ata/pata_marvell.c    |    2 +-
 drivers/ata/pata_ns87415.c    |   32 +++++++++++++++++++++++++++-----
 drivers/ata/pata_oldpiix.c    |    2 +-
 drivers/ata/pata_radisys.c    |    4 ++--
 drivers/ata/pata_rdc.c        |    2 +-
 drivers/ata/pata_rz1000.c     |   11 ++++++++++-
 drivers/ata/pata_sis.c        |   21 +++++++++++++++++++--
 drivers/ata/pata_via.c        |   19 +++++++++++++------
 drivers/ide/ide-pci-generic.c |    2 +-
 17 files changed, 131 insertions(+), 87 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 676f08b..25cb4e7 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -287,8 +287,11 @@ config PATA_CMD640_PCI
 	depends on PCI && EXPERIMENTAL
 	help
 	  This option enables support for the CMD640 PCI IDE
-	  interface chip. Only the primary channel is currently
-	  supported.
+	  interface chip.
+
+	  Known issues:
+	  - only the primary channel is currently supported
+	  - only the PCI chip interface is currently supported
 
 	  If unsure, say N.
 
@@ -344,6 +347,9 @@ config PATA_CYPRESS
 	  This option enables support for the Cypress/Contaq CY82C693
 	  chipset found in some Alpha systems
 
+	  Known issues:
+	  - only the primary channel is currently supported
+
 	  If unsure, say N.
 
 config PATA_EFAR
@@ -588,6 +594,10 @@ config PATA_PDC_OLD
 	  This option enables support for the Promise 20246, 20262, 20263,
 	  20265 and 20267 adapters.
 
+	  Known issues:
+	  - UDMA transfers fail mysteriously on some chipsets
+	  - ATAPI DMA is unsupported currently
+
 	  If unsure, say N.
 
 config PATA_QDI
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9ac4e37..0c6155f 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -869,10 +869,10 @@ static void do_pata_set_dmamode(struct ata_port *ap, struct ata_device *adev, in
 				(timings[pio][1] << 8);
 		}
 
-		if (ap->udma_mask) {
+		if (ap->udma_mask)
 			udma_enable &= ~(1 << devid);
-			pci_write_config_word(dev, master_port, master_data);
-		}
+
+		pci_write_config_word(dev, master_port, master_data);
 	}
 	/* Don't scribble on 0x48 if the controller does not support UDMA */
 	if (ap->udma_mask)
diff --git a/drivers/ata/pata_cs5520.c b/drivers/ata/pata_cs5520.c
index 0df83cf..95ebdac 100644
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -90,48 +90,12 @@ static void cs5520_set_timings(struct ata_port *ap, struct ata_device *adev, int
 }
 
 /**
- *	cs5520_enable_dma	-	turn on DMA bits
- *
- *	Turn on the DMA bits for this disk. Needed because the BIOS probably
- *	has not done the work for us. Belongs in the core SATA code.
- */
-
-static void cs5520_enable_dma(struct ata_port *ap, struct ata_device *adev)
-{
-	/* Set the DMA enable/disable flag */
-	u8 reg = ioread8(ap->ioaddr.bmdma_addr + 0x02);
-	reg |= 1<<(adev->devno + 5);
-	iowrite8(reg, ap->ioaddr.bmdma_addr + 0x02);
-}
-
-/**
- *	cs5520_set_dmamode	-	program DMA timings
- *	@ap: ATA port
- *	@adev: ATA device
- *
- *	Program the DMA mode timings for the controller according to the pio
- *	clocking table. Note that this device sets the DMA timings to PIO
- *	mode values. This may seem bizarre but the 5520 architecture talks
- *	PIO mode to the disk and DMA mode to the controller so the underlying
- *	transfers are PIO timed.
- */
-
-static void cs5520_set_dmamode(struct ata_port *ap, struct ata_device *adev)
-{
-	static const int dma_xlate[3] = { XFER_PIO_0, XFER_PIO_3, XFER_PIO_4 };
-	cs5520_set_timings(ap, adev, dma_xlate[adev->dma_mode]);
-	cs5520_enable_dma(ap, adev);
-}
-
-/**
  *	cs5520_set_piomode	-	program PIO timings
  *	@ap: ATA port
  *	@adev: ATA device
  *
  *	Program the PIO mode timings for the controller according to the pio
- *	clocking table. We know pio_mode will equal dma_mode because of the
- *	CS5520 architecture. At least once we turned DMA on and wrote a
- *	mode setter.
+ *	clocking table.
  */
 
 static void cs5520_set_piomode(struct ata_port *ap, struct ata_device *adev)
@@ -149,7 +113,6 @@ static struct ata_port_operations cs5520_port_ops = {
 	.qc_prep		= ata_sff_dumb_qc_prep,
 	.cable_detect		= ata_cable_40wire,
 	.set_piomode		= cs5520_set_piomode,
-	.set_dmamode		= cs5520_set_dmamode,
 };
 
 static int __devinit cs5520_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
diff --git a/drivers/ata/pata_efar.c b/drivers/ata/pata_efar.c
index 2a6412f..b2e71e6 100644
--- a/drivers/ata/pata_efar.c
+++ b/drivers/ata/pata_efar.c
@@ -2,6 +2,7 @@
  *    pata_efar.c - EFAR PIIX clone controller driver
  *
  *	(C) 2005 Red Hat
+ *	(C) 2009 Bartlomiej Zolnierkiewicz
  *
  *    Some parts based on ata_piix.c by Jeff Garzik and others.
  *
@@ -118,12 +119,12 @@ static void efar_set_piomode (struct ata_port *ap, struct ata_device *adev)
 		int shift = 4 * ap->port_no;
 		u8 slave_data;
 
-		idetm_data &= 0xCC0F;
+		idetm_data &= 0xFF0F;
 		idetm_data |= (control << 4);
 
 		/* Slave timing in separate register */
 		pci_read_config_byte(dev, 0x44, &slave_data);
-		slave_data &= 0x0F << shift;
+		slave_data &= ap->port_no ? 0x0F : 0xF0;
 		slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << shift;
 		pci_write_config_byte(dev, 0x44, slave_data);
 	}
@@ -200,7 +201,7 @@ static void efar_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
 			master_data |= control << 4;
 			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= (0x0F + 0xE1 * ap->port_no);
+			slave_data &= ap->port_no ? 0x0F : 0xF0;
 			/* Load the matching timing */
 			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
 			pci_write_config_byte(dev, 0x44, slave_data);
@@ -251,7 +252,7 @@ static int efar_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
 	static const struct ata_port_info info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
-		.mwdma_mask	= ATA_MWDMA2,
+		.mwdma_mask	= ATA_MWDMA12_ONLY,
 		.udma_mask 	= ATA_UDMA4,
 		.port_ops	= &efar_ops,
 	};
diff --git a/drivers/ata/pata_hpt3x2n.c b/drivers/ata/pata_hpt3x2n.c
index d30da80..9a09a1b 100644
--- a/drivers/ata/pata_hpt3x2n.c
+++ b/drivers/ata/pata_hpt3x2n.c
@@ -80,14 +80,13 @@ static struct hpt_clock hpt3x2n_clocks[] = {
 
 	{	XFER_MW_DMA_2,	0x2c829c62	},
 	{	XFER_MW_DMA_1,	0x2c829c66	},
-	{	XFER_MW_DMA_0,	0x2c829d2c	},
+	{	XFER_MW_DMA_0,	0x2c829d2e	},
 
 	{	XFER_PIO_4,	0x0c829c62	},
 	{	XFER_PIO_3,	0x0c829c84	},
 	{	XFER_PIO_2,	0x0c829ca6	},
 	{	XFER_PIO_1,	0x0d029d26	},
 	{	XFER_PIO_0,	0x0d029d5e	},
-	{	0,		0x0d029d5e	}
 };
 
 /**
diff --git a/drivers/ata/pata_hpt3x3.c b/drivers/ata/pata_hpt3x3.c
index 7e31025..c86c716 100644
--- a/drivers/ata/pata_hpt3x3.c
+++ b/drivers/ata/pata_hpt3x3.c
@@ -255,8 +255,17 @@ static int hpt3x3_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 #ifdef CONFIG_PM
 static int hpt3x3_reinit_one(struct pci_dev *dev)
 {
+	struct ata_host *host = dev_get_drvdata(&dev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(dev);
+	if (rc)
+		return rc;
+
 	hpt3x3_init_chipset(dev);
-	return ata_pci_device_resume(dev);
+
+	ata_host_resume(host);
+	return 0;
 }
 #endif
 
diff --git a/drivers/ata/pata_it8213.c b/drivers/ata/pata_it8213.c
index f156da8..8f3325a 100644
--- a/drivers/ata/pata_it8213.c
+++ b/drivers/ata/pata_it8213.c
@@ -22,7 +22,7 @@
 #define DRV_VERSION	"0.0.3"
 
 /**
- *	it8213_pre_reset	-	check for 40/80 pin
+ *	it8213_pre_reset	-	probe begin
  *	@link: link
  *	@deadline: deadline jiffies for the operation
  *
@@ -92,18 +92,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev)
 			    { 2, 1 },
 			    { 2, 3 }, };
 
-	if (pio > 2)
-		control |= 1;	/* TIME1 enable */
+	if (pio > 1)
+		control |= 1;	/* TIME */
 	if (ata_pio_need_iordy(adev))	/* PIO 3/4 require IORDY */
-		control |= 2;	/* IORDY enable */
+		control |= 2;	/* IE */
 	/* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */
 	if (adev->class != ATA_DEV_ATA)
-		control |= 4;
+		control |= 4;	/* PPE */
 
 	pci_read_config_word(dev, idetm_port, &idetm_data);
 
-	/* Enable PPE, IE and TIME as appropriate */
-
+	/* Set PPE, IE, and TIME as appropriate */
 	if (adev->devno == 0) {
 		idetm_data &= 0xCCF0;
 		idetm_data |= control;
@@ -112,17 +111,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev)
 	} else {
 		u8 slave_data;
 
-		idetm_data &= 0xCC0F;
+		idetm_data &= 0xFF0F;
 		idetm_data |= (control << 4);
 
 		/* Slave timing in separate register */
 		pci_read_config_byte(dev, 0x44, &slave_data);
 		slave_data &= 0xF0;
-		slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << 4;
+		slave_data |= (timings[pio][0] << 2) | timings[pio][1];
 		pci_write_config_byte(dev, 0x44, slave_data);
 	}
 
-	idetm_data |= 0x4000;	/* Ensure SITRE is enabled */
+	idetm_data |= 0x4000;	/* Ensure SITRE is set */
 	pci_write_config_word(dev, idetm_port, idetm_data);
 }
 
@@ -173,10 +172,10 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 
 		udma_enable |= (1 << devid);
 
-		/* Load the UDMA mode number */
+		/* Load the UDMA cycle time */
 		pci_read_config_word(dev, 0x4A, &udma_timing);
 		udma_timing &= ~(3 << (4 * devid));
-		udma_timing |= (udma & 3) << (4 * devid);
+		udma_timing |= u_speed << (4 * devid);
 		pci_write_config_word(dev, 0x4A, udma_timing);
 
 		/* Load the clock selection */
@@ -211,7 +210,7 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
 			master_data |= control << 4;
 			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= (0x0F + 0xE1 * ap->port_no);
+			slave_data &= 0xF0;
 			/* Load the matching timing */
 			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
 			pci_write_config_byte(dev, 0x44, slave_data);
@@ -263,7 +262,7 @@ static int it8213_init_one (struct pci_dev *pdev, const struct pci_device_id *en
 	static const struct ata_port_info info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
-		.mwdma_mask	= ATA_MWDMA2,
+		.mwdma_mask	= ATA_MWDMA12_ONLY,
 		.udma_mask 	= ATA_UDMA4, /* FIXME: want UDMA 100? */
 		.port_ops	= &it8213_ops,
 	};
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 6932e56..9df1ff7 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -25,6 +25,13 @@
  *		http://www.ryston.cz/petr/vlb/pdc20230b.html
  *		http://www.ryston.cz/petr/vlb/pdc20230c.html
  *		http://www.ryston.cz/petr/vlb/pdc20630.html
+ *	QDI65x0:
+ *		http://www.ryston.cz/petr/vlb/qd6500.html
+ *		http://www.ryston.cz/petr/vlb/qd6580.html
+ *
+ *	QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c
+ *	Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by
+ *	Samuel Thibault <samuel.thibault@ens-lyon.org>
  *
  *  Unsupported but docs exist:
  *	Appian/Adaptec AIC25VL01/Cirrus Logic PD7220
@@ -35,7 +42,7 @@
  *  the MPIIX where the tuning is PCI side but the IDE is "ISA side".
  *
  *  Specific support is included for the ht6560a/ht6560b/opti82c611a/
- *  opti82c465mv/promise 20230c/20630/winbond83759A
+ *  opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A
  *
  *  Use the autospeed and pio_mask options with:
  *	Appian ADI/2 aka CLPD7220 or AIC25VL01.
@@ -672,7 +679,7 @@ static void qdi6580dp_set_piomode(struct ata_port *ap, struct ata_device *adev)
 	outb(timing, ld_qdi->timing + 2 * ap->port_no);
 	/* Clear the FIFO */
 	if (adev->class != ATA_DEV_ATA)
-		outb(0x5F, ld_qdi->timing + 3);
+		outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
 }
 
 /**
@@ -707,7 +714,7 @@ static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev)
 	outb(timing, ld_qdi->timing + 2 * adev->devno);
 	/* Clear the FIFO */
 	if (adev->class != ATA_DEV_ATA)
-		outb(0x5F, ld_qdi->timing + 3);
+		outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3);
 }
 
 /**
@@ -787,6 +794,7 @@ static struct ata_port_operations qdi6580_port_ops = {
 static struct ata_port_operations qdi6580dp_port_ops = {
 	.inherits	= &legacy_base_port_ops,
 	.set_piomode	= qdi6580dp_set_piomode,
+	.qc_issue	= qdi_qc_issue,
 	.sff_data_xfer	= vlb32_data_xfer,
 };
 
diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c
index 2096fb7..950da39 100644
--- a/drivers/ata/pata_marvell.c
+++ b/drivers/ata/pata_marvell.c
@@ -58,7 +58,7 @@ static int marvell_pata_active(struct pci_dev *pdev)
 }
 
 /**
- *	marvell_pre_reset	-	check for 40/80 pin
+ *	marvell_pre_reset	-	probe begin
  *	@link: link
  *	@deadline: deadline jiffies for the operation
  *
diff --git a/drivers/ata/pata_ns87415.c b/drivers/ata/pata_ns87415.c
index 773b159..061aa1c 100644
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -325,6 +325,13 @@ static struct scsi_host_template ns87415_sht = {
 	ATA_BMDMA_SHT(DRV_NAME),
 };
 
+static void ns87415_fixup(struct pci_dev *pdev)
+{
+	/* Select 512 byte sectors */
+	pci_write_config_byte(pdev, 0x55, 0xEE);
+	/* Select PIO0 8bit clocking */
+	pci_write_config_byte(pdev, 0x54, 0xB7);
+}
 
 /**
  *	ns87415_init_one - Register 87415 ATA PCI device with kernel services
@@ -371,10 +378,8 @@ static int ns87415_init_one (struct pci_dev *pdev, const struct pci_device_id *e
 	if (rc)
 		return rc;
 
-	/* Select 512 byte sectors */
-	pci_write_config_byte(pdev, 0x55, 0xEE);
-	/* Select PIO0 8bit clocking */
-	pci_write_config_byte(pdev, 0x54, 0xB7);
+	ns87415_fixup(pdev);
+
 	return ata_pci_sff_init_one(pdev, ppi, &ns87415_sht, NULL);
 }
 
@@ -384,6 +389,23 @@ static const struct pci_device_id ns87415_pci_tbl[] = {
 	{ }	/* terminate list */
 };
 
+#ifdef CONFIG_PM
+static int ns87415_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	ns87415_fixup(pdev);
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 static struct pci_driver ns87415_pci_driver = {
 	.name			= DRV_NAME,
 	.id_table		= ns87415_pci_tbl,
@@ -391,7 +413,7 @@ static struct pci_driver ns87415_pci_driver = {
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= ata_pci_device_resume,
+	.resume			= ns87415_reinit_one,
 #endif
 };
 
diff --git a/drivers/ata/pata_oldpiix.c b/drivers/ata/pata_oldpiix.c
index 84ac503..9a8687d 100644
--- a/drivers/ata/pata_oldpiix.c
+++ b/drivers/ata/pata_oldpiix.c
@@ -239,7 +239,7 @@ static int oldpiix_init_one (struct pci_dev *pdev, const struct pci_device_id *e
 	static const struct ata_port_info info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
-		.mwdma_mask	= ATA_MWDMA2,
+		.mwdma_mask	= ATA_MWDMA12_ONLY,
 		.port_ops	= &oldpiix_pata_ops,
 	};
 	const struct ata_port_info *ppi[] = { &info, NULL };
diff --git a/drivers/ata/pata_radisys.c b/drivers/ata/pata_radisys.c
index 4401b33..4fd25e7 100644
--- a/drivers/ata/pata_radisys.c
+++ b/drivers/ata/pata_radisys.c
@@ -139,9 +139,9 @@ static void radisys_set_dmamode (struct ata_port *ap, struct ata_device *adev)
 		pci_read_config_byte(dev, 0x4A, &udma_mode);
 
 		if (adev->xfer_mode == XFER_UDMA_2)
-			udma_mode &= ~ (1 << adev->devno);
+			udma_mode &= ~(2 << (adev->devno * 4));
 		else /* UDMA 4 */
-			udma_mode |= (1 << adev->devno);
+			udma_mode |= (2 << (adev->devno * 4));
 
 		pci_write_config_byte(dev, 0x4A, udma_mode);
 
diff --git a/drivers/ata/pata_rdc.c b/drivers/ata/pata_rdc.c
index c843a1e..237a24d 100644
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -284,7 +284,7 @@ static struct ata_port_info rdc_port_info = {
 
 	.flags		= ATA_FLAG_SLAVE_POSS,
 	.pio_mask	= ATA_PIO4,
-	.mwdma_mask	= ATA_MWDMA2,
+	.mwdma_mask	= ATA_MWDMA12_ONLY,
 	.udma_mask	= ATA_UDMA5,
 	.port_ops	= &rdc_pata_ops,
 };
diff --git a/drivers/ata/pata_rz1000.c b/drivers/ata/pata_rz1000.c
index a5e4dfe..2932998 100644
--- a/drivers/ata/pata_rz1000.c
+++ b/drivers/ata/pata_rz1000.c
@@ -105,11 +105,20 @@ static int rz1000_init_one (struct pci_dev *pdev, const struct pci_device_id *en
 #ifdef CONFIG_PM
 static int rz1000_reinit_one(struct pci_dev *pdev)
 {
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
 	/* If this fails on resume (which is a "cant happen" case), we
 	   must stop as any progress risks data loss */
 	if (rz1000_fifo_disable(pdev))
 		panic("rz1000 fifo");
-	return ata_pci_device_resume(pdev);
+
+	ata_host_resume(host);
+	return 0;
 }
 #endif
 
diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c
index d70ecec..8af0dc8 100644
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -2,7 +2,7 @@
  *    pata_sis.c - SiS ATA driver
  *
  *	(C) 2005 Red Hat
- *	(C) 2007 Bartlomiej Zolnierkiewicz
+ *	(C) 2007,2009 Bartlomiej Zolnierkiewicz
  *
  *    Based upon linux/drivers/ide/pci/sis5513.c
  * Copyright (C) 1999-2000	Andre Hedrick <andre@linux-ide.org>
@@ -876,6 +876,23 @@ static int sis_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
 	return ata_pci_sff_init_one(pdev, ppi, &sis_sht, chipset);
 }
 
+#ifdef CONFIG_PM
+static int sis_reinit_one(struct pci_dev *pdev)
+{
+	struct ata_host *host = dev_get_drvdata(&pdev->dev);
+	int rc;
+
+	rc = ata_pci_device_do_resume(pdev);
+	if (rc)
+		return rc;
+
+	sis_fixup(pdev, host->private_data);
+
+	ata_host_resume(host);
+	return 0;
+}
+#endif
+
 static const struct pci_device_id sis_pci_tbl[] = {
 	{ PCI_VDEVICE(SI, 0x5513), },	/* SiS 5513 */
 	{ PCI_VDEVICE(SI, 0x5518), },	/* SiS 5518 */
@@ -891,7 +908,7 @@ static struct pci_driver sis_pci_driver = {
 	.remove			= ata_pci_remove_one,
 #ifdef CONFIG_PM
 	.suspend		= ata_pci_device_suspend,
-	.resume			= ata_pci_device_resume,
+	.resume			= sis_reinit_one,
 #endif
 };
 
diff --git a/drivers/ata/pata_via.c b/drivers/ata/pata_via.c
index 78eac27..0d97890 100644
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -303,14 +303,21 @@ static void via_do_set_mode(struct ata_port *ap, struct ata_device *adev, int mo
 	}
 
 	/* Set UDMA unless device is not UDMA capable */
-	if (udma_type && t.udma) {
-		u8 cable80_status;
+	if (udma_type) {
+		u8 udma_etc;
 
-		/* Get 80-wire cable detection bit */
-		pci_read_config_byte(pdev, 0x50 + offset, &cable80_status);
-		cable80_status &= 0x10;
+		pci_read_config_byte(pdev, 0x50 + offset, &udma_etc);
 
-		pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status);
+		/* clear transfer mode bit */
+		udma_etc &= ~0x20;
+
+		if (t.udma) {
+			/* preserve 80-wire cable detection bit */
+			udma_etc &= 0x10;
+			udma_etc |= ut;
+		}
+
+		pci_write_config_byte(pdev, 0x50 + offset, udma_etc);
 	}
 }
 
diff --git a/drivers/ide/ide-pci-generic.c b/drivers/ide/ide-pci-generic.c
index 3f0bc42..a743e68 100644
--- a/drivers/ide/ide-pci-generic.c
+++ b/drivers/ide/ide-pci-generic.c
@@ -165,7 +165,7 @@ static const struct pci_device_id generic_pci_tbl[] = {
 	{ PCI_VDEVICE(TOSHIBA,	PCI_DEVICE_ID_TOSHIBA_PICCOLO_1),	 4 },
 	{ PCI_VDEVICE(TOSHIBA,	PCI_DEVICE_ID_TOSHIBA_PICCOLO_2),	 4 },
 	{ PCI_VDEVICE(TOSHIBA,	PCI_DEVICE_ID_TOSHIBA_PICCOLO_3),	 4 },
-	{ PCI_VDEVICE(TOSHIBA,	PCI_DEVICE_ID_TOSHIBA_PICCOLO_5)	 4 },
+	{ PCI_VDEVICE(TOSHIBA,	PCI_DEVICE_ID_TOSHIBA_PICCOLO_5),	 4 },
 	{ PCI_VDEVICE(NETCELL,	PCI_DEVICE_ID_REVOLUTION),		 6 },
 	/*
 	 * Must come last.  If you add entries adjust

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>> The merge window is upon us, which by strict rules means that anything
>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>>
>>>> However, bug fixes and the like should definitely be in 2.6.33.
>>>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
>>>> could go either way.
>>
>>> If you would like to apply some of my patches to 2.6.33 you are more than
>>> welcome to do it.  I can even prepare separate git tree with specific changes
>>> to make it easier for you once you tell me which changes you would like to
>>> see in it.
>>
>> OK, great.
>>
>> Can you prepare a patchset containing only fixes?  Comment-only changes
>> are acceptable too.  Trivial changes too, if they are extremely trivial :)
>>
>> Include nothing that adds features, removes or unifies drivers, etc.
>
> Since this is pretty high-level description and some changes fall into
> many categories at once (i.e. addition of proper PCI Power Management
> handling could be considered both as a fix and as a feature) I prepared
> a rather conservative set of changes (which means that unfortunately
> it misses many enhancements available in my tree):
>
>> Please do it in standard kernel submit form, which is either
>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
>> (b) a standard git pull request, which includes shortlog, diffstat, and
>> all-in-one diff.
>
> Thank you for the detailed explanation of the standard kernel submit
> form (I wonder how would I know this otherwise :) but the thing is that
> at the current moment I'm not submitting anything to the upstream.

Ok, that explains my confusion, then.  I had thought you intended to get 
this stuff upstream, and into users' hands.


> That's it.  While this may sound strange to some people it turns out
> that in practice it is much less hassle for me personally to keep some
> of trees outside of the (sometimes greatly overrated) upstream.
>
> If knowing the above you still would like to include the aforementioned
> set of changes in your libata-dev tree they are at kernel.org now.

I will go through this batch and cherry-pick.  The build fix is already 
in my tree.  Existing kernel practice (and previous comments) indicate 
that lists of known issues do not belong in Kconfig.  Will take a look 
at the other stuff...

Thanks,

	Jeff

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>> The merge window is upon us, which by strict rules means that anything
> >>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
> >>>>
> >>>> However, bug fixes and the like should definitely be in 2.6.33.
> >>>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
> >>>> could go either way.
> >>
> >>> If you would like to apply some of my patches to 2.6.33 you are more than
> >>> welcome to do it.  I can even prepare separate git tree with specific changes
> >>> to make it easier for you once you tell me which changes you would like to
> >>> see in it.
> >>
> >> OK, great.
> >>
> >> Can you prepare a patchset containing only fixes?  Comment-only changes
> >> are acceptable too.  Trivial changes too, if they are extremely trivial :)
> >>
> >> Include nothing that adds features, removes or unifies drivers, etc.
> >
> > Since this is pretty high-level description and some changes fall into
> > many categories at once (i.e. addition of proper PCI Power Management
> > handling could be considered both as a fix and as a feature) I prepared
> > a rather conservative set of changes (which means that unfortunately
> > it misses many enhancements available in my tree):
> >
> >> Please do it in standard kernel submit form, which is either
> >> (a) repost the patches (yes, again) being submitted for 2.6.33, or
> >> (b) a standard git pull request, which includes shortlog, diffstat, and
> >> all-in-one diff.
> >
> > Thank you for the detailed explanation of the standard kernel submit
> > form (I wonder how would I know this otherwise :) but the thing is that
> > at the current moment I'm not submitting anything to the upstream.
> 
> Ok, that explains my confusion, then.  I had thought you intended to get 
> this stuff upstream, and into users' hands.

Interesting argument but the vast majority of users use distribution kernels
which are not upstream and I doubt that any self-respecting distribution would
miss such amount of fixes.

The rest can easily use my tree which follows upstream closely and can be
obtained using a single line git command.

> > That's it.  While this may sound strange to some people it turns out
> > that in practice it is much less hassle for me personally to keep some
> > of trees outside of the (sometimes greatly overrated) upstream.
> >
> > If knowing the above you still would like to include the aforementioned
> > set of changes in your libata-dev tree they are at kernel.org now.
> 
> I will go through this batch and cherry-pick.  The build fix is already 
> in my tree.  Existing kernel practice (and previous comments) indicate 
> that lists of known issues do not belong in Kconfig.  Will take a look 
> at the other stuff...

Well, you were aware that they were not dropped so you could have easily told
me that you specifically don't want this patches in the for-2.6.33 tree..

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>> The merge window is upon us, which by strict rules means that anything
>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>>>>
>>>>>> However, bug fixes and the like should definitely be in 2.6.33.
>>>>>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
>>>>>> could go either way.
>>>>
>>>>> If you would like to apply some of my patches to 2.6.33 you are more than
>>>>> welcome to do it.  I can even prepare separate git tree with specific changes
>>>>> to make it easier for you once you tell me which changes you would like to
>>>>> see in it.
>>>>
>>>> OK, great.
>>>>
>>>> Can you prepare a patchset containing only fixes?  Comment-only changes
>>>> are acceptable too.  Trivial changes too, if they are extremely trivial :)
>>>>
>>>> Include nothing that adds features, removes or unifies drivers, etc.
>>>
>>> Since this is pretty high-level description and some changes fall into
>>> many categories at once (i.e. addition of proper PCI Power Management
>>> handling could be considered both as a fix and as a feature) I prepared
>>> a rather conservative set of changes (which means that unfortunately
>>> it misses many enhancements available in my tree):
>>>
>>>> Please do it in standard kernel submit form, which is either
>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
>>>> (b) a standard git pull request, which includes shortlog, diffstat, and
>>>> all-in-one diff.
>>>
>>> Thank you for the detailed explanation of the standard kernel submit
>>> form (I wonder how would I know this otherwise :) but the thing is that
>>> at the current moment I'm not submitting anything to the upstream.
>>
>> Ok, that explains my confusion, then.  I had thought you intended to get
>> this stuff upstream, and into users' hands.
>
> Interesting argument but the vast majority of users use distribution kernels
> which are not upstream and I doubt that any self-respecting distribution would
> miss such amount of fixes.

Interesting argument, but applied across 1000+ developers this is 
clearly an unscalable development model for distributions.  Thus, 
patches go upstream, and are then distributed widely, to eliminate 
massive amounts of duplicated work across distributions.

You are essentially implying that each distribution must

	- discover your tree
	- look through the mailing list to figure out why each of
	  ~80 changes are not upstream
	- individually make a decision on each of ~80 changes
	- actively track your tree for updates, repeating this process
	  over and over again

Talk about a lot of unwanted work pushed upon OTHER people, all because 
you choose to avoid the standard upstream development process.


>>> That's it.  While this may sound strange to some people it turns out
>>> that in practice it is much less hassle for me personally to keep some
>>> of trees outside of the (sometimes greatly overrated) upstream.
>>>
>>> If knowing the above you still would like to include the aforementioned
>>> set of changes in your libata-dev tree they are at kernel.org now.
>>
>> I will go through this batch and cherry-pick.  The build fix is already
>> in my tree.  Existing kernel practice (and previous comments) indicate
>> that lists of known issues do not belong in Kconfig.  Will take a look
>> at the other stuff...
>
> Well, you were aware that they were not dropped so you could have easily told
> me that you specifically don't want this patches in the for-2.6.33 tree..

At the time you built atang-2.6.33, you were aware that those Kconfig 
changes were not wanted -at all-.

You tell others "I think that there were enough hints in my mail 
already" then fail to apply this logic to yourself.

	Jeff

Re: [PATCH 00/86] PATA fixes

[David Miller]

From: Jeff Garzik <jeff@garzik.org>
Date: Thu, 03 Dec 2009 12:39:48 -0500

> On 12/03/2009 11:59 AM, Alan Cox wrote:
>>> The merge window is upon us, which by strict rules means that anything
>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>
>> Not quite yet - Linus hasn't said "go"
> 
> He rarely if ever says "go."  The kernel X is released, and people
> send pull requests to Linus for X+1.  He typically merges immediately,
> but does not push out the first set of merges for a few days.

I don't think he even starts pulling until 1 or 2 days later.

I personally never send him a pull request until a day or two in.

Re: [PATCH 16/86] pata_efar: MWDMA0 is unsupported

[Jeff Garzik]

On 11/26/2009 10:15 AM, Alan Cox wrote:
> On Thu, 26 Nov 2009 15:53:58 +0100
> Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>  wrote:
>
>> On Wednesday 25 November 2009 06:25:52 pm Alan Cox wrote:
>>> On Wed, 25 Nov 2009 18:04:15 +0100
>>> Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>  wrote:
>>>
>>>> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
>>>> Subject: [PATCH] pata_efar: MWDMA0 is unsupported
>>>>
>>>> MWDMA0 timings cannot be met with the PIIX based controller
>>>> programming interface.
>>>
>>> The efar documentation makes no reference to not being capable of MWDMA0,
>>> so where does this come from ? No MWDMA0 is an Intel erratum it appears.
>>
>> No MWDMA0 support is a common issue on all 'PIIX-like' controllers.
>>
>> In case of this chipset while the (preliminary) documentation claims MWDMA0
>> support on the 'FEATURES' page the later 'programming guide' part describes
>> only PIO0-4, SWDMA2, MWDMA1-2 and UDMA0-4 transfer modes as supported.
>
> Cool - I only have the original docs.

ACK Bart's patch, then?

This thread was a bit unclear, and I want to be certain (well, as 
certain as we can be :))

	Jeff

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> >> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>>>> The merge window is upon us, which by strict rules means that anything
> >>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
> >>>>>>
> >>>>>> However, bug fixes and the like should definitely be in 2.6.33.
> >>>>>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
> >>>>>> could go either way.
> >>>>
> >>>>> If you would like to apply some of my patches to 2.6.33 you are more than
> >>>>> welcome to do it.  I can even prepare separate git tree with specific changes
> >>>>> to make it easier for you once you tell me which changes you would like to
> >>>>> see in it.
> >>>>
> >>>> OK, great.
> >>>>
> >>>> Can you prepare a patchset containing only fixes?  Comment-only changes
> >>>> are acceptable too.  Trivial changes too, if they are extremely trivial :)
> >>>>
> >>>> Include nothing that adds features, removes or unifies drivers, etc.
> >>>
> >>> Since this is pretty high-level description and some changes fall into
> >>> many categories at once (i.e. addition of proper PCI Power Management
> >>> handling could be considered both as a fix and as a feature) I prepared
> >>> a rather conservative set of changes (which means that unfortunately
> >>> it misses many enhancements available in my tree):
> >>>
> >>>> Please do it in standard kernel submit form, which is either
> >>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
> >>>> (b) a standard git pull request, which includes shortlog, diffstat, and
> >>>> all-in-one diff.
> >>>
> >>> Thank you for the detailed explanation of the standard kernel submit
> >>> form (I wonder how would I know this otherwise :) but the thing is that
> >>> at the current moment I'm not submitting anything to the upstream.
> >>
> >> Ok, that explains my confusion, then.  I had thought you intended to get
> >> this stuff upstream, and into users' hands.
> >
> > Interesting argument but the vast majority of users use distribution kernels
> > which are not upstream and I doubt that any self-respecting distribution would
> > miss such amount of fixes.
> 
> Interesting argument, but applied across 1000+ developers this is 
> clearly an unscalable development model for distributions.  Thus, 

Interesting that you have brought distributions' convenience before
non-distribution developers' one.

> patches go upstream, and are then distributed widely, to eliminate 
> massive amounts of duplicated work across distributions.
> 
> You are essentially implying that each distribution must
> 
> 	- discover your tree
> 	- look through the mailing list to figure out why each of
> 	  ~80 changes are not upstream
> 	- individually make a decision on each of ~80 changes
> 	- actively track your tree for updates, repeating this process
> 	  over and over again

Not really.

I'm only saying that the upstream is so much hassle to deal with it that
it is up to people wanting to see my changes upstream to do the work on
integrating them upstream if they want to see them in upstream faster.

Fair enough?

> Talk about a lot of unwanted work pushed upon OTHER people, all because 
> you choose to avoid the standard upstream development process.

I'm not forcing any work on anybody and I'm not avoiding the standard
process.  I just find other things to have higher priority than pushing
these changes upstream right now.

> >>> That's it.  While this may sound strange to some people it turns out
> >>> that in practice it is much less hassle for me personally to keep some
> >>> of trees outside of the (sometimes greatly overrated) upstream.
> >>>
> >>> If knowing the above you still would like to include the aforementioned
> >>> set of changes in your libata-dev tree they are at kernel.org now.
> >>
> >> I will go through this batch and cherry-pick.  The build fix is already
> >> in my tree.  Existing kernel practice (and previous comments) indicate
> >> that lists of known issues do not belong in Kconfig.  Will take a look
> >> at the other stuff...
> >
> > Well, you were aware that they were not dropped so you could have easily told
> > me that you specifically don't want this patches in the for-2.6.33 tree..
> 
> At the time you built atang-2.6.33, you were aware that those Kconfig 
> changes were not wanted -at all-.

Why should I remember/care/worry about such details?

> You tell others "I think that there were enough hints in my mail 
> already" then fail to apply this logic to yourself.

You forgot that it was you who have asked me to prepare this tree to
enhance your tree.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

Alan,

Can you sanity check me on these?

> Bartlomiej Zolnierkiewicz (28):
>        ide-pci-generic: build fix

ACK but skipped -- already applied myself

>        ata_piix: fix MWDMA handling on PIIX3

applied

>        pata_efar: fix wrong PIO timings being programmed

applied

>        pata_efar: fix wrong MWDMA timings being programmed

applied

>        pata_efar: MWDMA0 is unsupported

skipped, pending discussion (just sent email)

>        pata_cmd640: document known issues

rejected, for reasons already explained

>        pata_cs5520: remove dead VDMA support

applied

>        pata_cypress: document known issues

rejected, for reasons already explained

>        pata_hpt3x2n: fix overclocked MWDMA0 timing

skipped, pending discussion (just sent email)

>        pata_hpt3x3: Power Management fix

applied, on a hope and a prayer (did not see this posted to mailing 
list?).  It looks correct to me.

>        pata_it8213: fix UDMA handling

applied

>        pata_it8213: fix wrong PIO timings being programmed

applied

>        pata_it8213: fix PIO2 underclocking

applied

>        pata_it8213: fix wrong MWDMA timings being programmed

applied

>        pata_it8213: fix it8213_pre_reset() documentation

applied

>        pata_it8213: MWDMA0 is unsupported

skipped, pending discussion (just sent email)

>        pata_legacy: fix QDI6580DP support

applied

>        pata_legacy: fix access to control register for QDI6580

applied

>        pata_legacy: add pointers to QDI65x0 documentation

applied.  I did not think the file path issue raised was important 
enough to warrant patch rejection.

>        pata_marvell: fix marvell_pre_reset() documentation

applied

>        pata_ns87415: Power Management fix

applied

>        pata_oldpiix: MWDMA0 is unsupported

skipped -- Alan, Sergey, comments?

>        pata_pdc202xx_old: document known issues

rejected, for reasons already explained

>        pata_radisys: fix UDMA handling

applied

>        pata_rdc: MWDMA0 is unsupported

skipped -- Alan, Sergey, comments?

>        pata_rz1000: Power Management fix

applied

>        pata_sis: Power Management fix

applied

>        pata_via: clear UDMA transfer mode bit for PIO and MWDMA

applied -- even though Alan's comment was correct.  It is standard 
kernel practice to place cosmetic changes into their own patches, 
because it is standard kernel practice to break up logically distinct 
changes.

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 04:01 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
>> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>>>> The merge window is upon us, which by strict rules means that anything
>>>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>>>>>>
>>>>>>>> However, bug fixes and the like should definitely be in 2.6.33.
>>>>>>>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
>>>>>>>> could go either way.
>>>>>>
>>>>>>> If you would like to apply some of my patches to 2.6.33 you are more than
>>>>>>> welcome to do it.  I can even prepare separate git tree with specific changes
>>>>>>> to make it easier for you once you tell me which changes you would like to
>>>>>>> see in it.
>>>>>>
>>>>>> OK, great.
>>>>>>
>>>>>> Can you prepare a patchset containing only fixes?  Comment-only changes
>>>>>> are acceptable too.  Trivial changes too, if they are extremely trivial :)
>>>>>>
>>>>>> Include nothing that adds features, removes or unifies drivers, etc.
>>>>>
>>>>> Since this is pretty high-level description and some changes fall into
>>>>> many categories at once (i.e. addition of proper PCI Power Management
>>>>> handling could be considered both as a fix and as a feature) I prepared
>>>>> a rather conservative set of changes (which means that unfortunately
>>>>> it misses many enhancements available in my tree):
>>>>>
>>>>>> Please do it in standard kernel submit form, which is either
>>>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
>>>>>> (b) a standard git pull request, which includes shortlog, diffstat, and
>>>>>> all-in-one diff.
>>>>>
>>>>> Thank you for the detailed explanation of the standard kernel submit
>>>>> form (I wonder how would I know this otherwise :) but the thing is that
>>>>> at the current moment I'm not submitting anything to the upstream.
>>>>
>>>> Ok, that explains my confusion, then.  I had thought you intended to get
>>>> this stuff upstream, and into users' hands.
>>>
>>> Interesting argument but the vast majority of users use distribution kernels
>>> which are not upstream and I doubt that any self-respecting distribution would
>>> miss such amount of fixes.
>>
>> Interesting argument, but applied across 1000+ developers this is
>> clearly an unscalable development model for distributions.  Thus,
>
> Interesting that you have brought distributions' convenience before
> non-distribution developers' one.

uhwhu?  You brought up distributions.


>> patches go upstream, and are then distributed widely, to eliminate
>> massive amounts of duplicated work across distributions.
>>
>> You are essentially implying that each distribution must
>>
>> 	- discover your tree
>> 	- look through the mailing list to figure out why each of
>> 	  ~80 changes are not upstream
>> 	- individually make a decision on each of ~80 changes
>> 	- actively track your tree for updates, repeating this process
>> 	  over and over again
>
> Not really.
>
> I'm only saying that the upstream is so much hassle to deal with it that
> it is up to people wanting to see my changes upstream to do the work on
> integrating them upstream if they want to see them in upstream faster.
>
> Fair enough?

I respect your opinion, sure.  And respect that your time is your own. 
And appreciate you spending that time to batch together some patches.

But it is simple logic that a non-standard distribution method for your 
changes implies a self-imposed limited distribution, with possibly 
useful fixes and changes not getting into the hands of users that can 
use them.

That's your choice -- but it surprised me, is all.  Usually developers 
are more eager to get their changes into wide distribution, because that 
benefits the most Linux users.

If you fail to send changes upstream, most people will assume that you 
do not consider your changes "ready" for users, "ready" for wide 
distribution and use.  Because that is the common practice for nearly 
all other Linux kernel developers in all subsystems.

	Jeff

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 03:48 PM, David Miller wrote:
> From: Jeff Garzik<jeff@garzik.org>
> Date: Thu, 03 Dec 2009 12:39:48 -0500
>
>> On 12/03/2009 11:59 AM, Alan Cox wrote:
>>>> The merge window is upon us, which by strict rules means that anything
>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>
>>> Not quite yet - Linus hasn't said "go"
>>
>> He rarely if ever says "go."  The kernel X is released, and people
>> send pull requests to Linus for X+1.  He typically merges immediately,
>> but does not push out the first set of merges for a few days.
>
> I don't think he even starts pulling until 1 or 2 days later.
>
> I personally never send him a pull request until a day or two in.

<shrug>  In the past he has commented on pulls, indicating some sort of 
immediate action, yet not pushed for a few days.

Not a big deal.  Plenty of other people send pull requests immediately, 
even if you ignore the high-volume Ingo special case <chuckle>

In any case, the basic point is that Linus does not say "go" for merge 
windows.  People send, he pulls when he chooses, and pushes when he 
chooses.  It's all very zen ;-)

	Jeff

Re: [PATCH 00/86] PATA fixes

[David Miller]

From: Jeff Garzik <jeff@garzik.org>
Date: Thu, 03 Dec 2009 16:32:13 -0500

> In any case, the basic point is that Linus does not say "go" for merge
> windows.  People send, he pulls when he chooses, and pushes when he
> chooses.  It's all very zen ;-)

True.

But I also want to mention that I wait 2 days for another reason,
so that whatever I do toss to him gets full exposure in -next
at least one time.

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote:

> >        pata_efar: MWDMA0 is unsupported
> 
> skipped, pending discussion (just sent email)

The discussion was there, you were not especially interested
(http://lkml.org/lkml/2009/11/26/343).

> >        pata_hpt3x2n: fix overclocked MWDMA0 timing
> 
> skipped, pending discussion (just sent email)

ditto (http://lkml.org/lkml/2009/11/27/257).

There were no complains so I'm pretty sure Sergei was fine with it.

> >        pata_hpt3x3: Power Management fix
> 
> applied, on a hope and a prayer (did not see this posted to mailing 
> list?).  It looks correct to me.

I prefer sticking to technical facts. ;)

Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321

> >        pata_via: clear UDMA transfer mode bit for PIO and MWDMA
> 
> applied -- even though Alan's comment was correct.  It is standard 
> kernel practice to place cosmetic changes into their own patches, 
> because it is standard kernel practice to break up logically distinct 
> changes.

We are talking about:

 pata_via.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
is clearly documented in the patch description.


Do people really wonder why I find upstream to be too much hassle to
deal with?

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 04:42 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote:
>
>>>         pata_efar: MWDMA0 is unsupported
>>
>> skipped, pending discussion (just sent email)
>
> The discussion was there, you were not especially interested
> (http://lkml.org/lkml/2009/11/26/343).

I reviewed the discussion before adding an email to that thread.


>>>         pata_hpt3x2n: fix overclocked MWDMA0 timing
>>
>> skipped, pending discussion (just sent email)
>
> ditto (http://lkml.org/lkml/2009/11/27/257).

I reviewed the discussion before adding an email to that thread.


> There were no complains so I'm pretty sure Sergei was fine with it.

It was unclear, hence I sent email for clarification.


>>>         pata_hpt3x3: Power Management fix
>>
>> applied, on a hope and a prayer (did not see this posted to mailing
>> list?).  It looks correct to me.
>
> I prefer sticking to technical facts. ;)
>
> Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321

Whoops, I indeed missed this one.


>>>         pata_via: clear UDMA transfer mode bit for PIO and MWDMA
>>
>> applied -- even though Alan's comment was correct.  It is standard
>> kernel practice to place cosmetic changes into their own patches,
>> because it is standard kernel practice to break up logically distinct
>> changes.
>
> We are talking about:
>
>   pata_via.c |   19 +++++++++++++------
>   1 file changed, 13 insertions(+), 6 deletions(-)
>
> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
> is clearly documented in the patch description.
>
>
> Do people really wonder why I find upstream to be too much hassle to
> deal with?

The thousand other kernel developers seem to be able to split up their 
patches, separating out cosmetic changes from functional ones.  It has 
clear engineering benefits, and has been standard practice for a decade 
or more.

Why is it such an imposition for your patches to look like everyone 
else's?  And by "everyone", I mean all other kernel developers, not just 
other ATA developers.

You seem to consider standard kernel practice a hassle.  Separating out 
cosmetic changes is not only a libata practice, it is the norm for the 
entire kernel.

	Jeff

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:

> >>>         pata_via: clear UDMA transfer mode bit for PIO and MWDMA
> >>
> >> applied -- even though Alan's comment was correct.  It is standard
> >> kernel practice to place cosmetic changes into their own patches,
> >> because it is standard kernel practice to break up logically distinct
> >> changes.
> >
> > We are talking about:
> >
> >   pata_via.c |   19 +++++++++++++------
> >   1 file changed, 13 insertions(+), 6 deletions(-)
> >
> > patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
> > is clearly documented in the patch description.
> >
> >
> > Do people really wonder why I find upstream to be too much hassle to
> > deal with?
> 
> The thousand other kernel developers seem to be able to split up their 
> patches, separating out cosmetic changes from functional ones.  It has 
> clear engineering benefits, and has been standard practice for a decade 
> or more.
> 
> Why is it such an imposition for your patches to look like everyone 
> else's?  And by "everyone", I mean all other kernel developers, not just 
> other ATA developers.
> 
> You seem to consider standard kernel practice a hassle.  Separating out 
> cosmetic changes is not only a libata practice, it is the norm for the 
> entire kernel.

Indeed.

>From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
From: Jeff Garzik <jeff@garzik.org>
Date: Fri, 16 Jan 2009 10:17:09 -0500
Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
 for SAS drivers.

Caught by Ke Wei (and team?) at Marvell.

Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
general trend.

Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
---
 drivers/ata/libata-core.c           |    1 -
 drivers/ata/libata-scsi.c           |   17 +++++++++++++----
 drivers/scsi/ipr.c                  |    2 +-
 drivers/scsi/libsas/sas_scsi_host.c |    2 +-
 include/linux/libata.h              |    2 ++
 5 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 71218d7..552ecae 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6638,7 +6638,6 @@ EXPORT_SYMBOL_GPL(ata_dev_pair);
 EXPORT_SYMBOL_GPL(ata_port_disable);
 EXPORT_SYMBOL_GPL(ata_ratelimit);
 EXPORT_SYMBOL_GPL(ata_wait_register);
-EXPORT_SYMBOL_GPL(ata_scsi_ioctl);
 EXPORT_SYMBOL_GPL(ata_scsi_queuecmd);
 EXPORT_SYMBOL_GPL(ata_scsi_slave_config);
 EXPORT_SYMBOL_GPL(ata_scsi_slave_destroy);
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 9e92107..a1a6e62 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -423,9 +423,9 @@ int ata_std_bios_param(struct scsi_device *sdev, struct block_device *bdev,
  *	RETURNS:
  *	Zero on success, negative errno on error.
  */
-static int ata_get_identity(struct scsi_device *sdev, void __user *arg)
+static int ata_get_identity(struct ata_port *ap, struct scsi_device *sdev,
+			    void __user *arg)
 {
-	struct ata_port *ap = ata_shost_to_port(sdev->host);
 	struct ata_device *dev = ata_scsi_find_dev(ap, sdev);
 	u16 __user *dst = arg;
 	char buf[40];
@@ -645,7 +645,8 @@ int ata_task_ioctl(struct scsi_device *scsidev, void __user *arg)
 	return rc;
 }
 
-int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
+int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *scsidev,
+		     int cmd, void __user *arg)
 {
 	int val = -EINVAL, rc = -EINVAL;
 
@@ -663,7 +664,7 @@ int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
 		return 0;
 
 	case HDIO_GET_IDENTITY:
-		return ata_get_identity(scsidev, arg);
+		return ata_get_identity(ap, scsidev, arg);
 
 	case HDIO_DRIVE_CMD:
 		if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
@@ -682,6 +683,14 @@ int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
 
 	return rc;
 }
+EXPORT_SYMBOL_GPL(ata_sas_scsi_ioctl);
+
+int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
+{
+	return ata_sas_scsi_ioctl(ata_shost_to_port(scsidev->host),
+				scsidev, cmd, arg);
+}
+EXPORT_SYMBOL_GPL(ata_scsi_ioctl);
 
 /**
  *	ata_scsi_qc_new - acquire new ata_queued_cmd reference
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 841f460..0782900 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -4912,7 +4912,7 @@ static int ipr_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
 	if (res && ipr_is_gata(res)) {
 		if (cmd == HDIO_GET_IDENTITY)
 			return -ENOTTY;
-		return ata_scsi_ioctl(sdev, cmd, arg);
+		return ata_sas_scsi_ioctl(res->sata_port->ap, sdev, cmd, arg);
 	}
 
 	return -EINVAL;
diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c
index 7448387..1c558d3 100644
--- a/drivers/scsi/libsas/sas_scsi_host.c
+++ b/drivers/scsi/libsas/sas_scsi_host.c
@@ -717,7 +717,7 @@ int sas_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
 	struct domain_device *dev = sdev_to_domain_dev(sdev);
 
 	if (dev_is_sata(dev))
-		return ata_scsi_ioctl(sdev, cmd, arg);
+		return ata_sas_scsi_ioctl(dev->sata_dev.ap, sdev, cmd, arg);
 
 	return -EINVAL;
 }
diff --git a/include/linux/libata.h b/include/linux/libata.h
index b6b8a7f..73b69c7 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -927,6 +927,8 @@ extern void ata_host_init(struct ata_host *, struct device *,
 extern int ata_scsi_detect(struct scsi_host_template *sht);
 extern int ata_scsi_ioctl(struct scsi_device *dev, int cmd, void __user *arg);
 extern int ata_scsi_queuecmd(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *));
+extern int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *dev,
+			    int cmd, void __user *arg);
 extern void ata_sas_port_destroy(struct ata_port *);
 extern struct ata_port *ata_sas_port_alloc(struct ata_host *,
 					   struct ata_port_info *, struct Scsi_Host *);
-- 
1.6.4.2



--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
>
>>>>>          pata_via: clear UDMA transfer mode bit for PIO and MWDMA
>>>>
>>>> applied -- even though Alan's comment was correct.  It is standard
>>>> kernel practice to place cosmetic changes into their own patches,
>>>> because it is standard kernel practice to break up logically distinct
>>>> changes.
>>>
>>> We are talking about:
>>>
>>>    pata_via.c |   19 +++++++++++++------
>>>    1 file changed, 13 insertions(+), 6 deletions(-)
>>>
>>> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
>>> is clearly documented in the patch description.
>>>
>>>
>>> Do people really wonder why I find upstream to be too much hassle to
>>> deal with?
>>
>> The thousand other kernel developers seem to be able to split up their
>> patches, separating out cosmetic changes from functional ones.  It has
>> clear engineering benefits, and has been standard practice for a decade
>> or more.
>>
>> Why is it such an imposition for your patches to look like everyone
>> else's?  And by "everyone", I mean all other kernel developers, not just
>> other ATA developers.
>>
>> You seem to consider standard kernel practice a hassle.  Separating out
>> cosmetic changes is not only a libata practice, it is the norm for the
>> entire kernel.
>
> Indeed.
>
>  From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
> From: Jeff Garzik<jeff@garzik.org>
> Date: Fri, 16 Jan 2009 10:17:09 -0500
> Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
>   for SAS drivers.
>
> Caught by Ke Wei (and team?) at Marvell.
>
> Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
> general trend.
>
> Acked-by: James Bottomley<James.Bottomley@HansenPartnership.com>
> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>

If your point, by posting this patch, is that it includes a ton of 
gratuitous cosmetic changes, you misread the patch.

ata_scsi_ioctl() remains in existence; only the callers need to use the 
new SAS-related ioctl function were updated.  The remainder continued to 
use ata_scsi_ioctl().

	Jeff

Re: [PATCH 00/86] PATA fixes

[Sergei Shtylyov]

Hello.

Jeff Garzik wrote:

>>        pata_efar: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)

   There's basically nothing to discuss -- the PIIX like chips don't 
support MWDMA0 (with an acceptable cycle length, if at all, anyway). The 
way the driver is written, MWDMA0 is simply programmed overclocked.

>
>>        pata_hpt3x2n: fix overclocked MWDMA0 timing
>
> skipped, pending discussion (just sent email)


   Nothing to discuss either, this looks like a single digit typo to me...

>
>>        pata_hpt3x3: Power Management fix
>
> applied, on a hope and a prayer (did not see this posted to mailing 
> list?).

   http://marc.info/?l=linux-ide&m=125916980522990

>
>>        pata_it8213: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)

   Nothing to discuss...

>        pata_oldpiix: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

>
>>        pata_rdc: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

MBR, Sergei

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
> >
> >>>>>          pata_via: clear UDMA transfer mode bit for PIO and MWDMA
> >>>>
> >>>> applied -- even though Alan's comment was correct.  It is standard
> >>>> kernel practice to place cosmetic changes into their own patches,
> >>>> because it is standard kernel practice to break up logically distinct
> >>>> changes.
> >>>
> >>> We are talking about:
> >>>
> >>>    pata_via.c |   19 +++++++++++++------
> >>>    1 file changed, 13 insertions(+), 6 deletions(-)
> >>>
> >>> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
> >>> is clearly documented in the patch description.
> >>>
> >>>
> >>> Do people really wonder why I find upstream to be too much hassle to
> >>> deal with?
> >>
> >> The thousand other kernel developers seem to be able to split up their
> >> patches, separating out cosmetic changes from functional ones.  It has
> >> clear engineering benefits, and has been standard practice for a decade
> >> or more.
> >>
> >> Why is it such an imposition for your patches to look like everyone
> >> else's?  And by "everyone", I mean all other kernel developers, not just
> >> other ATA developers.
> >>
> >> You seem to consider standard kernel practice a hassle.  Separating out
> >> cosmetic changes is not only a libata practice, it is the norm for the
> >> entire kernel.
> >
> > Indeed.
> >
> >  From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
> > From: Jeff Garzik<jeff@garzik.org>
> > Date: Fri, 16 Jan 2009 10:17:09 -0500
> > Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
> >   for SAS drivers.
> >
> > Caught by Ke Wei (and team?) at Marvell.
> >
> > Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
> > general trend.
> >
> > Acked-by: James Bottomley<James.Bottomley@HansenPartnership.com>
> > Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
> 
> If your point, by posting this patch, is that it includes a ton of 
> gratuitous cosmetic changes, you misread the patch.
> 
> ata_scsi_ioctl() remains in existence; only the callers need to use the 
> new SAS-related ioctl function were updated.  The remainder continued to 
> use ata_scsi_ioctl().

Moving kernel exports around is completely unrelated to a bug fix.

Yes, it is convenient to do it in the same patch and OK with me.

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 05:02 PM, Sergei Shtylyov wrote:
> Hello.
>
> Jeff Garzik wrote:
>
>>> pata_efar: MWDMA0 is unsupported
>>
>> skipped, pending discussion (just sent email)
>
> There's basically nothing to discuss -- the PIIX like chips don't
> support MWDMA0 (with an acceptable cycle length, if at all, anyway). The
> way the driver is written, MWDMA0 is simply programmed overclocked.
>
>>
>>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>>
>> skipped, pending discussion (just sent email)
>
>
> Nothing to discuss either, this looks like a single digit typo to me...
>
>>
>>> pata_hpt3x3: Power Management fix
>>
>> applied, on a hope and a prayer (did not see this posted to mailing
>> list?).
>
> http://marc.info/?l=linux-ide&m=125916980522990

Yeah, missed that.  Bart provided a link, too.


>>> pata_it8213: MWDMA0 is unsupported
>>
>> skipped, pending discussion (just sent email)
>
> Nothing to discuss...

Perhaps discuss was the wrong word.  After reviewing each thread, in 
each case, it remained unclear whether the original patch was correct or 
not, especially since the docs seemed to list MWDMA0 as supported on 
PIIX-like chips.

Thanks for going over these, that should clear up my confusion.

	Jeff

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 05:06 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
>> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
>>>
>>>>>>>           pata_via: clear UDMA transfer mode bit for PIO and MWDMA
>>>>>>
>>>>>> applied -- even though Alan's comment was correct.  It is standard
>>>>>> kernel practice to place cosmetic changes into their own patches,
>>>>>> because it is standard kernel practice to break up logically distinct
>>>>>> changes.
>>>>>
>>>>> We are talking about:
>>>>>
>>>>>     pata_via.c |   19 +++++++++++++------
>>>>>     1 file changed, 13 insertions(+), 6 deletions(-)
>>>>>
>>>>> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
>>>>> is clearly documented in the patch description.
>>>>>
>>>>>
>>>>> Do people really wonder why I find upstream to be too much hassle to
>>>>> deal with?
>>>>
>>>> The thousand other kernel developers seem to be able to split up their
>>>> patches, separating out cosmetic changes from functional ones.  It has
>>>> clear engineering benefits, and has been standard practice for a decade
>>>> or more.
>>>>
>>>> Why is it such an imposition for your patches to look like everyone
>>>> else's?  And by "everyone", I mean all other kernel developers, not just
>>>> other ATA developers.
>>>>
>>>> You seem to consider standard kernel practice a hassle.  Separating out
>>>> cosmetic changes is not only a libata practice, it is the norm for the
>>>> entire kernel.
>>>
>>> Indeed.
>>>
>>>   From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
>>> From: Jeff Garzik<jeff@garzik.org>
>>> Date: Fri, 16 Jan 2009 10:17:09 -0500
>>> Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
>>>    for SAS drivers.
>>>
>>> Caught by Ke Wei (and team?) at Marvell.
>>>
>>> Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
>>> general trend.
>>>
>>> Acked-by: James Bottomley<James.Bottomley@HansenPartnership.com>
>>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
>>
>> If your point, by posting this patch, is that it includes a ton of
>> gratuitous cosmetic changes, you misread the patch.
>>
>> ata_scsi_ioctl() remains in existence; only the callers need to use the
>> new SAS-related ioctl function were updated.  The remainder continued to
>> use ata_scsi_ioctl().
>
> Moving kernel exports around is completely unrelated to a bug fix.

Did the patch contain -cosmetic- changes intermingled with code changes, 
in the same code lines?  No.

Is it good kernel practice to intermingle cosmetic changes with 
functional ones, in the same code lines?  Also, no.

	Jeff

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 05:10 PM, Jeff Garzik wrote:
> Did the patch contain -cosmetic- changes intermingled with code changes,
> in the same code lines? No.
>
> Is it good kernel practice to intermingle cosmetic changes with
> functional ones, in the same code lines? Also, no.


In fact, I recall one case where a certain developer on this list used 
cosmetic code changes (Lindent, IIRC) to hide functional, 
security-related code changes.

Mixing cosmetic and function changes is simply bad engineering practice, 
_especially_ when they occur in the same lines of code.

	Jeff

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 11:10:51 pm Jeff Garzik wrote:
> On 12/03/2009 05:06 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
> >> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
> >>>
> >>>>>>>           pata_via: clear UDMA transfer mode bit for PIO and MWDMA
> >>>>>>
> >>>>>> applied -- even though Alan's comment was correct.  It is standard
> >>>>>> kernel practice to place cosmetic changes into their own patches,
> >>>>>> because it is standard kernel practice to break up logically distinct
> >>>>>> changes.
> >>>>>
> >>>>> We are talking about:
> >>>>>
> >>>>>     pata_via.c |   19 +++++++++++++------
> >>>>>     1 file changed, 13 insertions(+), 6 deletions(-)
> >>>>>
> >>>>> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
> >>>>> is clearly documented in the patch description.
> >>>>>
> >>>>>
> >>>>> Do people really wonder why I find upstream to be too much hassle to
> >>>>> deal with?
> >>>>
> >>>> The thousand other kernel developers seem to be able to split up their
> >>>> patches, separating out cosmetic changes from functional ones.  It has
> >>>> clear engineering benefits, and has been standard practice for a decade
> >>>> or more.
> >>>>
> >>>> Why is it such an imposition for your patches to look like everyone
> >>>> else's?  And by "everyone", I mean all other kernel developers, not just
> >>>> other ATA developers.
> >>>>
> >>>> You seem to consider standard kernel practice a hassle.  Separating out
> >>>> cosmetic changes is not only a libata practice, it is the norm for the
> >>>> entire kernel.
> >>>
> >>> Indeed.
> >>>
> >>>   From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
> >>> From: Jeff Garzik<jeff@garzik.org>
> >>> Date: Fri, 16 Jan 2009 10:17:09 -0500
> >>> Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
> >>>    for SAS drivers.
> >>>
> >>> Caught by Ke Wei (and team?) at Marvell.
> >>>
> >>> Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
> >>> general trend.
> >>>
> >>> Acked-by: James Bottomley<James.Bottomley@HansenPartnership.com>
> >>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
> >>
> >> If your point, by posting this patch, is that it includes a ton of
> >> gratuitous cosmetic changes, you misread the patch.
> >>
> >> ata_scsi_ioctl() remains in existence; only the callers need to use the
> >> new SAS-related ioctl function were updated.  The remainder continued to
> >> use ata_scsi_ioctl().
> >
> > Moving kernel exports around is completely unrelated to a bug fix.
> 
> Did the patch contain -cosmetic- changes intermingled with code changes, 
> in the same code lines?  No.

Took me a bit longer to find such one since you are not doing much
patches any longer. ;)

> Is it good kernel practice to intermingle cosmetic changes with 
> functional ones, in the same code lines?  Also, no.

I prefer using common sense over black-and-white rules.

If patch is a _really_ tiny one (< 20 LOC changed) it sometimes makes
sense to save the time on handling separate patches.

--
Bartlomiej Zolnierkiewicz


>From ee9ccdf70163ca6408f6965e0fbc65baeac7312c Mon Sep 17 00:00:00 2001
From: Jeff Garzik <jeff@garzik.org>
Date: Thu, 12 Jul 2007 15:51:22 -0400
Subject: [PATCH] [libata] sata_mv: Fix and clean up per-chip-generation tests

Due to a mistake in test logic, Gen-IIE chips were being treated as
Gen-II chips in some cases.  Fix this, and in the process, clean up
IS_50XX/IS_60XX tests to the more uniform IS_GEN_{I,II,IIE} tests.

Signed-off-by: Jeff Garzik <jeff@garzik.org>
---
 drivers/ata/sata_mv.c |   29 ++++++++++++++---------------
 1 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index d40c41c..8a77a0a 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -301,8 +301,9 @@ enum {
 	MV_HP_ERRATA_60X1B2	= (1 << 3),
 	MV_HP_ERRATA_60X1C0	= (1 << 4),
 	MV_HP_ERRATA_XX42A0	= (1 << 5),
-	MV_HP_50XX		= (1 << 6),
-	MV_HP_GEN_IIE		= (1 << 7),
+	MV_HP_GEN_I		= (1 << 6),
+	MV_HP_GEN_II		= (1 << 7),
+	MV_HP_GEN_IIE		= (1 << 8),
 
 	/* Port private flags (pp_flags) */
 	MV_PP_FLAG_EDMA_EN	= (1 << 0),
@@ -310,10 +311,8 @@ enum {
 	MV_PP_FLAG_HAD_A_RESET	= (1 << 2),
 };
 
-#define IS_50XX(hpriv) ((hpriv)->hp_flags & MV_HP_50XX)
-#define IS_60XX(hpriv) (((hpriv)->hp_flags & MV_HP_50XX) == 0)
-#define IS_GEN_I(hpriv) IS_50XX(hpriv)
-#define IS_GEN_II(hpriv) IS_60XX(hpriv)
+#define IS_GEN_I(hpriv) ((hpriv)->hp_flags & MV_HP_GEN_I)
+#define IS_GEN_II(hpriv) ((hpriv)->hp_flags & MV_HP_GEN_II)
 #define IS_GEN_IIE(hpriv) ((hpriv)->hp_flags & MV_HP_GEN_IIE)
 
 enum {
@@ -1406,7 +1405,7 @@ static void mv_err_intr(struct ata_port *ap, struct ata_queued_cmd *qc)
 			", dev disconnect" : ", dev connect");
 	}
 
-	if (IS_50XX(hpriv)) {
+	if (IS_GEN_I(hpriv)) {
 		eh_freeze_mask = EDMA_EH_FREEZE_5;
 
 		if (edma_err_cause & EDMA_ERR_SELF_DIS_5) {
@@ -2100,7 +2099,7 @@ static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem *mmio,
 
 	writelfl(ATA_RST, port_mmio + EDMA_CMD_OFS);
 
-	if (IS_60XX(hpriv)) {
+	if (IS_GEN_II(hpriv)) {
 		u32 ifctl = readl(port_mmio + SATA_INTERFACE_CTL);
 		ifctl |= (1 << 7);		/* enable gen2i speed */
 		ifctl = (ifctl & 0xfff) | 0x9b1000; /* from chip spec */
@@ -2116,7 +2115,7 @@ static void mv_channel_reset(struct mv_host_priv *hpriv, void __iomem *mmio,
 
 	hpriv->ops->phy_errata(hpriv, mmio, port_no);
 
-	if (IS_50XX(hpriv))
+	if (IS_GEN_I(hpriv))
 		mdelay(1);
 }
 
@@ -2163,7 +2162,7 @@ comreset_retry:
 	} while (time_before(jiffies, deadline));
 
 	/* work around errata */
-	if (IS_60XX(hpriv) &&
+	if (IS_GEN_II(hpriv) &&
 	    (sstatus != 0x0) && (sstatus != 0x113) && (sstatus != 0x123) &&
 	    (retry-- > 0))
 		goto comreset_retry;
@@ -2396,7 +2395,7 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)
 	switch(board_idx) {
 	case chip_5080:
 		hpriv->ops = &mv5xxx_ops;
-		hp_flags |= MV_HP_50XX;
+		hp_flags |= MV_HP_GEN_I;
 
 		switch (rev_id) {
 		case 0x1:
@@ -2416,7 +2415,7 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)
 	case chip_504x:
 	case chip_508x:
 		hpriv->ops = &mv5xxx_ops;
-		hp_flags |= MV_HP_50XX;
+		hp_flags |= MV_HP_GEN_I;
 
 		switch (rev_id) {
 		case 0x0:
@@ -2436,6 +2435,7 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)
 	case chip_604x:
 	case chip_608x:
 		hpriv->ops = &mv6xxx_ops;
+		hp_flags |= MV_HP_GEN_II;
 
 		switch (rev_id) {
 		case 0x7:
@@ -2455,7 +2455,6 @@ static int mv_chip_id(struct ata_host *host, unsigned int board_idx)
 	case chip_7042:
 	case chip_6042:
 		hpriv->ops = &mv6xxx_ops;
-
 		hp_flags |= MV_HP_GEN_IIE;
 
 		switch (rev_id) {
@@ -2522,7 +2521,7 @@ static int mv_init_host(struct ata_host *host, unsigned int board_idx)
 	hpriv->ops->enable_leds(hpriv, mmio);
 
 	for (port = 0; port < host->n_ports; port++) {
-		if (IS_60XX(hpriv)) {
+		if (IS_GEN_II(hpriv)) {
 			void __iomem *port_mmio = mv_port_base(mmio, port);
 
 			u32 ifctl = readl(port_mmio + SATA_INTERFACE_CTL);
@@ -2557,7 +2556,7 @@ static int mv_init_host(struct ata_host *host, unsigned int board_idx)
 	/* and unmask interrupt generation for host regs */
 	writelfl(PCI_UNMASK_ALL_IRQS, mmio + PCI_IRQ_MASK_OFS);
 
-	if (IS_50XX(hpriv))
+	if (IS_GEN_I(hpriv))
 		writelfl(~HC_MAIN_MASKED_IRQS_5, mmio + HC_MAIN_IRQ_MASK_OFS);
 	else
 		writelfl(~HC_MAIN_MASKED_IRQS, mmio + HC_MAIN_IRQ_MASK_OFS);
-- 
1.6.4.2

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 05:23 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 11:10:51 pm Jeff Garzik wrote:
>> Is it good kernel practice to intermingle cosmetic changes with
>> functional ones, in the same code lines?  Also, no.
>
> I prefer using common sense over black-and-white rules.
>
> If patch is a _really_ tiny one (<  20 LOC changed) it sometimes makes
> sense to save the time on handling separate patches.

This is open source -- you have to consider the time saved by reviewers too.

But I doubt you have saved time on all your motivated commit searches, so...

	Jeff

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Thursday 03 December 2009 11:30:50 pm Jeff Garzik wrote:
> On 12/03/2009 05:23 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 03 December 2009 11:10:51 pm Jeff Garzik wrote:
> >> Is it good kernel practice to intermingle cosmetic changes with
> >> functional ones, in the same code lines?  Also, no.
> >
> > I prefer using common sense over black-and-white rules.
> >
> > If patch is a _really_ tiny one (<  20 LOC changed) it sometimes makes
> > sense to save the time on handling separate patches.
> 
> This is open source -- you have to consider the time saved by reviewers too.

Like I said previously this is best done on per-case basis and because it is
open source eventually people will come up with an alternative patch if they
find the current one too bothersome to review, merge etc.

> But I doubt you have saved time on all your motivated commit searches, so...

Well, just two basic searches limited to one contributor and one directory..

--
Bartlomiej Zolnierkiewicz

Re: [PATCH 00/86] PATA fixes

[Jeff Garzik]

On 12/03/2009 04:16 PM, Jeff Garzik wrote:
>> pata_efar: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)

applied, after merging into a single "PIIX no MWDMA0" patch

>> pata_hpt3x2n: fix overclocked MWDMA0 timing
>
> skipped, pending discussion (just sent email)

applied

>> pata_it8213: MWDMA0 is unsupported
>
> skipped, pending discussion (just sent email)

applied

>> pata_oldpiix: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?

applied, after merging into a single "PIIX no MWDMA0" patch

>> pata_rdc: MWDMA0 is unsupported
>
> skipped -- Alan, Sergey, comments?

applied, after merging into a single "PIIX no MWDMA0" patch

Re: [PATCH 00/86] PATA fixes

[Alan Cox]

Likewise I'm happy with all of this stuff. My worry is the turn 32bit on
for hardware without real testing/docs checking except where it was on by
default bits.

The rest is good stuff. The 32bit stuff for the unproven cards could do
longer in -next as its only a performance boost for PIO.

Re: [PATCH 00/86] PATA fixes

[Alan Cox]

> >        pata_oldpiix: MWDMA0 is unsupported
> 
> skipped -- Alan, Sergey, comments?

Would need to look at the chip docs again. Certainly the ICH documents
the lack of MWDMA. Dunno about the original PIIX.

Rest looks sane, and that one probably is as the only way to to DMA0
appears to be with TIME0 clear. Unfortunately I can't lay my hands on a
PIIX errata sheet right now. The PIIX4 programming tables don't list
MWDMA0.

The original PIIX datasheet clarifies one other point too

For 32bit PIO it seems you must have bit 4 and 0 of IDETIM set for 32bit
data port access. That is you cannot use 32bit PIO when TIME0/TIME1 are
not set for that device.

MPIIX fixes that restriction (no DMA but does have 32bit PIO for all
modes) by inserting the needed mode 0 two clocks of CS deselect even if
not visible on the ISA bus. The restriction is also not mentioned on
PIIX4+ so presumably is specific to the original chip.

Re: [PATCH 84/86] libata: add ata_mwdma_to_pio() inline helper

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] libata: add ata_mwdma_to_pio() inline helper

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

[...]

>  static struct ata_port_operations rdc_pata_ops = {
> Index: b/include/linux/ata.h
> ===================================================================
> --- a/include/linux/ata.h
> +++ b/include/linux/ata.h
> @@ -1012,4 +1012,15 @@ static inline int lba_48_ok(u64 block, u
>  #define sata_pmp_gscr_rev(gscr)		(((gscr)[SATA_PMP_GSCR_REV] >> 8) & 0xff)
>  #define sata_pmp_gscr_ports(gscr)	((gscr)[SATA_PMP_GSCR_PORT_INFO] & 0xf)
>  
> +/* returns PIO number matching given MWDMA mode */
> +static inline u8 ata_mwdma_to_pio(u8 mwdma_mode)
> +{
> +	unsigned int mwdma = mwdma_mode - XFER_MW_DMA_0;
> +	const unsigned int needed_pio[3] = {

    'u8' would have been enough.

> +		XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
> +	};

    Er, perhaps this should be 'static' array?.. Intialization *auto* class 
arrays produces some real code... Also, why not simply {0, 3, 4}?

> +
> +	return needed_pio[mwdma] - XFER_PIO_0;
> +}
> +
>  #endif /* __LINUX_ATA_H__ */

MBR, Sergei

Re: [PATCH 00/86] PATA fixes

[david]

On Thu, 3 Dec 2009, Bartlomiej Zolnierkiewicz wrote:

> On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
>> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
>>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
>>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
>>>>>>>> The merge window is upon us, which by strict rules means that anything
>>>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
>>>>>>>>
>>>>>>>> However, bug fixes and the like should definitely be in 2.6.33.
>>>>>>>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
>>>>>>>> could go either way.
>>>>>>
>>>>>>> If you would like to apply some of my patches to 2.6.33 you are more than
>>>>>>> welcome to do it.  I can even prepare separate git tree with specific changes
>>>>>>> to make it easier for you once you tell me which changes you would like to
>>>>>>> see in it.
>>>>>>
>>>>>> OK, great.
>>>>>>
>>>>>> Can you prepare a patchset containing only fixes?  Comment-only changes
>>>>>> are acceptable too.  Trivial changes too, if they are extremely trivial :)
>>>>>>
>>>>>> Include nothing that adds features, removes or unifies drivers, etc.
>>>>>
>>>>> Since this is pretty high-level description and some changes fall into
>>>>> many categories at once (i.e. addition of proper PCI Power Management
>>>>> handling could be considered both as a fix and as a feature) I prepared
>>>>> a rather conservative set of changes (which means that unfortunately
>>>>> it misses many enhancements available in my tree):
>>>>>
>>>>>> Please do it in standard kernel submit form, which is either
>>>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
>>>>>> (b) a standard git pull request, which includes shortlog, diffstat, and
>>>>>> all-in-one diff.
>>>>>
>>>>> Thank you for the detailed explanation of the standard kernel submit
>>>>> form (I wonder how would I know this otherwise :) but the thing is that
>>>>> at the current moment I'm not submitting anything to the upstream.
>>>>
>>>> Ok, that explains my confusion, then.  I had thought you intended to get
>>>> this stuff upstream, and into users' hands.
>>>
>>> Interesting argument but the vast majority of users use distribution kernels
>>> which are not upstream and I doubt that any self-respecting distribution would
>>> miss such amount of fixes.
>>
>> Interesting argument, but applied across 1000+ developers this is
>> clearly an unscalable development model for distributions.  Thus,
>
> Interesting that you have brought distributions' convenience before
> non-distribution developers' one.

and you are leaving those of us who use kernel.org out in the cold 
(forcing all non-distribution users to go through all the work that Jeff 
described)

I'm not sure who you see as benifiting from this approach.

David Lang

Re: [PATCH 00/86] PATA fixes

[Bartlomiej Zolnierkiewicz]

On Saturday 12 December 2009 03:02:43 am david@lang.hm wrote:
> On Thu, 3 Dec 2009, Bartlomiej Zolnierkiewicz wrote:
> 
> > On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
> >> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
> >>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
> >>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
> >>>>>>>> The merge window is upon us, which by strict rules means that anything
> >>>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34.
> >>>>>>>>
> >>>>>>>> However, bug fixes and the like should definitely be in 2.6.33.
> >>>>>>>> ->init_host is definitely 2.6.34 material.  Some of the other stuff
> >>>>>>>> could go either way.
> >>>>>>
> >>>>>>> If you would like to apply some of my patches to 2.6.33 you are more than
> >>>>>>> welcome to do it.  I can even prepare separate git tree with specific changes
> >>>>>>> to make it easier for you once you tell me which changes you would like to
> >>>>>>> see in it.
> >>>>>>
> >>>>>> OK, great.
> >>>>>>
> >>>>>> Can you prepare a patchset containing only fixes?  Comment-only changes
> >>>>>> are acceptable too.  Trivial changes too, if they are extremely trivial :)
> >>>>>>
> >>>>>> Include nothing that adds features, removes or unifies drivers, etc.
> >>>>>
> >>>>> Since this is pretty high-level description and some changes fall into
> >>>>> many categories at once (i.e. addition of proper PCI Power Management
> >>>>> handling could be considered both as a fix and as a feature) I prepared
> >>>>> a rather conservative set of changes (which means that unfortunately
> >>>>> it misses many enhancements available in my tree):
> >>>>>
> >>>>>> Please do it in standard kernel submit form, which is either
> >>>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or
> >>>>>> (b) a standard git pull request, which includes shortlog, diffstat, and
> >>>>>> all-in-one diff.
> >>>>>
> >>>>> Thank you for the detailed explanation of the standard kernel submit
> >>>>> form (I wonder how would I know this otherwise :) but the thing is that
> >>>>> at the current moment I'm not submitting anything to the upstream.
> >>>>
> >>>> Ok, that explains my confusion, then.  I had thought you intended to get
> >>>> this stuff upstream, and into users' hands.
> >>>
> >>> Interesting argument but the vast majority of users use distribution kernels
> >>> which are not upstream and I doubt that any self-respecting distribution would
> >>> miss such amount of fixes.
> >>
> >> Interesting argument, but applied across 1000+ developers this is
> >> clearly an unscalable development model for distributions.  Thus,
> >
> > Interesting that you have brought distributions' convenience before
> > non-distribution developers' one.
> 
> and you are leaving those of us who use kernel.org out in the cold 
> (forcing all non-distribution users to go through all the work that Jeff 
> described)

[ ..and you believed it? ;) ]

> I'm not sure who you see as benifiting from this approach.

I'm not the maintainer of the affected code (according to MAINTAINERS
at least PATA code is unmaintained and to add more confusion it has been
in such state forever despite numerous claims of said code being the
'official' one ) so I think that you are barking at the wrong tree here..

Moreover the claim of forcing people to do the work was completely
ridiculous (BTW all the changes happen in my own time) since I did/do
a lot to make review/merge easier for people:

- My tree is based on top of libata tree and stays up-to-date with it.

- All changes have been posted to linux-ide and linux-kernel, and they
  had review concerns addressed already (there was only one real issue,
  Alan has noticed that scc_pata change is unnecessary).

- I'm OK with providing additional branches with only selected changes
  to ease the merging process.

--
Bartlomiej Zolnierkiewicz