linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller.
       [not found] ` <20070807204157.GA23028@kroah.com>
@ 2007-08-07 20:42   ` Greg KH
  2007-08-07 23:39     ` Chr
  2007-08-07 20:48   ` [2.6.22.2 review 67/84] libata: add FUJITSU MHV2080BH to NCQ blacklist Greg KH
  1 sibling, 1 reply; 4+ messages in thread
From: Greg KH @ 2007-08-07 20:42 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
	Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
	Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan, linux-ide,
	Jeff Garzik, Christian Lamparter

[-- Attachment #1: add-a-pci-id-for-santa-rosa-s-pata-controller.patch --]
[-- Type: text/plain, Size: 963 bytes --]


From: Christian Lamparter <chunkeey@web.de>

This is commit c1e6f28cc5de37dcd113b9668a185c0b9334ba8a which is
merged during 23-rc1 window.  Considering the popularity of these
chips, I think including it in -stable release would be good idea.

Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ata/ata_piix.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -200,6 +200,8 @@ static const struct pci_device_id piix_p
 	/* ICH7/7-R (i945, i975) UDMA 100*/
 	{ 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
 	{ 0x8086, 0x269E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
+	/* ICH8 Mobile PATA Controller */
+	{ 0x8086, 0x2850, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 
 	/* NOTE: The following PCI ids must be kept in sync with the
 	 * list in drivers/pci/quirks.c.

-- 

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

* [2.6.22.2 review 67/84] libata: add FUJITSU MHV2080BH to NCQ blacklist
       [not found] ` <20070807204157.GA23028@kroah.com>
  2007-08-07 20:42   ` [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller Greg KH
@ 2007-08-07 20:48   ` Greg KH
  1 sibling, 0 replies; 4+ messages in thread
From: Greg KH @ 2007-08-07 20:48 UTC (permalink / raw)
  To: linux-kernel, stable, Jeff Garzik, linux-ide, Serge van Thillo
  Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
	Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
	Chuck Ebbert, Domenico Andreoli, torvalds, akpm, alan, Tejun Heo

[-- Attachment #1: libata-add-fujitsu-mhv2080bh-to-ncq-blacklist.patch --]
[-- Type: text/plain, Size: 901 bytes --]

From: Tejun Heo <htejun@gmail.com>

Please warmly welcome the first member from FUJITSU to the prestigious
NCQ spurious completion club.

This is reported by Serge Van Thillo in bugzilla bug 8730.

  http://bugzilla.kernel.org/show_bug.cgi?id=8730

Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Serge van Thillo <nulleke@hotmail.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ata/libata-core.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3800,6 +3800,7 @@ static const struct ata_blacklist_entry 
 	{ "HTS541612J9SA00",	"SBDIC7JP",	ATA_HORKAGE_NONCQ, },
 	{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
 	{ "WDC WD740ADFD-00NLR1", NULL,		ATA_HORKAGE_NONCQ, },
+	{ "FUJITSU MHV2080BH",	"00840028",	ATA_HORKAGE_NONCQ, },
 
 	/* Devices with NCQ limits */
 

-- 

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

* Re: [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller.
  2007-08-07 20:42   ` [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller Greg KH
@ 2007-08-07 23:39     ` Chr
  2007-08-09 19:39       ` Andrew Morton
  0 siblings, 1 reply; 4+ messages in thread
From: Chr @ 2007-08-07 23:39 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
	Theodore Ts'o, Randy Dunlap, Dave Jones, Chuck Wolber,
	Chris Wedgwood, Michael Krufky, Chuck Ebbert, Domenico Andreoli,
	torvalds, akpm, alan, linux-ide, Jeff Garzik, Gaston, Jason D,
	chunkeey

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

On Tuesday, 7. August 2007, Greg KH wrote:
> 
> From: Christian Lamparter <chunkeey@web.de>
> 
> This is commit c1e6f28cc5de37dcd113b9668a185c0b9334ba8a which is
> merged during 23-rc1 window.  Considering the popularity of these
> chips, I think including it in -stable release would be good idea.
> 
> Signed-off-by: Christian Lamparter <chunkeey@web.de>
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 

I did not receive any complains. I guess it's stable enough for -stable ;-) ...

--- 

Not OT: 

There is another outstanding issue with ata_piix.c.
Intel has never officially supported anything faster than PATA 100MB/s.

But, the ata_piix.c driver "define" the ICH5 & ICH7 as UDMA6 (aka 133MB/s) capable.
[ Well, no one has probably noticed it before, because there is bug in do_pata_set_dmamode... 
Just look at libata_atapiix_enable_real_udma133.patch and you'll see what wrong with it. ] 

Here are Intel's datasheets for the affected chipsets:
ICH5 Datasheet: http://www.intel.com/design/chipsets/datashts/252516.htm
(See note on page 183: "... the ICH5 supports reads at the maximum rate of 100MB/s.")

ICH7 Datasheet: http://www.intel.com/design/chipsets/datashts/307013.htm
(See first note on page 190: "... the ICH7 supports reads at the maximum rate of 100MB/s.")

-

They are two different ways to deal with it:

- Either -

1. replace all ich_pata_133 with ich_pata_100. 
   (libata_atapiix_disable_udma6.diff - diff from 2.6.22 )

- Or -

2. keep all ich_pata_133 and fix the bug in "do_pata_set_dmamode".
   (libata_atapiix_enable_real_udma133.patch - diff from 2.6.22) 
   If there are any concerns about the safety of the patch patch: 
   http://lkml.org/lkml/2007/7/6/292 (It was already tested by an Intel employee,
   but I guess a bit more user input is necessary here... )

Both ways have their pros and cons. Unfortunately, I don't have the time to follow this
discussion right now, so here's a: 

Signed-off-by: Christian Lamparter <chunkeey@web.de>
(Just in case, if one of the patches really gets merged!)

Thanks,
	Chr. 


[-- Attachment #2: libata_atapiix_disable_udma6.diff --]
[-- Type: text/x-diff, Size: 1651 bytes --]

--- a/drivers/ata/ata_piix.c	2007-08-08 00:52:52.000000000 +0200
+++ b/drivers/ata/ata_piix.c	2007-08-08 00:55:45.000000000 +0200
@@ -122,7 +122,7 @@ enum {
 	ich_pata_33		= 1,	/* ICH up to UDMA 33 only */
 	ich_pata_66		= 2,	/* ICH up to 66 Mhz */
 	ich_pata_100		= 3,	/* ICH up to UDMA 100 */
-	ich_pata_133		= 4,	/* ICH up to UDMA 133 */
+	/* ICH up to UDMA 133 is not supported */
 	ich5_sata		= 5,
 	ich6_sata		= 6,
 	ich6_sata_ahci		= 7,
@@ -190,7 +190,7 @@ static const struct pci_device_id piix_p
 	{ 0x8086, 0x24CA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	{ 0x8086, 0x24CB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* Intel ICH5 */
-	{ 0x8086, 0x24DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
+	{ 0x8086, 0x24DB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* C-ICH (i810E2) */
 	{ 0x8086, 0x245B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* ESB (855GME/875P + 6300ESB) UDMA 100  */
@@ -198,7 +198,7 @@ static const struct pci_device_id piix_p
 	/* ICH6 (and 6) (i915) UDMA 100 */
 	{ 0x8086, 0x266F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	/* ICH7/7-R (i945, i975) UDMA 100*/
-	{ 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
+	{ 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 	{ 0x8086, 0x269E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
 
 	/* NOTE: The following PCI ids must be kept in sync with the
@@ -479,7 +479,7 @@ static struct ata_port_info piix_port_in
 		.port_ops	= &ich_pata_ops,
 	},
 
-	/* ich_pata_133: 4 	ICH with full UDMA6 */
+	/* ich_pata_133: 4 - Not supported - */
 	{
 		.sht		= &piix_sht,
 		.flags		= PIIX_PATA_FLAGS | PIIX_FLAG_CHECKINTR,

[-- Attachment #3: libata_atapiix_enable_real_udma133.patch --]
[-- Type: text/x-diff, Size: 442 bytes --]

--- a/drivers/ata/ata_piix.c	2007-08-08 00:52:52.000000000 +0200
+++ b/drivers/ata/ata_piix.c	2007-08-08 00:53:03.000000000 +0200
@@ -765,8 +765,8 @@ static void do_pata_set_dmamode (struct 
 		 *	       except UDMA0 which is 00
 		 */
 		u_speed = min(2 - (udma & 1), udma);
-		if (udma == 5)
-			u_clock = 0x1000;	/* 100Mhz */
+		if (udma >= 5)
+			u_clock = 0x1000;	/* 133Mhz */
 		else if (udma > 2)
 			u_clock = 1;		/* 66Mhz */
 		else

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

* Re: [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller.
  2007-08-07 23:39     ` Chr
@ 2007-08-09 19:39       ` Andrew Morton
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Morton @ 2007-08-09 19:39 UTC (permalink / raw)
  To: Chr
  Cc: Greg KH, linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
	Theodore Ts'o, Randy Dunlap, Dave Jones, Chuck Wolber,
	Chris Wedgwood, Michael Krufky, Chuck Ebbert, Domenico Andreoli,
	torvalds, alan, linux-ide, Jeff Garzik, Gaston, Jason D

On Wed, 8 Aug 2007 01:39:12 +0200
Chr <chunkeey@web.de> wrote:

> On Tuesday, 7. August 2007, Greg KH wrote:
> > 
> > From: Christian Lamparter <chunkeey@web.de>
> > 
> > This is commit c1e6f28cc5de37dcd113b9668a185c0b9334ba8a which is
> > merged during 23-rc1 window.  Considering the popularity of these
> > chips, I think including it in -stable release would be good idea.
> > 
> > Signed-off-by: Christian Lamparter <chunkeey@web.de>
> > Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> 
> I did not receive any complains. I guess it's stable enough for -stable ;-) ...
> 
> --- 
> 
> Not OT: 
> 
> There is another outstanding issue with ata_piix.c.
> Intel has never officially supported anything faster than PATA 100MB/s.
> 
> But, the ata_piix.c driver "define" the ICH5 & ICH7 as UDMA6 (aka 133MB/s) capable.
> [ Well, no one has probably noticed it before, because there is bug in do_pata_set_dmamode... 
> Just look at libata_atapiix_enable_real_udma133.patch and you'll see what wrong with it. ] 
> 
> Here are Intel's datasheets for the affected chipsets:
> ICH5 Datasheet: http://www.intel.com/design/chipsets/datashts/252516.htm
> (See note on page 183: "... the ICH5 supports reads at the maximum rate of 100MB/s.")
> 
> ICH7 Datasheet: http://www.intel.com/design/chipsets/datashts/307013.htm
> (See first note on page 190: "... the ICH7 supports reads at the maximum rate of 100MB/s.")
> 
> -
> 
> They are two different ways to deal with it:
> 
> - Either -
> 
> 1. replace all ich_pata_133 with ich_pata_100. 
>    (libata_atapiix_disable_udma6.diff - diff from 2.6.22 )
> 
> - Or -
> 
> 2. keep all ich_pata_133 and fix the bug in "do_pata_set_dmamode".
>    (libata_atapiix_enable_real_udma133.patch - diff from 2.6.22) 
>    If there are any concerns about the safety of the patch patch: 
>    http://lkml.org/lkml/2007/7/6/292 (It was already tested by an Intel employee,
>    but I guess a bit more user input is necessary here... )
> 
> Both ways have their pros and cons. Unfortunately, I don't have the time to follow this
> discussion right now, so here's a: 
> 
> Signed-off-by: Christian Lamparter <chunkeey@web.de>
> (Just in case, if one of the patches really gets merged!)
> 

You kinda hid these patches rather well.

I chose option 1. 




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

end of thread, other threads:[~2007-08-09 19:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20070807204034.882009319@mini.kroah.org>
     [not found] ` <20070807204157.GA23028@kroah.com>
2007-08-07 20:42   ` [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller Greg KH
2007-08-07 23:39     ` Chr
2007-08-09 19:39       ` Andrew Morton
2007-08-07 20:48   ` [2.6.22.2 review 67/84] libata: add FUJITSU MHV2080BH to NCQ blacklist Greg KH

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