Re: SATA open bugs

[Matt Sealey]

Tejun Heo wrote:

Hello, Natalie.


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


This one is chrp specific.  The native mode fix didn't work.  I'll
follow up later.


Following up in private with original porter now.

I really think this is a combination of a chip bug and firmware
configuration being futzed. We might have to leave IRQ steering
at 14/15 even in PCI mode, because the ISA bridge isn't so smart
as the docs imply it is.

--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Alan Cox]

> > http://bugzilla.kernel.org/show_bug.cgi?id=8424 - patch review
> This one is on Alan.

I think not - something horrible is happening in dma_alloc_coherent when
called from dmam_* with a non PCI device


Seems to be some kind of AMD64 specific DMA mapping bug ?
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Disk spin down issue on shut down/suspend to disk

[Pavel Machek]

Hi!

> >> Oh... crap, so acpi wants to sync cache on shutdown.  I wonder whether
> >> it spins down the disk correctly.  Does emergency unload count increase
> >> after each power down?  Also, please post the result of 'dmidecode'.
> > 
> > I know that my Compaq X1000-series laptop does do some kind of ACPI
> > games with the disk on ACPI power off (I assume it is putting the disk
> > in standby before power-off at least). It also does this if you boot
> > into DOS, GRUB, etc. and then hit the power button. Could be if the disk
> > is dumb enough to spin up for sync cache and standby when there is
> > nothing to flush, and the kernel does its own standby, this could cause
> > an extra spinup/down..
> 
> Yeah, that seems to be what's going on.  I don't think we have any other
> choice than blacklisting those notebooks.  This is a mess.  How does the
> other OS cope with this?
> 
> I'm thinking about using DMI vendor/product match to detect the affected
> systems but I think it would be better to match the ACPI implementation
> directly.  Is there a way to match specific ACPI implementation?

Well.. unless they use some SMM trick, it is ACPI AML code telling
kernel to spin the disk down. I guess we could detect that, and simply
ignore the request.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Disk spin down issue on shut down/suspend to disk

[Pavel Machek]

Hi!

> > firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list)
> > see: http://linuxfirmwarekit.org/
> > 
> > But if I understand this problem right, this won't be easy.
> > The ACPI tables are just parsed with system ("iasl ...") and syntactical
> > errors/warnings are printed out.
> > I also thought about a test, interpreting the DSDT and read out values
> > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> > not designed for that atm. You need to compile in most parts of the
> > acpica code and parse and interpret DSDT/SSDT code yourself in the
> > firmwarekit core or inside a plugin, then do a walk_namespace call or
> > whatever to find the functions/parts you like to examine. This is a lot
> > work and needs a proper design (providing an interface to plugins to let
> > them easily check specific AML/ASL code).
> 
> Furthermore, we don't really know what we're looking for.  How can you
> tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
> trying to power the machine off?  Adding to the fun, many modern ATA
> controller have more than one way to issue a command.  Maybe we can
> match accesses inside regions specified by PCI BARs  :-(

Hmmm... perhaps we should do it the other way. ACPI is allowed to
touch the embedded controller, what else? Maybe we should warn as soon
as API touches non-EC I/O port?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Disk spin down issue on shut down/suspend to disk

[Thomas Renninger]

On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote:
> Hi!
> 
> > > firmwarekit-discuss <[EMAIL PROTECTED]> (added to CC list)
> > > see: http://linuxfirmwarekit.org/
> > > 
> > > But if I understand this problem right, this won't be easy.
> > > The ACPI tables are just parsed with system ("iasl ...") and syntactical
> > > errors/warnings are printed out.
> > > I also thought about a test, interpreting the DSDT and read out values
> > > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> > > not designed for that atm. You need to compile in most parts of the
> > > acpica code and parse and interpret DSDT/SSDT code yourself in the
> > > firmwarekit core or inside a plugin, then do a walk_namespace call or
> > > whatever to find the functions/parts you like to examine. This is a lot
> > > work and needs a proper design (providing an interface to plugins to let
> > > them easily check specific AML/ASL code).
> > 
> > Furthermore, we don't really know what we're looking for.  How can you
> > tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
> > trying to power the machine off?  Adding to the fun, many modern ATA
> > controller have more than one way to issue a command.  Maybe we can
> > match accesses inside regions specified by PCI BARs  :-(
> 
> Hmmm... perhaps we should do it the other way. ACPI is allowed to
> touch the embedded controller, what else? Maybe we should warn as soon
> as API touches non-EC I/O port?

This is not working...
ACPI can and does access all kind of other I/O ports and other
resources.
Hmm, are the disk accesses done by ACPI via OperationRegion/Field
declared variables?
I try to get a check for those clashing with native drivers (hopefully
this approach is successful for 2.6.24, can't say for sure yet), I
wonder whether this one would give a warning like "Libata driver is
using the same SystemIO/SystemMem resources than ACPI OperationRegion
declaration XY".
This would not solve the problem, but at least show the need of such a
test. Such ACPI vs native driver interference problems are very hard
nuts (in identifying and solving).

Can someone post an ASL code snippet how ACPI actually access the disk
and in which parts/functions, pls.

Thanks,

   Thomas

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pata error messages?

[Kumar Gala]

I'm trying to figure out what could cause the following error  
messages.  This is on a PPC host using a ULI 1575 southbridge:


- k

ata5: PATA max UDMA/133 cmd 0xfdfee300 ctl 0xfdfee30a bmdma  
0xfdfee320 irq 6
ata6: PATA max UDMA/133 cmd 0xfdfee310 ctl 0xfdfee31a bmdma  
0xfdfee328 irq 6

ata5.00: ATAPI: SONYDVD RW AW-Q170A, 1.72, max UDMA/66
ata5.00: configured for UDMA/66
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/66
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/66
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/66
ata5: EH complete
ata5.00: limiting speed to UDMA/44:PIO4
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/44
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/44
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/44
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/44
ata5: EH complete
ata5.00: limiting speed to UDMA/33:PIO4
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata5: soft resetting port
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata5.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x12 data  
36 in

 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata

Re: [patch 2/4] Expose Power Management Policy option to users

[Kristen Carlson Accardi]

On Wed, 1 Aug 2007 14:16:51 -0700
Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:

> I was able to duplicate Tejun's problem on an ATAPI device I had here.
> this updated patch fixed my problem.  These devices are just setting 
> PhyReady (N) and CommWake (W) in Serror on power state changes, ignoring
> them seems to be fine, and fixed the problem for me.

Hi Tejun,
Were you able to test out this patch and see if it solved your ATAPI
device/ALPM issues?

Thanks,
Kristen


> 
> 
> Enable Aggressive Link Power management for AHCI controllers.
> 
> This patch will set the correct bits to turn on Aggressive
> Link Power Management (ALPM) for the ahci driver.  This
> will cause the controller and disk to negotiate a lower
> power state for the link when there is no activity (see
> the AHCI 1.x spec for details).  This feature is mutually
> exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
> is disabled.  ALPM will be enabled by default, but it is
> settable via the scsi host syfs interface.  Possible 
> settings for this feature are:
> 
> Setting   Effect
> --
> min_power ALPM is enabled, and link set to enter 
>   lowest power state (SLUMBER) when idle
>   Hot plug not allowed.
> 
> max_performance   ALPM is disabled, Hot Plug is allowed
> 
> medium_power  ALPM is enabled, and link set to enter
>   second lowest power state (PARTIAL) when
>   idle.  Hot plug not allowed.
> 
> Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>
> 
> Index: 2.6-git/drivers/ata/ahci.c
> ===
> --- 2.6-git.orig/drivers/ata/ahci.c
> +++ 2.6-git/drivers/ata/ahci.c
> @@ -48,6 +48,9 @@
>  #define DRV_NAME "ahci"
>  #define DRV_VERSION  "2.3"
>  
> +static int ahci_enable_alpm(struct ata_port *ap,
> + enum link_pm policy);
> +static int ahci_disable_alpm(struct ata_port *ap);
>  
>  enum {
>   AHCI_PCI_BAR= 5,
> @@ -98,6 +101,7 @@ enum {
>   /* HOST_CAP bits */
>   HOST_CAP_SSC= (1 << 14), /* Slumber capable */
>   HOST_CAP_CLO= (1 << 24), /* Command List Override support */
> + HOST_CAP_ALPM   = (1 << 26), /* Aggressive Link PM support */
>   HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */
>   HOST_CAP_SNTF   = (1 << 29), /* SNotification register */
>   HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */
> @@ -153,6 +157,8 @@ enum {
> PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
>  
>   /* PORT_CMD bits */
> + PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */
> + PORT_CMD_ALPE   = (1 << 26), /* Aggressive Link PM enable */
>   PORT_CMD_ATAPI  = (1 << 24), /* Device is ATAPI */
>   PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */
>   PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */
> @@ -244,6 +250,11 @@ static int ahci_pci_device_suspend(struc
>  static int ahci_pci_device_resume(struct pci_dev *pdev);
>  #endif
>  
> +static struct class_device_attribute *ahci_shost_attrs[] = {
> + &class_device_attr_link_power_management_policy,
> + NULL
> +};
> +
>  static struct scsi_host_template ahci_sht = {
>   .module = THIS_MODULE,
>   .name   = DRV_NAME,
> @@ -261,6 +272,7 @@ static struct scsi_host_template ahci_sh
>   .slave_configure= ata_scsi_slave_config,
>   .slave_destroy  = ata_scsi_slave_destroy,
>   .bios_param = ata_std_bios_param,
> + .shost_attrs= ahci_shost_attrs,
>  };
>  
>  static const struct ata_port_operations ahci_ops = {
> @@ -292,6 +304,8 @@ static const struct ata_port_operations 
>   .port_suspend   = ahci_port_suspend,
>   .port_resume= ahci_port_resume,
>  #endif
> + .enable_pm  = ahci_enable_alpm,
> + .disable_pm = ahci_disable_alpm,
>  
>   .port_start = ahci_port_start,
>   .port_stop  = ahci_port_stop,
> @@ -778,6 +792,156 @@ static void ahci_power_up(struct ata_por
>   writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
>  }
>  
> +static int ahci_disable_alpm(struct ata_port *ap)
> +{
> + void __iomem *port_mmio = ahci_port_base(ap);
> + u32 cmd, scontrol;
> + struct ahci_port_priv *pp = ap->private_data;
> +
> + /*
> +  * disable Interface Power Management State Transitions
> +  * This is accomplished by setting bits 8:11 of the
> +  * SATA Control register
> +  */
> + scontrol = readl(port_mmio + PORT_SCR_CTL);
> + scontrol |= (0x3 << 8);
> + writel(scontrol, port_mmio + PORT_SCR_CTL);
> +
> + /* get the existing command bits */
> + cmd = readl(port_mmio + PORT_CMD);
> +
> + /* disable ALPM and A

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Andi Kleen]

On Thu, Aug 09, 2007 at 02:53:36PM +0100, Alan Cox wrote:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=8424 - patch review
> > This one is on Alan.
> 
> I think not - something horrible is happening in dma_alloc_coherent when
> called from dmam_* with a non PCI device
> 
> 
> Seems to be some kind of AMD64 specific DMA mapping bug ?

I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA
able device to dma_alloc_coherent(). Which seems like a caller bug.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pata error messages?

[Alan Cox]

On Thu, 9 Aug 2007 10:59:12 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:

> I'm trying to figure out what could cause the following error  
> messages.  This is on a PPC host using a ULI 1575 southbridge:

I'm still chasing problems with ATAPI DMA on some ALi host bridges. I'd
like to say I knew what was going on but the truth is I'm currently
diffing lspci out and staring at spec sheets with little result.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Alan Cox]

> > Seems to be some kind of AMD64 specific DMA mapping bug ?
> 
> I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA
> able device to dma_alloc_coherent(). Which seems like a caller bug.

Ok - other archs seem to just return NULL in this case. If its your view
that dma_alloc_coherent(dev) should explode not return NULL then we can
wrap dma_alloc_coherent but I'm not sure the caller library has any
business knowing whether a specific class of device is DMA capable on a
specific platform ?

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pata error messages?

[Kumar Gala]

On Aug 9, 2007, at 12:17 PM, Alan Cox wrote:


On Thu, 9 Aug 2007 10:59:12 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:


I'm trying to figure out what could cause the following error
messages.  This is on a PPC host using a ULI 1575 southbridge:


I'm still chasing problems with ATAPI DMA on some ALi host bridges.  
I'd

like to say I knew what was going on but the truth is I'm currently
diffing lspci out and staring at spec sheets with little result.


yeah, the ALi spec I have for 1575 is terse at best.

I'd be interested in possible register dumps, I'm not sure if we are  
even setting up the controllers properly or not.


- k
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Andi Kleen]

On Thu, Aug 09, 2007 at 06:21:01PM +0100, Alan Cox wrote:
> > > Seems to be some kind of AMD64 specific DMA mapping bug ?
> > 
> > I think it's dev->dma_mask == NULL. Clearly you're passing a non DMA
> > able device to dma_alloc_coherent(). Which seems like a caller bug.
> 
> Ok - other archs seem to just return NULL in this case. If its your view

Ok then the initialization would fail.

I could do that, but clearly there must be some other bug
in the process that tries to do DMA on such random devices
in the first place.

> that dma_alloc_coherent(dev) should explode not return NULL then we can
> wrap dma_alloc_coherent but I'm not sure the caller library has any
> business knowing whether a specific class of device is DMA capable on a
> specific platform ?

Someone must ask that caller library to DMA to/from that device
in the first place. Whoever it is it is wrong. 

Or perhaps you got the wrong device here? For ISA devices we 
traditionally used NULL. Or if you set up your own ISA devices
(which I can't see a reason for but there might be one I'm missing) 
at least give them a dma mask. Then it should probably work on x86-64.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Alan Cox]

> Someone must ask that caller library to DMA to/from that device
> in the first place. Whoever it is it is wrong. 

No I disagree.

> Or perhaps you got the wrong device here? For ISA devices we 
> traditionally used NULL. Or if you set up your own ISA devices
> (which I can't see a reason for but there might be one I'm missing) 
> at least give them a dma mask. Then it should probably work on x86-64.

The libata code currently (and this seems to work for all but x86-64)
does the following if it is setting up a potentially DMA capable device

- Allocate a dma_coherent buffer
- If it is refused then turn off DMA and use PIO

It has no idea whether a pcmcia, isa, platform or even PCI device happens
to be DMA capable, and there are platforms with PCI but very limited DMA
for example in the embedded space. In fact it has no idea this level
whether it is working a PCI, ISA, PCMCIA, SBUS or some other bus device.
It's supposed to be generic code.

Obviously doing anything other than dma_alloc_coherent if the allocation
fails is stupid but trying to allocate dma memory to find out if the
device can be used with DMA on a given platform is quite logical and
sensible in some cases.

Thus I think dma_alloc_coherent() for an ISA, PCMCIA or other class
(platform particularly) shouldn't explode on AMD64 but simply return
NULL. Its a sane request to make when you don't in your library know what
dev is.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Disk spin down issue on shut down/suspend to disk

[Rafael J. Wysocki]

On Thursday, 9 August 2007 17:06, Pavel Machek wrote:
> Hi!
> 
> > >> Oh... crap, so acpi wants to sync cache on shutdown.  I wonder whether
> > >> it spins down the disk correctly.  Does emergency unload count increase
> > >> after each power down?  Also, please post the result of 'dmidecode'.
> > > 
> > > I know that my Compaq X1000-series laptop does do some kind of ACPI
> > > games with the disk on ACPI power off (I assume it is putting the disk
> > > in standby before power-off at least). It also does this if you boot
> > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk
> > > is dumb enough to spin up for sync cache and standby when there is
> > > nothing to flush, and the kernel does its own standby, this could cause
> > > an extra spinup/down..
> > 
> > Yeah, that seems to be what's going on.  I don't think we have any other
> > choice than blacklisting those notebooks.  This is a mess.  How does the
> > other OS cope with this?
> > 
> > I'm thinking about using DMI vendor/product match to detect the affected
> > systems but I think it would be better to match the ACPI implementation
> > directly.  Is there a way to match specific ACPI implementation?
> 
> Well.. unless they use some SMM trick, it is ACPI AML code telling
> kernel to spin the disk down. I guess we could detect that, and simply
> ignore the request.

Please see: http://lkml.org/lkml/2007/8/8/187

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Andi Kleen]

On Thu, Aug 09, 2007 at 06:53:10PM +0100, Alan Cox wrote:
> > Or perhaps you got the wrong device here? For ISA devices we 
> > traditionally used NULL. Or if you set up your own ISA devices
> > (which I can't see a reason for but there might be one I'm missing) 
> > at least give them a dma mask. Then it should probably work on x86-64.
> 
> The libata code currently (and this seems to work for all but x86-64)
> does the following if it is setting up a potentially DMA capable device

Where does the device come from? What device is it?
Is that known already?

> Thus I think dma_alloc_coherent() for an ISA, PCMCIA or other class
> (platform particularly) shouldn't explode on AMD64 but simply return
> NULL. Its a sane request to make when you don't in your library know what
> dev is.

But at least on x86-64 the device is likely DMA capable. At least
PCMCIA usually is.  Near all devices are DMA capable, except perhaps
SMBus and some real oddballs. So the device should not have a NULL dma_mask
in the first place. Or it is the wrong device. e.g. we have platform
devices for things like timers etc. which are really not DMA capable
because it doesn't make much sense to DMA your timer; but there
should be really no reason to use such a device in a libata driver. 

If it's some kind of PCMCIA device like implied by pata_pcmcia
then it's likely DMA capable.

So if I return NULL then either a really DMA capable device will
not work. Or you got a real oddball device that you shouldn't have gotten
in the first place. 

Perhaps the PCMCIA code sets up some of its devices wrong? 

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6.22.2 review 06/84] Add a PCI ID for santa rosas PATA controller.

[Andrew Morton]

On Wed, 8 Aug 2007 01:39:12 +0200
Chr <[EMAIL PROTECTED]> wrote:

> On Tuesday, 7. August 2007, Greg KH wrote:
> > 
> > From: Christian Lamparter <[EMAIL PROTECTED]>
> > 
> > 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 <[EMAIL PROTECTED]>
> > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > 
> 
> 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 <[EMAIL PROTECTED]>
> (Just in case, if one of the patches really gets merged!)
> 

You kinda hid these patches rather well.

I chose option 1. 



-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/11] it8213/piix/slc90e66: remove {it8213,piix,slc90e66}_dma_2_pio()

[Bartlomiej Zolnierkiewicz]

On Sunday 05 August 2007, Sergei Shtylyov wrote:
> Hello.
> 
> Bartlomiej Zolnierkiewicz wrote:
> 
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> 
> Sigh... when I was talking about getting rid of that function, I meant 
> that we need to also decouple UltraDMA from PIO -- which is what this patch 
> misses...

Addressed in the follow-up patch.

> Actually, I intended to decouple DMA form PIO in this drivers completely 
> but that would be a next step...

DMA and PIO timings are shared on these controllers (except when DTE bit is
set, then PIO0 timings are always used and DMA timings are independent)...?

Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] ide: fix hidden dependencies on CONFIG_IDE_GENERIC

[Bartlomiej Zolnierkiewicz]

Some host drivers depend on CONFIG_IDE_GENERIC to do the probing but their
config options lack explicit dependencies on IDE_GENERIC.  In the long-term
these host drivers should be fixed to do the probing themselves but for now
fix them by making their config options select CONFIG_IDE_GENERIC.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 arch/cris/arch-v10/drivers/Kconfig |1 +
 arch/cris/arch-v32/drivers/Kconfig |1 +
 drivers/ide/Kconfig|9 +
 3 files changed, 11 insertions(+)

Index: b/arch/cris/arch-v10/drivers/Kconfig
===
--- a/arch/cris/arch-v10/drivers/Kconfig
+++ b/arch/cris/arch-v10/drivers/Kconfig
@@ -548,6 +548,7 @@ config ETRAX_IDE
select BLK_DEV_IDEDISK
select BLK_DEV_IDECD
select BLK_DEV_IDEDMA
+   select IDE_GENERIC
help
  Enable this to get support for ATA/IDE.
  You can't use parallel ports or SCSI ports
Index: b/arch/cris/arch-v32/drivers/Kconfig
===
--- a/arch/cris/arch-v32/drivers/Kconfig
+++ b/arch/cris/arch-v32/drivers/Kconfig
@@ -592,6 +592,7 @@ config ETRAX_IDE
select BLK_DEV_IDEDISK
select BLK_DEV_IDECD
select BLK_DEV_IDEDMA
+   select IDE_GENERIC
help
  Enables the ETRAX IDE driver.
 
Index: b/drivers/ide/Kconfig
===
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -304,6 +304,7 @@ comment "IDE chipset support/bugfixes"
 
 config IDE_GENERIC
tristate "generic/default IDE chipset support"
+   default H8300
help
  If unsure, say N.
 
@@ -352,6 +353,7 @@ config BLK_DEV_CMD640_ENHANCED
 config BLK_DEV_IDEPNP
bool "PNP EIDE support"
depends on PNP
+   select IDE_GENERIC
help
  If you have a PnP (Plug and Play) compatible EIDE card and
  would like the kernel to automatically detect and activate
@@ -858,6 +860,7 @@ config BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ
 
 config IDE_ARM
def_bool ARM && (ARCH_CLPS7500 || ARCH_RPC || ARCH_SHARK)
+   select IDE_GENERIC
 
 config BLK_DEV_IDE_ICSIDE
tristate "ICS IDE interface support"
@@ -891,6 +894,7 @@ config BLK_DEV_IDE_BAST
 config BLK_DEV_GAYLE
bool "Amiga Gayle IDE interface support"
depends on AMIGA
+   select IDE_GENERIC
help
  This is the IDE driver for the Amiga Gayle IDE interface. It supports
  both the `A1200 style' and `A4000 style' of the Gayle IDE interface,
@@ -922,6 +926,7 @@ config BLK_DEV_IDEDOUBLER
 config BLK_DEV_BUDDHA
bool "Buddha/Catweasel/X-Surf IDE interface support (EXPERIMENTAL)"
depends on ZORRO && EXPERIMENTAL
+   select IDE_GENERIC
help
  This is the IDE driver for the IDE interfaces on the Buddha, 
  Catweasel and X-Surf expansion boards.  It supports up to two 
interfaces 
@@ -934,6 +939,7 @@ config BLK_DEV_BUDDHA
 config BLK_DEV_FALCON_IDE
bool "Falcon IDE interface support"
depends on ATARI
+   select IDE_GENERIC
help
  This is the IDE driver for the builtin IDE interface on the Atari
  Falcon. Say Y if you have a Falcon and want to use IDE devices (hard
@@ -943,6 +949,7 @@ config BLK_DEV_FALCON_IDE
 config BLK_DEV_MAC_IDE
bool "Macintosh Quadra/Powerbook IDE interface support"
depends on MAC
+   select IDE_GENERIC
help
  This is the IDE driver for the builtin IDE interface on some m68k
  Macintosh models. It supports both the `Quadra style' (used in
@@ -956,6 +963,7 @@ config BLK_DEV_MAC_IDE
 config BLK_DEV_Q40IDE
bool "Q40/Q60 IDE interface support"
depends on Q40
+   select IDE_GENERIC
help
  Enable the on-board IDE controller in the Q40/Q60.  This should
  normally be on; disable it only if you are running a custom hard
@@ -964,6 +972,7 @@ config BLK_DEV_Q40IDE
 config BLK_DEV_MPC8xx_IDE
bool "MPC8xx IDE support"
depends on 8xx && IDE=y && BLK_DEV_IDE=y
+   select IDE_GENERIC
help
  This option provides support for IDE on Motorola MPC8xx Systems.
  Please see 'Type of MPC8xx IDE interface' for details.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] it8213/piix/slc90e66: "de-couple" PIO and UDMA modes

[Bartlomiej Zolnierkiewicz]

Don't force PIO4 when programming UDMA mode (suggested by Sergei).

Cc: Sergei Shtylyov <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/pci/it8213.c   |9 -
 drivers/ide/pci/piix.c |   11 +--
 drivers/ide/pci/slc90e66.c |   10 --
 3 files changed, 13 insertions(+), 17 deletions(-)

Index: b/drivers/ide/pci/it8213.c
===
--- a/drivers/ide/pci/it8213.c
+++ b/drivers/ide/pci/it8213.c
@@ -93,7 +93,7 @@ static void it8213_set_dma_mode(ide_driv
int w_flag  = 0x10 << drive->dn;
int u_speed = 0;
u16 reg4042, reg4a;
-   u8  reg48, reg54, reg55, pio;
+   u8  reg48, reg54, reg55;
 
pci_read_config_word(dev, maslave, ®4042);
pci_read_config_byte(dev, 0x48, ®48);
@@ -134,10 +134,9 @@ static void it8213_set_dma_mode(ide_driv
pci_write_config_byte(dev, 0x54, reg54 | 
v_flag);
} else
pci_write_config_byte(dev, 0x54, reg54 & ~v_flag);
-
-   pio = 4;
} else {
const u8 mwdma_to_pio[] = { 0, 3, 4 };
+   u8 pio;
 
if (reg48 & u_flag)
pci_write_config_byte(dev, 0x48, reg48 & ~u_flag);
@@ -152,9 +151,9 @@ static void it8213_set_dma_mode(ide_driv
pio = mwdma_to_pio[speed - XFER_MW_DMA_0];
else
pio = 2; /* only SWDMA2 is allowed */
-   }
 
-   it8213_set_pio_mode(drive, pio);
+   it8213_set_pio_mode(drive, pio);
+   }
 }
 
 /**
Index: b/drivers/ide/pci/piix.c
===
--- a/drivers/ide/pci/piix.c
+++ b/drivers/ide/pci/piix.c
@@ -1,5 +1,5 @@
 /*
- *  linux/drivers/ide/pci/piix.c   Version 0.52Jul 14, 2007
+ *  linux/drivers/ide/pci/piix.c   Version 0.53Aug 9, 2007
  *
  *  Copyright (C) 1998-1999 Andrzej Krzysztofowicz, Author and Maintainer
  *  Copyright (C) 1998-2000 Andre Hedrick <[EMAIL PROTECTED]>
@@ -194,7 +194,7 @@ static void piix_set_dma_mode(ide_drive_
int u_speed = 0;
int sitre;
u16 reg4042, reg4a;
-   u8  reg48, reg54, reg55, pio;
+   u8  reg48, reg54, reg55;
 
pci_read_config_word(dev, maslave, ®4042);
sitre = (reg4042 & 0x4000) ? 1 : 0;
@@ -231,10 +231,9 @@ static void piix_set_dma_mode(ide_drive_
pci_write_config_byte(dev, 0x54, reg54 | 
v_flag);
} else
pci_write_config_byte(dev, 0x54, reg54 & ~v_flag);
-
-   pio = 4;
} else {
const u8 mwdma_to_pio[] = { 0, 3, 4 };
+   u8 pio;
 
if (reg48 & u_flag)
pci_write_config_byte(dev, 0x48, reg48 & ~u_flag);
@@ -249,9 +248,9 @@ static void piix_set_dma_mode(ide_drive_
pio = mwdma_to_pio[speed - XFER_MW_DMA_0];
else
pio = 2; /* only SWDMA2 is allowed */
-   }
 
-   piix_set_pio_mode(drive, pio);
+   piix_set_pio_mode(drive, pio);
+   }
 }
 
 /**
Index: b/drivers/ide/pci/slc90e66.c
===
--- a/drivers/ide/pci/slc90e66.c
+++ b/drivers/ide/pci/slc90e66.c
@@ -1,5 +1,5 @@
 /*
- *  linux/drivers/ide/pci/slc90e66.c   Version 0.17Aug 2, 2007
+ *  linux/drivers/ide/pci/slc90e66.c   Version 0.18Aug 9, 2007
  *
  *  Copyright (C) 2000-2002 Andre Hedrick <[EMAIL PROTECTED]>
  *  Copyright (C) 2006-2007 MontaVista Software, Inc. <[EMAIL PROTECTED]>
@@ -82,7 +82,6 @@ static void slc90e66_set_dma_mode(ide_dr
int sitre = 0, a_speed  = 7 << (drive->dn * 4);
int u_speed = 0, u_flag = 1 << drive->dn;
u16 reg4042, reg44, reg48, reg4a;
-   u8  pio;
 
pci_read_config_word(dev, maslave, ®4042);
sitre = (reg4042 & 0x4000) ? 1 : 0;
@@ -111,10 +110,9 @@ static void slc90e66_set_dma_mode(ide_dr
pci_read_config_word(dev, 0x4a, ®4a);
pci_write_config_word(dev, 0x4a, reg4a|u_speed);
}
-
-   pio = 4;
} else {
const u8 mwdma_to_pio[] = { 0, 3, 4 };
+   u8 pio;
 
if (reg48 & u_flag)
pci_write_config_word(dev, 0x48, reg48 & ~u_flag);
@@ -125,9 +123,9 @@ static void slc90e66_set_dma_mode(ide_dr
pio = mwdma_to_pio[speed - XFER_MW_DMA_0];
else
pio = 2; /* only SWDMA2 is allowed */
-   }
 
-   slc90e66_set_pio_mode(drive, pio);
+   slc90e66_set_pio_mode(drive, pi

[PATCH 3/4] sis5513: clear prefetch and postwrite for ATAPI devices

[Bartlomiej Zolnierkiewicz]

Clear prefetch and postwrite for ATAPI devices instead of depending on BIOS.

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/pci/sis5513.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

Index: b/drivers/ide/pci/sis5513.c
===
--- a/drivers/ide/pci/sis5513.c
+++ b/drivers/ide/pci/sis5513.c
@@ -1,5 +1,5 @@
 /*
- * linux/drivers/ide/pci/sis5513.c Version 0.29Aug 1, 2007
+ * linux/drivers/ide/pci/sis5513.c Version 0.30Aug 9, 2007
  *
  * Copyright (C) 1999-2000 Andre Hedrick <[EMAIL PROTECTED]>
  * Copyright (C) 2002  Lionel Bouton <[EMAIL PROTECTED]>, Maintainer
@@ -522,20 +522,19 @@ static void sis_program_timings(ide_driv
sis_ata133_program_timings(drive, mode);
 }
 
-/* Enables per-drive prefetch and postwrite */
 static void config_drive_art_rwp (ide_drive_t *drive)
 {
ide_hwif_t *hwif= HWIF(drive);
struct pci_dev *dev = hwif->pci_dev;
-
u8 reg4bh   = 0;
-   u8 rw_prefetch  = (0x11 << drive->dn);
+   u8 rw_prefetch  = 0;
 
-   if (drive->media != ide_disk)
-   return;
pci_read_config_byte(dev, 0x4b, ®4bh);
 
-   if ((reg4bh & rw_prefetch) != rw_prefetch)
+   if (drive->media == ide_disk)
+   rw_prefetch = 0x11 << drive->dn;
+
+   if ((reg4bh & (0x11 << drive->dn)) != rw_prefetch)
pci_write_config_byte(dev, 0x4b, reg4bh|rw_prefetch);
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] sis5513: remove /proc/ide/sis

[Bartlomiej Zolnierkiewicz]

This belongs to user-space (and only if really needed).

   textdata bss dec hex filename
   7129 404   875411d75 drivers/ide/pci/sis5513.o.before
   3916 404   1432110e1 drivers/ide/pci/sis5513.o.after

Additionaly to being bloat the code contained two bugs:
- wrong cable bit was checked (0x0001 instead of 0x8000) on ATA_133 chipsets
- incorrect UDMA cycle time was reported on ATA_100a/ATA_133 chipsets

Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ide/pci/sis5513.c |  249 --
 1 file changed, 1 insertion(+), 248 deletions(-)

Index: b/drivers/ide/pci/sis5513.c
===
--- a/drivers/ide/pci/sis5513.c
+++ b/drivers/ide/pci/sis5513.c
@@ -1,5 +1,5 @@
 /*
- * linux/drivers/ide/pci/sis5513.c Version 0.30Aug 9, 2007
+ * linux/drivers/ide/pci/sis5513.c Version 0.31Aug 9, 2007
  *
  * Copyright (C) 1999-2000 Andre Hedrick <[EMAIL PROTECTED]>
  * Copyright (C) 2002  Lionel Bouton <[EMAIL PROTECTED]>, Maintainer
@@ -65,8 +65,6 @@
 
 #include "ide-timing.h"
 
-#define DISPLAY_SIS_TIMINGS
-
 /* registers layout and init values are chipset family dependant */
 
 #define ATA_16 0x01
@@ -193,243 +191,6 @@ static char* chipset_capability[] = {
"ATA 133 (1st gen)", "ATA 133 (2nd gen)"
 };
 
-#if defined(DISPLAY_SIS_TIMINGS) && defined(CONFIG_IDE_PROC_FS)
-#include 
-#include 
-
-static u8 sis_proc = 0;
-
-static struct pci_dev *bmide_dev;
-
-static char* cable_type[] = {
-   "80 pins",
-   "40 pins"
-};
-
-static char* recovery_time[] ={
-   "12 PCICLK", "1 PCICLK",
-   "2 PCICLK", "3 PCICLK",
-   "4 PCICLK", "5 PCICLCK",
-   "6 PCICLK", "7 PCICLCK",
-   "8 PCICLK", "9 PCICLCK",
-   "10 PCICLK", "11 PCICLK",
-   "13 PCICLK", "14 PCICLK",
-   "15 PCICLK", "15 PCICLK"
-};
-
-static char* active_time[] = {
-   "8 PCICLK", "1 PCICLCK",
-   "2 PCICLK", "3 PCICLK",
-   "4 PCICLK", "5 PCICLK",
-   "6 PCICLK", "12 PCICLK"
-};
-
-static char* cycle_time[] = {
-   "Reserved", "2 CLK",
-   "3 CLK", "4 CLK",
-   "5 CLK", "6 CLK",
-   "7 CLK", "8 CLK",
-   "9 CLK", "10 CLK",
-   "11 CLK", "12 CLK",
-   "13 CLK", "14 CLK",
-   "15 CLK", "16 CLK"
-};
-
-/* Generic add master or slave info function */
-static char* get_drives_info (char *buffer, u8 pos)
-{
-   u8 reg00, reg01, reg10, reg11; /* timing registers */
-   u32 regdw0, regdw1;
-   char* p = buffer;
-
-/* Postwrite/Prefetch */
-   if (chipset_family < ATA_133) {
-   pci_read_config_byte(bmide_dev, 0x4b, ®00);
-   p += sprintf(p, "Drive %d:Postwrite %s \t \t Postwrite 
%s\n",
-pos, (reg00 & (0x10 << pos)) ? "Enabled" : 
"Disabled",
-(reg00 & (0x40 << pos)) ? "Enabled" : "Disabled");
-   p += sprintf(p, "Prefetch  %s \t \t Prefetch  
%s\n",
-(reg00 & (0x01 << pos)) ? "Enabled" : "Disabled",
-(reg00 & (0x04 << pos)) ? "Enabled" : "Disabled");
-   pci_read_config_byte(bmide_dev, 0x40+2*pos, ®00);
-   pci_read_config_byte(bmide_dev, 0x41+2*pos, ®01);
-   pci_read_config_byte(bmide_dev, 0x44+2*pos, ®10);
-   pci_read_config_byte(bmide_dev, 0x45+2*pos, ®11);
-   } else {
-   u32 reg54h;
-   u8 drive_pci = 0x40;
-   pci_read_config_dword(bmide_dev, 0x54, ®54h);
-   if (reg54h & 0x4000) {
-   // Configuration space remapped to 0x70
-   drive_pci = 0x70;
-   }
-   pci_read_config_dword(bmide_dev, (unsigned 
long)drive_pci+4*pos, ®dw0);
-   pci_read_config_dword(bmide_dev, (unsigned 
long)drive_pci+4*pos+8, ®dw1);
-
-   p += sprintf(p, "Drive %d:\n", pos);
-   }
-
-
-/* UDMA */
-   if (chipset_family >= ATA_133) {
-   p += sprintf(p, "UDMA %s \t \t \t UDMA %s\n",
-(regdw0 & 0x04) ? "Enabled" : "Disabled",
-(regdw1 & 0x04) ? "Enabled" : "Disabled");
-   p += sprintf(p, "UDMA Cycle Time%s \t UDMA 
Cycle Time%s\n",
-cycle_time[(regdw0 & 0xF0) >> 4],
-cycle_time[(regdw1 & 0xF0) >> 4]);
-   } else if (chipset_family >= ATA_33) {
-   p += sprintf(p, "UDMA %s \t \t \t UDMA %s\n",
-(reg01 & 0x80) ? "Enabled" : "Disabled",
-(reg11 & 0x80) ? "Enabled" : "Disabled");
-
-   p += sprintf(p, "UDMA Cycle Time");
-   switch(chipset_family) {
-   case ATA_33:p += sprintf(p, cycle_time[(reg01 & 

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[James Bottomley]

On Thu, 2007-08-09 at 18:53 +0100, Alan Cox wrote:
> > Someone must ask that caller library to DMA to/from that device
> > in the first place. Whoever it is it is wrong. 
> 
> No I disagree.

I'm with Andi here ... you're fortunate that parisc has no working
IDE/SATA interface (or rather we have so few running boxes with PCMCIA),
but if it did this call sequence would explode on that platform for a
different reason.

> > Or perhaps you got the wrong device here? For ISA devices we 
> > traditionally used NULL. Or if you set up your own ISA devices
> > (which I can't see a reason for but there might be one I'm missing) 
> > at least give them a dma mask. Then it should probably work on x86-64.
> 
> The libata code currently (and this seems to work for all but x86-64)
> does the following if it is setting up a potentially DMA capable device
> 
>   - Allocate a dma_coherent buffer

You cannot allocate a dma_coherent buffer without passing in the correct
underlying device ... on parisc we'd explode trying to find the iommu to
map through (some of our hw has more than one).

>   - If it is refused then turn off DMA and use PIO
> 
> It has no idea whether a pcmcia, isa, platform or even PCI device happens
> to be DMA capable, and there are platforms with PCI but very limited DMA
> for example in the embedded space. In fact it has no idea this level
> whether it is working a PCI, ISA, PCMCIA, SBUS or some other bus device.
> It's supposed to be generic code.
> 
> Obviously doing anything other than dma_alloc_coherent if the allocation
> fails is stupid but trying to allocate dma memory to find out if the
> device can be used with DMA on a given platform is quite logical and
> sensible in some cases.
> 
> Thus I think dma_alloc_coherent() for an ISA, PCMCIA or other class
> (platform particularly) shouldn't explode on AMD64 but simply return
> NULL. Its a sane request to make when you don't in your library know what
> dev is.

PCMCIA should be correctly plumbed into the generic model.  It's really
just a bridge ... how that bridge is wired critically affects how
coherent memory is allocated.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL

[Bartlomiej Zolnierkiewicz]

While at it:

On Sunday 05 August 2007, Sergei Shtylyov wrote:

> Index: linux-2.6/drivers/ata/pata_hpt37x.c
> ===
> --- linux-2.6.orig/drivers/ata/pata_hpt37x.c
> +++ linux-2.6/drivers/ata/pata_hpt37x.c
> @@ -8,12 +8,10 @@

this driver is lacking author/maintainer info:

/*
 * Libata driver for the highpoint 37x and 30x UDMA66 ATA controllers.
 *
 * This driver is heavily based upon:
 *
 * linux/drivers/ide/pci/hpt366.c   Version 0.36April 25, 2003
 *

>   * Copyright (C) 1999-2003   Andre Hedrick <[EMAIL PROTECTED]>
>   * Portions Copyright (C) 2001   Sun Microsystems, Inc.
>   * Portions Copyright (C) 2003   Red Hat Inc
> - * Portions Copyright (C) 2005-2006  MontaVista Software, Inc.
> + * Portions Copyright (C) 2005-2007  MontaVista Software, Inc.

reference to hpt366 version should also be updated (or removed)

>   *
>   * TODO
> - *   PLL mode
> - *   Look into engine reset on timeout errors. Should not be
> - *   required.
> + *   Look into engine reset on timeout errors. Should not be required.
>   */
>  
>  #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] libata-core: support wildcard matching in ata_blacklist_entry

[David Milburn]

Support the use of '*' in model_num and model_rev entries
in ata_device_blacklist[].

Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: David Milburn <[EMAIL PROTECTED]>
---

 libata-core.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 60e78be..4603bd9 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3796,6 +3796,18 @@ static const struct ata_blacklist_entry 
ata_device_blacklist [] = {
{ }
 };
 
+int strn_pattern_cmp(const char *patt, const char *name, int c)
+{
+   const char *p = strchr(patt, c);
+   int len;
+
+   if (p == NULL)
+   len = strlen(name);
+   else
+   len = p-patt;
+   return strncmp(patt, name, len);
+}
+
 static unsigned long ata_dev_blacklisted(const struct ata_device *dev)
 {
unsigned char model_num[ATA_ID_PROD_LEN + 1];
@@ -3806,10 +3818,10 @@ static unsigned long ata_dev_blacklisted(const struct 
ata_device *dev)
ata_id_c_string(dev->id, model_rev, ATA_ID_FW_REV, sizeof(model_rev));
 
while (ad->model_num) {
-   if (!strcmp(ad->model_num, model_num)) {
+   if (!strn_pattern_cmp(ad->model_num, model_num, '*')) {
if (ad->model_rev == NULL)
return ad->horkage;
-   if (!strcmp(ad->model_rev, model_rev))
+   if (!strn_pattern_cmp(ad->model_rev, model_rev, '*'))
return ad->horkage;
}
ad++;
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

sata_promise: Warning/Errors with SATA300 TX4 and SAMSUNG HD501LJ

[Sebastian Witt]

Hello,

I'm using a Promise SATA300 TX4 with SAMSUNG HD501LJ harddisks on kernel 2.6.21. 
On high disk load sometimes warning/error messages are printed out:


...
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata4.00: cmd c8/00:08:8f:7f:85/00:00:00:00:00/ef tag 0 cdb 0x0 data 4096 in
 res 50/00:00:96:7f:85/00:00:11:00:00/ef Emask 0x1 (device error)
ata4.00: configured for UDMA/133
ata4: EH complete
...

They are not happening very often (three in the last few days) and also
no other problems occured (filesystem/data ok).

dmesg:
...
scsi0 : sata_promise
ata1: SATA link down (SStatus 0 SControl 300)
scsi1 : sata_promise
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-8: SAMSUNG HD501LJ, CR100-10, max UDMA7
ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/133
scsi2 : sata_promise
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-8: SAMSUNG HD501LJ, CR100-10, max UDMA7
ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata3.00: configured for UDMA/133
scsi3 : sata_promise
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: ATA-8: SAMSUNG HD501LJ, CR100-10, max UDMA7
ata4.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata4.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access ATA  SAMSUNG HD501LJ  CR10 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

 sda: sda1
sd 1:0:0:0: [sda] Attached SCSI disk
sd 1:0:0:0: Attached scsi generic sg0 type 0
scsi 2:0:0:0: Direct-Access ATA  SAMSUNG HD501LJ  CR10 PQ: 0 ANSI: 5
sd 2:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

sd 2:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

 sdb: sdb1
sd 2:0:0:0: [sdb] Attached SCSI disk
sd 2:0:0:0: Attached scsi generic sg1 type 0
scsi 3:0:0:0: Direct-Access ATA  SAMSUNG HD501LJ  CR10 PQ: 0 ANSI: 5
sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

 sdc: sdc1
sd 3:0:0:0: [sdc] Attached SCSI disk
sd 3:0:0:0: Attached scsi generic sg2 type 0

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata4.00: cmd 25/00:28:d7:51:a5/00:00:11:00:00/e0 tag 0 cdb 0x0 data 20480 in
 res 50/00:00:fe:51:a5/00:00:11:00:00/e0 Emask 0x1 (device error)
ata4.00: configured for UDMA/133
ata4: EH complete
sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata4.00: cmd c8/00:08:8f:7f:85/00:00:00:00:00/ef tag 0 cdb 0x0 data 4096 in
 res 50/00:00:96:7f:85/00:00:11:00:00/ef Emask 0x1 (device error)
ata4.00: configured for UDMA/133
ata4: EH complete
sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB)
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.00: cmd 25/00:80:2f:fd:c2/00:00:1a:00:00/e0 tag 0 cdb 0x0 data 65536 in
 res 50/00:00:ae:fd:c2/00:00:1a:00:00/e0 Emask 0x1 (device error)
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA



Some ideas? Not optimal/not good/bad/very bad?

Regards,
Sebastian
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] pata_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]

[Bartlomiej Zolnierkiewicz]

Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):

* Fix the problem by adding missing struct ata_port_info to artop_init_one().

* Use the right naming (s/626/628/).

* Bump driver version.

Fixes IDE->libata regression, problem was never present in IDE aec62xx driver.

Cc: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
 drivers/ata/pata_artop.c |   19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

Index: b/drivers/ata/pata_artop.c
===
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -2,6 +2,7 @@
  *pata_artop.c - ARTOP ATA controller driver
  *
  * (C) 2006 Red Hat <[EMAIL PROTECTED]>
+ * (C) 2007 Bartlomiej Zolnierkiewicz
  *
  *Based in part on drivers/ide/pci/aec62xx.c
  * Copyright (C) 1999-2002 Andre Hedrick <[EMAIL PROTECTED]>
@@ -28,7 +29,7 @@
 #include 
 
 #define DRV_NAME   "pata_artop"
-#define DRV_VERSION"0.4.3"
+#define DRV_VERSION"0.4.4"
 
 /*
  * The ARTOP has 33 Mhz and "over clocked" timing tables. Until we
@@ -430,7 +431,7 @@ static int artop_init_one (struct pci_de
.udma_mask  = ATA_UDMA4,
.port_ops   = &artop6260_ops,
};
-   static const struct ata_port_info info_626x_fast = {
+   static const struct ata_port_info info_628x = {
.sht= &artop_sht,
.flags  = ATA_FLAG_SLAVE_POSS,
.pio_mask   = 0x1f, /* pio0-4 */
@@ -438,6 +439,14 @@ static int artop_init_one (struct pci_de
.udma_mask  = ATA_UDMA5,
.port_ops   = &artop6260_ops,
};
+   static const struct ata_port_info info_628x_fast = {
+   .sht= &artop_sht,
+   .flags  = ATA_FLAG_SLAVE_POSS,
+   .pio_mask   = 0x1f, /* pio0-4 */
+   .mwdma_mask = 0x07, /* mwdma0-2 */
+   .udma_mask  = ATA_UDMA6,
+   .port_ops   = &artop6260_ops,
+   };
const struct ata_port_info *ppi[] = { NULL, NULL };
 
if (!printed_version++)
@@ -455,13 +464,13 @@ static int artop_init_one (struct pci_de
}
else if (id->driver_data == 1)  /* 6260 */
ppi[0] = &info_626x;
-   else if (id->driver_data == 2)  { /* 6260 or 6260 + fast */
+   else if (id->driver_data == 2)  { /* 6280 or 6280 + fast */
unsigned long io = pci_resource_start(pdev, 4);
u8 reg;
 
-   ppi[0] = &info_626x;
+   ppi[0] = &info_628x;
if (inb(io) & 0x10)
-   ppi[0] = &info_626x_fast;
+   ppi[0] = &info_628x_fast;
/* Mac systems come up with some registers not set as we
   will need them */
 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 0/4] Updated SATA Link Power Management patches

[Kristen Carlson Accardi]

Hello,
Here are some updated ALPM patches.  These patches are different from the
last version in that they now use the error handler to enable link power
management.  Please review and let me know what you think.

Kristen

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 1/4] Store interrupt value

[Kristen Carlson Accardi]

Use a stored value for which interrupts to enable.  Changing this allows
us to selectively turn off certain interrupts later and have them 
stay off.

Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>

Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -175,6 +175,7 @@ enum {
AHCI_FLAG_32BIT_ONLY= (1 << 28), /* force 32bit */
AHCI_FLAG_MV_PATA   = (1 << 29), /* PATA port */
AHCI_FLAG_NO_MSI= (1 << 30), /* no PCI MSI */
+   AHCI_FLAG_NO_HOTPLUG= (1 << 31), /* ignore PxSERR.DIAG.N */
 
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
  ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
@@ -215,6 +216,7 @@ struct ahci_port_priv {
unsigned intncq_saw_d2h:1;
unsigned intncq_saw_dmas:1;
unsigned intncq_saw_sdb:1;
+   u32 intr_mask;  /* interrupts to enable */
 };
 
 static int ahci_scr_read(struct ata_port *ap, unsigned int sc_reg, u32 *val);
@@ -1518,6 +1520,7 @@ static void ahci_thaw(struct ata_port *a
void __iomem *mmio = ap->host->iomap[AHCI_PCI_BAR];
void __iomem *port_mmio = ahci_port_base(ap);
u32 tmp;
+   struct ahci_port_priv *pp = ap->private_data;
 
/* clear IRQ */
tmp = readl(port_mmio + PORT_IRQ_STAT);
@@ -1525,7 +1528,7 @@ static void ahci_thaw(struct ata_port *a
writel(1 << ap->port_no, mmio + HOST_IRQ_STAT);
 
/* turn IRQ back on */
-   writel(DEF_PORT_IRQ, port_mmio + PORT_IRQ_MASK);
+   writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
 }
 
 static void ahci_error_handler(struct ata_port *ap)
@@ -1679,6 +1682,12 @@ static int ahci_port_start(struct ata_po
pp->cmd_tbl = mem;
pp->cmd_tbl_dma = mem_dma;
 
+   /*
+* Save off initial list of interrupts to be enabled.
+* This could be changed later
+*/
+   pp->intr_mask = DEF_PORT_IRQ;
+
ap->private_data = pp;
 
/* engage engines, captain */

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 2/4] increase number of allowable device flags

[Kristen Carlson Accardi]

Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>

Index: 2.6-git/include/linux/libata.h
===
--- 2.6-git.orig/include/linux/libata.h
+++ 2.6-git/include/linux/libata.h
@@ -139,7 +139,7 @@ enum {
ATA_DFLAG_FLUSH_EXT = (1 << 4), /* do FLUSH_EXT instead of FLUSH */
ATA_DFLAG_ACPI_PENDING  = (1 << 5), /* ACPI resume action pending */
ATA_DFLAG_ACPI_FAILED   = (1 << 6), /* ACPI on devcfg has failed */
-   ATA_DFLAG_CFG_MASK  = (1 << 8) - 1,
+   ATA_DFLAG_CFG_MASK  = (1 << 12) - 1,
 
ATA_DFLAG_PIO   = (1 << 8), /* device limited to PIO mode */
ATA_DFLAG_NCQ_OFF   = (1 << 9), /* device limited to non-NCQ mode */

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 3/4] Enable link power management for ata drivers

[Kristen Carlson Accardi]

libata drivers can define a function (enable_pm) that will
perform hardware specific actions to enable whatever power
management policy the user set up from the scsi sysfs 
interface if the driver supports it.  This power management 
policy will be activated after all disks have been 
enumerated and intialized.  Drivers should also define
disable_pm, which will turn off link power management, but
not change link power management policy.

Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-git/drivers/ata/libata-scsi.c
===
--- 2.6-git.orig/drivers/ata/libata-scsi.c
+++ 2.6-git/drivers/ata/libata-scsi.c
@@ -110,6 +110,78 @@ static struct scsi_transport_template at
.user_scan  = ata_scsi_user_scan,
 };
 
+static const struct {
+   enum link_pmvalue;
+   char*name;
+} link_pm_policy[] = {
+   { NOT_AVAILABLE, "max_performance" },
+   { MIN_POWER, "min_power" },
+   { MAX_PERFORMANCE, "max_performance" },
+   { MEDIUM_POWER, "medium_power" },
+};
+
+const char *ata_scsi_link_pm_policy(enum link_pm policy)
+{
+   int i;
+   char *name = NULL;
+
+   for (i = 0; i < ARRAY_SIZE(link_pm_policy); i++) {
+   if (link_pm_policy[i].value == policy) {
+   name = link_pm_policy[i].name;
+   break;
+   }
+   }
+   return name;
+}
+
+static ssize_t store_link_pm_policy(struct class_device *class_dev,
+   const char *buf, size_t count)
+{
+   struct Scsi_Host *shost = class_to_shost(class_dev);
+   struct ata_port *ap = ata_shost_to_port(shost);
+   enum link_pm policy = 0;
+   int i;
+
+   /*
+* we are skipping array location 0 on purpose - this
+* is because a value of NOT_AVAILABLE is displayed
+* to the user as max_performance, but when the user
+* writes "max_performance", they actually want the
+* value to match MAX_PERFORMANCE.
+*/
+   for (i = 1; i < ARRAY_SIZE(link_pm_policy); i++) {
+   const int len = strlen(link_pm_policy[i].name);
+   if (strncmp(link_pm_policy[i].name, buf, len) == 0 &&
+  buf[len] == '\n') {
+   policy = link_pm_policy[i].value;
+   break;
+   }
+   }
+   if (!policy)
+   return -EINVAL;
+
+   if (ata_scsi_set_link_pm_policy(ap, policy))
+   return -EINVAL;
+   return count;
+}
+
+static ssize_t
+show_link_pm_policy(struct class_device *class_dev, char *buf)
+{
+   struct Scsi_Host *shost = class_to_shost(class_dev);
+   struct ata_port *ap = ata_shost_to_port(shost);
+   const char *policy =
+   ata_scsi_link_pm_policy(ap->pm_policy);
+
+   if (!policy)
+   return -EINVAL;
+
+   return snprintf(buf, 23, "%s\n", policy);
+}
+CLASS_DEVICE_ATTR(link_power_management_policy, S_IRUGO | S_IWUSR,
+   show_link_pm_policy, store_link_pm_policy);
+EXPORT_SYMBOL_GPL(class_device_attr_link_power_management_policy);
+
 static void ata_scsi_invalid_field(struct scsi_cmnd *cmd,
   void (*done)(struct scsi_cmnd *))
 {
@@ -2904,6 +2976,52 @@ void ata_scsi_simulate(struct ata_device
}
 }
 
+int ata_scsi_set_link_pm_policy(struct ata_port *ap,
+   enum link_pm policy)
+{
+   int rc = -EINVAL;
+   int i;
+
+   /*
+* make sure no broken devices are on this port,
+* and that all devices support interface power
+* management
+*/
+   for (i = 0; i < ATA_MAX_DEVICES; i++) {
+   struct ata_device *dev = &ap->device[i];
+
+   /* only check drives which exist */
+   if (!ata_dev_enabled(dev))
+   continue;
+
+   /*
+* do we need to handle the case where we've hotplugged
+* a broken drive (since hotplug and ALPM are mutually
+* exclusive) ?
+*
+* If so, if we detect a broken drive on a port with
+* alpm already enabled, then we should reset the policy
+* to off for the entire port.
+*/
+   if ((dev->horkage & ATA_HORKAGE_IPM) ||
+   !(dev->flags & ATA_DFLAG_IPM)) {
+   ata_dev_printk(dev, KERN_ERR,
+   "Unable to set Link PM policy\n");
+   ap->pm_policy = MAX_PERFORMANCE;
+   }
+   }
+
+   if (ap->ops->enable_pm) {
+   ap->pm_policy = policy;
+   ap->eh_info.action |= ATA_EHI_LPM;
+   ap->eh_info.flags |= ATA_EHI_NO_AUTOPSY;
+   ata_port_schedule_eh(ap);
+   rc = 0;
+   }
+   return rc;
+}
+EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy);
+
 int ata_scsi_add_hosts(

[patch 4/4] Enable Aggressive Link Power management for AHCI controllers.

[Kristen Carlson Accardi]

This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver.  This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details).  This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled.  ALPM will be enabled by default, but it is
settable via the scsi host syfs interface.  Possible 
settings for this feature are:

Setting Effect
--
min_power   ALPM is enabled, and link set to enter 
lowest power state (SLUMBER) when idle
Hot plug not allowed.

max_performance ALPM is disabled, Hot Plug is allowed

medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle.  Hot plug not allowed.

Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>

Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -48,6 +48,9 @@
 #define DRV_NAME   "ahci"
 #define DRV_VERSION"2.3"
 
+static int ahci_enable_alpm(struct ata_port *ap,
+   enum link_pm policy);
+static int ahci_disable_alpm(struct ata_port *ap);
 
 enum {
AHCI_PCI_BAR= 5,
@@ -98,6 +101,7 @@ enum {
/* HOST_CAP bits */
HOST_CAP_SSC= (1 << 14), /* Slumber capable */
HOST_CAP_CLO= (1 << 24), /* Command List Override support */
+   HOST_CAP_ALPM   = (1 << 26), /* Aggressive Link PM support */
HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */
HOST_CAP_SNTF   = (1 << 29), /* SNotification register */
HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */
@@ -153,6 +157,8 @@ enum {
  PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
 
/* PORT_CMD bits */
+   PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */
+   PORT_CMD_ALPE   = (1 << 26), /* Aggressive Link PM enable */
PORT_CMD_ATAPI  = (1 << 24), /* Device is ATAPI */
PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */
PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */
@@ -244,6 +250,11 @@ static int ahci_pci_device_suspend(struc
 static int ahci_pci_device_resume(struct pci_dev *pdev);
 #endif
 
+static struct class_device_attribute *ahci_shost_attrs[] = {
+   &class_device_attr_link_power_management_policy,
+   NULL
+};
+
 static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name   = DRV_NAME,
@@ -261,6 +272,7 @@ static struct scsi_host_template ahci_sh
.slave_configure= ata_scsi_slave_config,
.slave_destroy  = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+   .shost_attrs= ahci_shost_attrs,
 };
 
 static const struct ata_port_operations ahci_ops = {
@@ -292,6 +304,8 @@ static const struct ata_port_operations 
.port_suspend   = ahci_port_suspend,
.port_resume= ahci_port_resume,
 #endif
+   .enable_pm  = ahci_enable_alpm,
+   .disable_pm = ahci_disable_alpm,
 
.port_start = ahci_port_start,
.port_stop  = ahci_port_stop,
@@ -778,6 +792,156 @@ static void ahci_power_up(struct ata_por
writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
 }
 
+static int ahci_disable_alpm(struct ata_port *ap)
+{
+   void __iomem *port_mmio = ahci_port_base(ap);
+   u32 cmd, scontrol;
+   struct ahci_port_priv *pp = ap->private_data;
+
+   /*
+* disable Interface Power Management State Transitions
+* This is accomplished by setting bits 8:11 of the
+* SATA Control register
+*/
+   scontrol = readl(port_mmio + PORT_SCR_CTL);
+   scontrol |= (0x3 << 8);
+   writel(scontrol, port_mmio + PORT_SCR_CTL);
+
+   /* get the existing command bits */
+   cmd = readl(port_mmio + PORT_CMD);
+
+   /* disable ALPM and ASP */
+   cmd &= ~PORT_CMD_ASP;
+   cmd &= ~PORT_CMD_ALPE;
+
+   /* force the interface back to active */
+   cmd |= PORT_CMD_ICC_ACTIVE;
+
+   /* write out new cmd value */
+   writel(cmd, port_mmio + PORT_CMD);
+   cmd = readl(port_mmio + PORT_CMD);
+
+   /* wait 10ms to be sure we've come out of any low power state */
+   msleep(10);
+
+   /* clear out any PhyRdy stuff from interrupt status */
+   writel(PORT_IRQ_PHYRDY, port_mmio + PORT_IRQ_STAT);
+
+   /* go ahead and clean out PhyRdy Change from Serror too */
+   ahci_scr_write(ap, SCR_ERROR, ((1 << 16) | (1 << 18)));
+
+   /*
+* Clear flag to in

Re: Disk spin down issue on shut down/suspend to disk

[Rafael J. Wysocki]

On Wednesday, 8 August 2007 14:24, Rafael J. Wysocki wrote:
> On Wednesday, 8 August 2007 04:56, Tejun Heo wrote:
> > Rafael J. Wysocki wrote:
> > > Well, on my box (nx6325) with the appended (experimental) patch applied
> > > on top of 2.6.23-rc1 with the patchset from
> > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , 
> > > the
> > > double spin down doesn't occur during hibernation and the system is shut 
> > > down
> > > notceably faster.
> > 
> > Can you please explain what the patch does?
> 
> It replaces the shutting down of devices done by kernel_shutdown_prepare()
> with the suspending of the (just like before entering S3, but the target state
> is now S4) and the shutting down of sysdevs with suspending them.
> 
> It also disables the nonboot CPUs before entering the sleep state (S4), which
> generally always is a good idea.
> 
> In short, it makes hibernation_platform_enter() execute the 
> enter-a-sleep-state
> sequence instead of the mixed shutdown-with-entering-S4 thing.
> 
> > So, I take it that entering S4 also spins down the disk.
> 
> Yes.
> 
> > Does the patch remove the ACPI spin down or libata one?
> 
> I _think_ that it removes the ACPI one, although I'll need to do some more
> testing to confirm that.

OK

I can confirm that the patch removes the ACPI spin down (ie. the one that
happens in the power down phase without the patch).

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Alan Cox]

> Where does the device come from? What device is it?

At the higher level someone passed us a device and some mappings and
function methods and said "this is an IDE controller"

> Is that known already?

The core code has no idea or interest in where it came from.

> But at least on x86-64 the device is likely DMA capable. At least
> PCMCIA usually is.  Near all devices are DMA capable, except perhaps

PCMCIA usally isn't.

> So if I return NULL then either a really DMA capable device will
> not work. Or you got a real oddball device that you shouldn't have gotten
> in the first place. 

What about other platforms ? I don't want libata to have

#ifdef CONFIG_X86_64
/* this platform is different)
if (hack-around-in-dev-struct())
return NULL;
#endif


All I want is

This is a device, the caller has said it may be DMA capable
dma_alloc_coherent
NULL. ok in this situation it isn't

I don't want to know about arch internals. I don't want to know about
platform specific DMA rules. I just want to be able to ask for DMA and
get told yes or no. Oops is not a useful error return.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Alan Cox]

> You cannot allocate a dma_coherent buffer without passing in the correct
> underlying device ... on parisc we'd explode trying to find the iommu to
> map through (some of our hw has more than one).

We do pass the correct underlying device. Then dma_alloc_coherent oopses
on x86_64 if you pass some valid devices (eg pcmcia). 

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pata_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]

[Alan Cox]

On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:

> 
> Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
> and for AEC6880[R] it is UDMA6 (not UDMA5):
> 
> * Fix the problem by adding missing struct ata_port_info to artop_init_one().
> 
> * Use the right naming (s/626/628/).
> 
> * Bump driver version.
> 
> Fixes IDE->libata regression, problem was never present in IDE aec62xx driver.

Have you tested this ??

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[James Bottomley]

On Thu, 2007-08-09 at 23:37 +0100, Alan Cox wrote:
> > You cannot allocate a dma_coherent buffer without passing in the correct
> > underlying device ... on parisc we'd explode trying to find the iommu to
> > map through (some of our hw has more than one).
> 
> We do pass the correct underlying device. Then dma_alloc_coherent oopses
> on x86_64 if you pass some valid devices (eg pcmcia). 

If the device you're passing has a NULL dma_mask pointer that means the
platform hasn't set it up correctly for dma ... and that's the
underlying problem (although it's not necessarily a libata problem): you
can't call dma_ operations on a device that hasn't been set up in the
platform for it.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Andi Kleen]

On Thu, Aug 09, 2007 at 11:34:58PM +0100, Alan Cox wrote:
> > Where does the device come from? What device is it?
> 
> At the higher level someone passed us a device and some mappings and
> function methods and said "this is an IDE controller"

Ok you're stabbing in the dark. I guess more debugging is needed.

> > But at least on x86-64 the device is likely DMA capable. At least
> > PCMCIA usually is.  Near all devices are DMA capable, except perhaps
> 
> PCMCIA usally isn't.

Hmm?

> I don't want to know about arch internals. I don't want to know about
> platform specific DMA rules. I just want to be able to ask for DMA and
> get told yes or no. Oops is not a useful error return.

I'm not blaming libata here, just whoever gave that bogus device to it.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL

[Alan Cox]

>  * This driver is heavily based upon:
>  *
>  * linux/drivers/ide/pci/hpt366.c   Version 0.36April 25, 2003
>  *
> reference to hpt366 version should also be updated (or removed)


Disagree - its not based on the newer hpt366 driver. Its based on the old
one. Actually by now it bears almost no resemblence any of them
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[James Bottomley]

On Fri, 2007-08-10 at 00:17 +0100, Alan Cox wrote:
> > If the device you're passing has a NULL dma_mask pointer that means the
> > platform hasn't set it up correctly for dma ... and that's the
> 
> Well it may not do DMA. 

Unfortunately, I don't think we've considered that possibility in the
integration of the dma API and generic devices.

> > underlying problem (although it's not necessarily a libata problem): you
> > can't call dma_ operations on a device that hasn't been set up in the
> > platform for it.
> 
> Right.
> 
> Ok so what is the right way given a random *correctly* set up device that
> may or may not be DMA capable to determine this. Its an arbitary device
> pointer for an arbitary device class on an arbitary platform which may or
> may not support DMA for this device class ?
> 
> Can I called dma_alloc_coherent and get a NULL back or do we need a
> device_can_dma() check in each platform ?

Fundamentally it's a different question.  The dma_alloc is just saying
can you set up a coherent memory area that this device can reach.  Often
the platform cannot necessarily discover this.  I'd say the best signal
is that the driver has called dma_set_mask(dev, DMA_MASK_NONE) (which
isn't defined yet). So the platform has a signal that the device isn't
DMA capable.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II

[Alan Cox]

> BTW unless I'm misreading the i386 code it'll not fail here, but
> allocate memory. Surely that will cause failures later if you
> rely on it failing? If you don't rely on it then changing x86-64
> will also not help you.

Eww that'll do strange things.

Ok so we do in fact need some kind of proper way to ask if a device is
DMA capable ?

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pata_cmd64x: Set up MWDMA modes properly

[Alan Cox]

On Fri, 10 Aug 2007 01:09:13 +0200 (MEST)
Mikael Pettersson <[EMAIL PROTECTED]> wrote:

> On Wed, 8 Aug 2007 14:33:20 +0100, Alan Cox wrote:
> > Set the MWDMA timing by updating the correct registers. Split the PIO
> > path as this is mostly shared code. Wants testing.
> 
> Works fine on my CMD646 SPARC Ultra5.

Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Alan Cox]

> If the device you're passing has a NULL dma_mask pointer that means the
> platform hasn't set it up correctly for dma ... and that's the

Well it may not do DMA. 

> underlying problem (although it's not necessarily a libata problem): you
> can't call dma_ operations on a device that hasn't been set up in the
> platform for it.

Right.

Ok so what is the right way given a random *correctly* set up device that
may or may not be DMA capable to determine this. Its an arbitary device
pointer for an arbitary device class on an arbitary platform which may or
may not support DMA for this device class ?

Can I called dma_alloc_coherent and get a NULL back or do we need a
device_can_dma() check in each platform ?

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pata_cmd64x: Set up MWDMA modes properly

[Mikael Pettersson]

On Wed, 8 Aug 2007 14:33:20 +0100, Alan Cox wrote:
> Set the MWDMA timing by updating the correct registers. Split the PIO
> path as this is mostly shared code. Wants testing.

Works fine on my CMD646 SPARC Ultra5.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Andi Kleen]

I'll submit a patch to check this in my next batch.

But as James pointed out you'll likely need similar patches on other
architectures.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs)

[Alan Cox]

> > At the higher level someone passed us a device and some mappings and
> > function methods and said "this is an IDE controller"
> 
> Ok you're stabbing in the dark. I guess more debugging is needed.

Huh ?

> > > But at least on x86-64 the device is likely DMA capable. At least
> > > PCMCIA usually is.  Near all devices are DMA capable, except perhaps
> > 
> > PCMCIA usally isn't.
> 
> Hmm?

PCMCIA is not DMA capable, and indeed passing a pcmcia device to AMD64
boxes dma_alloc_ functions causes an Oops.

> I'm not blaming libata here, just whoever gave that bogus device to it.

For the simple example the PCMCIA layer.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] pata_hpt37x: actually clock HPT374 by 50 MHz DPLL

[Bartlomiej Zolnierkiewicz]

On Friday 10 August 2007, Alan Cox wrote:
> >  * This driver is heavily based upon:
> >  *
> >  * linux/drivers/ide/pci/hpt366.c   Version 0.36April 25, 
> > 2003
> >  *
> > reference to hpt366 version should also be updated (or removed)
> 
> 
> Disagree - its not based on the newer hpt366 driver. Its based on the old

But this patch has just updated copyright references to match with the new
driver while the version still matches the old one!

> one. Actually by now it bears almost no resemblence any of them

Indeed, unfortunately...

Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problems while mounting /boot partition

[Jan Engelhardt]

On Aug 8 2007 18:28, Michal Piotrowski wrote:
>
>Hi Brian,
>
>Brian J. Murrell pisze:
>> I am using Ubuntu Gutsy, which is the in-development branch heading for
>> their next stable release.
>
>You forgot about message subject, so no one has read this report.

Actually, given the volume on LKML, a line without a subject is making
the most attention since all others do have one. :)


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pata_artop: fix UDMA5 for AEC6280[R] and UDMA6 for AEC6880[R]

[Bartlomiej Zolnierkiewicz]

On Friday 10 August 2007, Alan Cox wrote:
> On Thu, 9 Aug 2007 23:19:34 +0200
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
> > and for AEC6880[R] it is UDMA6 (not UDMA5):
> > 
> > * Fix the problem by adding missing struct ata_port_info to 
> > artop_init_one().
> > 
> > * Use the right naming (s/626/628/).
> > 
> > * Bump driver version.
> > 
> > Fixes IDE->libata regression, problem was never present in IDE aec62xx 
> > driver.
> 
> Have you tested this ??

-ENODEV so no and testing is welcomed.

However I went over both drivers to make sure that this change is safe
and correct.

BTW presence of the above bugs would strongly indicate that pata_artop has
never been tested (properly) with AEC6x80[R], otherwise these bugs should
have been noticed and fixed much earlier.

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II

[Andi Kleen]

BTW unless I'm misreading the i386 code it'll not fail here, but
allocate memory. Surely that will cause failures later if you
rely on it failing? If you don't rely on it then changing x86-64
will also not help you.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html