Tejun collecting libata patches this week
I'm about to disappear (virtually) through Friday for vacation. Tejun Heo has agreed to collect libata bug fix patches in my absence. Thanks! Jeff - 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: linux-ata.org contributions
Tejun Heo wrote: Jeff Garzik wrote: I wouldn't push it out unless it looked OK in my browser. But overall I tend to dislike wikis. They enable collaboration, but tend to be uniformly ugly, cumbersome, and CPU intensive. Besides collaboration, one thing I like about wikis is that updating the page is an one-step process. You can just go there and edit things directly and pages are updated and history is recorded immediately. Compared to normal web pages where you have to go through one or a few iterations of edit - view - check in if you wanna - upload / send pages, it's just more efficient. Well, I also dislike editing html pages directly and pages generated by openoffice is ugly. So, my preference is a wiki. I don't care which wiki it is as long as I can edit and view it directly. So noted, it sounds like a wiki it greatly preferred by all involved. I'll look around for one I like. Expect no action until Nov 16 at the earliest, of course... Jeff - 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: [git patches] libata fixes
Tejun Heo wrote: These are upstream patches I collected while Jeff is away. Thanks. * workaround for ATAPI tape drives * detection/suspend workarounds for several laptops * ICH8/9 port_enable fix ata_piix controller ID reorganization is included to ease the fixes. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/tj/libata-dev.git upstream-linus to receive the following updates: drivers/ata/ata_piix.c| 87 drivers/ata/libata-core.c | 100 +++--- drivers/ata/libata-eh.c | 95 --- drivers/ata/libata-scsi.c |3 - drivers/ata/pata_sis.c|1 include/linux/libata.h|5 -- 6 files changed, 81 insertions(+), 210 deletions(-) Adrian Bunk (1): libata: remove unused functions Albert Lee (2): libata: workaround DRQ=1 ERR=1 for ATAPI tape drives libata: use ATA_HORKAGE_STUCK_ERR for ATAPI tape drives Gabriel C (1): pata_sis.c: Add Packard Bell EasyNote K5305 to laptops Mark Lord (1): libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs Tejun Heo (3): ata_piix: add SATELLITE U205 to broken suspend list ata_piix: reorganize controller IDs ata_piix: port enable for the first SATA controller of ICH8 is 0xf not 0x3 Thomas Rohwer (1): ata_piix: only enable the first port on apple macbook pro Just to make sure, I pulled this into #upstream-fixes. If Linus already picked it up, great. Otherwise I'll make sure it goes upstream. Jeff - 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_ali: Add Mitac 8317 and derivatives
Alan Cox wrote: Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_ali.c linux-2.6.24-rc2-mm1/drivers/ata/pata_ali.c --- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_ali.c 2007-11-16 17:55:11.0 + +++ linux-2.6.24-rc2-mm1/drivers/ata/pata_ali.c 2007-11-16 18:12:21.0 + @@ -63,6 +63,9 @@ /* Fujitsu P2000 */ if (pdev-subsystem_vendor == 0x10CF pdev-subsystem_device == 0x10AF) return 1; + /* Mitac 8317 (Winbook-A) and relatives */ + if (pdev-subsystem_vendor == 0x1071 pdev-subsystem_device == 0x8317) + return 1; applied #upstream-fixes - 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 #upstream-fixes] sata_sil24: fix sg table sizing
Tejun Heo wrote: sil24 unnecessarily used LIBATA_MAX_PRD and ATAPI sg table was short by one entry which might cause very obscure problems. This patch updates sg table sizing such that * One full page is used for PRB + sg table. On 4k page, this results in 253 sg's. * Make ATAPI sg block properly sized. * Make build fail if command block size doesn't equal PAGE_SIZE. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- Jeff, this one is for #upstream-fixes. drivers/ata/sata_sil24.c | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) applied - 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: [PATCHSET] libata: update EH speed down logic, take #2
Tejun Heo wrote: Hello, This is the second take of update-EH-speed-down-logic patchset. Changes from the last take[1] are... * Updated to apply build against the current linus#master. Recently committed error-passthhrough-for-non-IO-command change broke build with this patchset applied. This patchset is against the current linux#master (b55d1b18). ACK patchset (I think I already did this, but just to reinforce) comments follow with next patchset response... - 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] ata.h: Don't do a SATA check for 40wire_relaxed
Alan Cox wrote: Without the valid bits at least one set of TSScorp drives report 0 in word 93 for PATA 40 wire, which we (and the specs) say actually means SATA. (The SATA version seems to report 80 wire...) Signed-off-by: Alan Cox [EMAIL PROTECTED] SATA version on what controller? Have you verified where the bridge is, if it's not reporting word93==0 ? Is this for 2.6.24-rc, considering that we are late in -rc? Jeff - 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] ata_piix: only enable the first port on apple macbook pro
Tejun Heo wrote: From: Thomas Rohwer [EMAIL PROTECTED] ICH8M on apple macbook pro occasionally locks up completely during PCS initialization if ports other than the first one are enabled. Add a separate controller ID and only enable the first port. tj: commit description added and patch updated to fit with the previous controller ID update. Signed-off-by: Thomas Rohwer [EMAIL PROTECTED] Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- applied to #tj-upstream-fixes ACK - 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 06/12] libata: separate out ata_acpi_gtm_xfermask() from pacpi_discover_modes()
Tejun Heo wrote:
Finding out matching transfer mode from ACPI GTM values is useful for
other purposes too. Separate out the function and timing tables from
pata_acpi::pacpi_discover_modes().
Other than checking shared-configuration bit after doing
ata_acpi_gtm() in pacpi_discover_modes() which should be safe, this
patch doesn't introduce any behavior change.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
---
drivers/ata/libata-acpi.c | 78 +
drivers/ata/pata_acpi.c | 66 ++---
include/linux/libata.h| 25 ++
3 files changed, 114 insertions(+), 55 deletions(-)
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 08a52dd..5ffa542 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -424,6 +424,84 @@ int ata_acpi_cbl_80wire(struct ata_port *ap)
EXPORT_SYMBOL_GPL(ata_acpi_cbl_80wire);
+/* Welcome to ACPI, bring a bucket */
+const unsigned int ata_acpi_pio_cycle[7] = {
+ 600, 383, 240, 180, 120, 100, 80
+};
+EXPORT_SYMBOL_GPL(ata_acpi_pio_cycle);
+
+const unsigned int ata_acpi_mwdma_cycle[5] = {
+ 480, 150, 120, 100, 80
+};
+EXPORT_SYMBOL_GPL(ata_acpi_mwdma_cycle);
+
+const unsigned int ata_acpi_udma_cycle[7] = {
+ 120, 80, 60, 45, 30, 20, 15
+};
+EXPORT_SYMBOL_GPL(ata_acpi_udma_cycle);
these exports seem a bit ugly
If pressed I will apply, but...
-
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 05/12] libata: xfer_mask is unsigned int not unsigned long
Jeff Garzik wrote: Tejun Heo wrote: xfer_mask is unsigned int not unsigned long. Change -mode_filter to take and return unsigned int. While at it, rename @adev of ata_pci_default_filter() to @dev for consistency. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-sff.c |5 +++-- drivers/ata/pata_acpi.c|2 +- drivers/ata/pata_ali.c |2 +- drivers/ata/pata_hpt366.c |2 +- drivers/ata/pata_hpt37x.c |4 ++-- drivers/ata/pata_pdc2027x.c|4 ++-- drivers/ata/pata_scc.c |2 +- drivers/ata/pata_serverworks.c |4 ++-- include/linux/libata.h |5 +++-- 9 files changed, 16 insertions(+), 14 deletions(-) as I noted I permit unsigned long, which is a naturally aligned machine int on our platforms. er, s/permit/prefer/ - 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: [RFC 0/3] [SCSI/libata] libata EH conversion for ipr SAS
Brian King wrote: The following three patches convert ipr to use the new libata EH APIs. In the process of doing this, I first looked into implementing this in a similar manner to how libata SAS is done today, which is hooking into target_alloc/target_destroy to allocate/delete sata ports. While I was able to get this working after writing my own eh_strategy_handler, I was doubtful this was the best long term solution. One problem with this implementation I didn't solve was the fact that libata now invokes EH for each and every error received. For some devices, such as optical devices, each not ready response received during a media reload would result in all the attached SAS devices getting quiesced as well. My second approach is the attached patch set. In this series I have created a new libata API which can be used by SAS LLDDs. It introduces an ata_sas_rphy device object which is created/destroyed by the following API: ata_sas_rphy_alloc ata_sas_rphy_add ata_sas_rphy_delete When using this API in ipr, I made ipr's scsi_host the parent device of the SATA rphy. The SATA rphy is then the parent of the allocated scsi_hosts. This means that each SATA rphy in the SAS topology will have its own scsi_host, making SAS *much* more like all the SATA LLDDs in how it uses libata. The only issue I ran into with this implementation is that since each SATA port has its own scsi_host, the adapter cannot rely on scsi core to manage any LLDD or adapter imposed queue depth. To solve this I added some code to ipr. Longer term, block layer queue groups might be another way to do this. I'm still polishing this up, but it is up and running and seems to work with what testing I've done so far. I'm generally happy with this, though I am curious what Tejun thinks as well. Once everybody is happy, I think we should collect libata ACKs and then push this via the SCSI maintainership route. That would libsas work in parallel, with perhaps in situ tweaks and fixes as the implementation is fleshed out. Jeff - 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] ata_piix: port enable for the first SATA controller of ICH8 is 0xf not 0x3
Tejun Heo wrote: ICH8 and 9 use two SFF controllers to show 6 SATA ports. The first controllre hosts the first 4 ports while the second one hosts the last 2. The PCS register of the first controller encompasses the first four ports or all six ports depending on configuration while PCS of the second controller controls the last two ports. Using 0xf for the first controller and 0x3 for the second controller always result in the correct configuration. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- applied to #tj-upstream-fixes ACK - 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: [PATCHSET] libata: update timing and fix pata_amd transfer mode selection
Tejun Heo wrote: Hello, This patchset cleans up and improves PATA timing related code and fix pata_amd transfer mode selection on top of the improvements. This patchset contains the following tweleve patches. 0001-ata_generic-unindent-loop-in-generic_set_mode.patch 0002-libata-export-xfermode-PATA-timing-related-functi.patch 0003-libata-clean-up-xfermode-PATA-timing-related-stuf.patch 0004-libata-kill-ata_id_to_dma_mode.patch 0005-libata-xfer_mask-is-unsigned-int-not-unsigned-long.patch 0006-libata-separate-out-ata_acpi_gtm_xfermask-from-pa.patch 0007-libata-fix-ata_acpi_gtm_xfermask.patch 0008-libata-implement-ata_timing_cycle2mode-and-use-it.patch 0009-libata-implement-ata_acpi_init_gtm.patch 0010-libata-reimplement-ata_acpi_cbl_80wire-using-ata_.patch 0011-libata-add-ATA_CBL_PATA_IGN.patch 0012-pata_amd-update-mode-selection-for-NV-PATAs.patch 0001-0005 are clean ups of timing handling code. 0006-0008 unifies timing handling code in libata-acpi.c and pata_acpi.c with the core timing code. 0009 implements initial GTM caching. I thought about moving this to LLDs but it's too much hassle. GTM is host wide and doing it from -error_handler would require cross-port synchronization. Left alternative is adding a separate hook. Simply doing it during ACPI attach is simpler. 0010 reimplements ata_acpi_cbl_80wire() using ata_acpi_gtm_xfermask(). This new function takes @gtm argument. Both users (pata_via and pata_amd) are converted to pass initial GTM. 0011 implements ATA_CBL_PATA_IGN which tells libata to ignore cable type and supporess all related handling. 0012 updates mode selection for NV PATA controllers. We just can't tell what cable is attached on the controller either from host or drive side. So, for those controllers, pata_amd just sets cable type to ATA_CBL_PATA_IGN and use -mode_filter to limit transfer mode according to BIOS/ACPI boot configuration. If that fails (not likely), pata_amd simply sets the highest allowed speed and let EH figure out the mess. With recent updates, EH should be able to figure it out pretty soon. overall this seems pretty sane... but I lean towards applying it in 2.6.25 rather than 2.6.24, since we are fairly deep into 2.6.24-rc at this point, with little time to test these and the speed down changes to ensure no last-minute breakage. - 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 05/12] libata: xfer_mask is unsigned int not unsigned long
Tejun Heo wrote: xfer_mask is unsigned int not unsigned long. Change -mode_filter to take and return unsigned int. While at it, rename @adev of ata_pci_default_filter() to @dev for consistency. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-sff.c |5 +++-- drivers/ata/pata_acpi.c|2 +- drivers/ata/pata_ali.c |2 +- drivers/ata/pata_hpt366.c |2 +- drivers/ata/pata_hpt37x.c |4 ++-- drivers/ata/pata_pdc2027x.c|4 ++-- drivers/ata/pata_scc.c |2 +- drivers/ata/pata_serverworks.c |4 ++-- include/linux/libata.h |5 +++-- 9 files changed, 16 insertions(+), 14 deletions(-) as I noted I permit unsigned long, which is a naturally aligned machine int on our platforms. Consistency patches in the other direction (moving ATA_MASK_* to a separate enum and marking with UL suffix) are welcome. - 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_ninja32: Cardbus ATA initial support
Alan Cox wrote: Lots of work needed to bring it up to scratch but it does work so you can now use the card. That makes it at least useful, especially as the other cardbus cards are usually INIC162x which aren't yet supported well. Signed-off-by: Alan Cox [EMAIL PROTECTED] applied #upstream - 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_ali: Lots of problems still showing up with small ATAPI DMA
Alan Cox wrote: Hopefully there is a better long term solution but for now lets favour reliability. Signed-off-by: Alan Cox [EMAIL PROTECTED] applied #upstream-fixes - 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] libata: IORDY handling
Alan Cox wrote: I believe this version meets all Sergei's objections Correct the logic for when we issue a set features for transfer mode - If the device has IORDY and the controller has IORDY - set the mode - If the device has IORDY and the controller does not - turn IORDY off - If neither has IORDY do nothing Signed-off-by: Alan Cox [EMAIL PROTECTED] applied #upstream - 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_jmicron: fix disabled port handling in jmicron_pre_reset()
Tejun Heo wrote: There are two bugs in disabled port handling. * test in PORT_PATA0 is reversed * -prereset should return -ENOENT for disabled ports not 0 The first bug makes the PATA channel considered disabled but the second bug saves the day by returning 0. The net result is that cable is always left at ATA_CBL_UNKNOWN. This results in false 80c configuration and thus transfer errors. This patch fixes both bugs. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- applied to #tj-upstream-fixes. drivers/ata/pata_jmicron.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) applied - 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_sil680: kill bogus reset code (take 2)
Sergei Shtylyov wrote: Since writing to two reserved bits ain't much of a housekeeping, I think it's time we get rid of the custom error handler in this driver. ;-) Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED] --- Oops, somehow I've managed to send a stale patch, without a version change... This code has been discussed 4 months ago, and is still in the same state. :-| The patch is against the Linus' tree... drivers/ata/pata_sil680.c | 32 ++-- 1 files changed, 2 insertions(+), 30 deletions(-) applied - 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] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote: Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask unconditionally, but for non-ATA_PROT_DMA commands (which includes all ATAPI), it just falls back to ata_qc_issue_prot which issues via the legacy SFF interface and can only handle 32-bit addressing. So yes, it appears to have a similar bug as sata_nv had. sata_mv doesn't do ATAPI at all... Jeff - 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] libata-sff: tf_load
Alan Cox wrote:
Jeff said he preferred that the SFF tf_load followed the spec and we
documented that anyone who needed different overrode it, rather than it
using the -check_status methods. No driver relies on the current behaviour.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc2-mm1/drivers/ata/libata-sff.c
linux-2.6.24-rc2-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/libata-sff.c 2007-11-16
17:55:11.0 +
+++ linux-2.6.24-rc2-mm1/drivers/ata/libata-sff.c 2007-11-16
18:11:51.0 +
@@ -147,7 +147,9 @@
* @tf: ATA taskfile register set for storing input
*
* Reads ATA taskfile registers for currently-selected device
- * into @tf.
+ * into @tf. Assumes the device has a fully SFF compliant task file
+ * layout and behaviour. If you device does not (eg has a different
+ * status method) then you will need to provide a replacement tf_read
*
* LOCKING:
* Inherited from caller.
@@ -156,7 +158,7 @@
{
struct ata_ioports *ioaddr = ap-ioaddr;
- tf-command = ata_chk_status(ap);
+ tf-command = ata_check_status(ap);
applied #upstream, 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: [PATCH] pata_pcmcia: Minor cleanups and support for dual channel cards
Alan Cox wrote:
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c
linux-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c
--- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c 2007-11-16
17:55:11.0 +
+++ linux-2.6.24-rc2-mm1/drivers/ata/pata_pcmcia.c 2007-11-16
18:18:38.0 +
@@ -42,7 +42,7 @@
#define DRV_NAME pata_pcmcia
-#define DRV_VERSION 0.3.2
+#define DRV_VERSION 0.3.3
/*
* Private data structure to glue stuff together
@@ -198,7 +198,6 @@
/**
* pcmcia_init_one - attach a PCMCIA interface
* @pdev: pcmcia device
- * @ops: operations for this device
*
* Register a PCMCIA IDE interface. Such interfaces are PIO 0 and
* shared IRQ.
@@ -217,9 +216,10 @@
cistpl_cftable_entry_t dflt;
} *stk = NULL;
cistpl_cftable_entry_t *cfg;
- int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM;
+ int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM, p;
unsigned long io_base, ctl_base;
void __iomem *io_addr, *ctl_addr;
+ int n_ports = 1;
struct ata_port_operations *ops = pcmcia_port_ops;
@@ -348,7 +348,7 @@
/* FIXME: Could be more ports at base + 0x10 but we only deal with
one right now */
if (pdev-io.NumPorts1 = 0x20)
- printk(KERN_WARNING DRV_NAME : second channel not yet
supported.\n);
+ n_ports = 2;
if (pdev-manf_id == 0x0097 pdev-card_id == 0x1620)
ops = pcmcia_8bit_port_ops;
@@ -357,20 +357,23 @@
* sane.
*/
ret = -ENOMEM;
- host = ata_host_alloc(pdev-dev, 1);
+ host = ata_host_alloc(pdev-dev, n_ports);
if (!host)
goto failed;
- ap = host-ports[0];
- ap-ops = ops;
- ap-pio_mask = 1;/* ISA so PIO 0 cycles */
- ap-flags |= ATA_FLAG_SLAVE_POSS;
- ap-ioaddr.cmd_addr = io_addr;
- ap-ioaddr.altstatus_addr = ctl_addr;
- ap-ioaddr.ctl_addr = ctl_addr;
- ata_std_ports(ap-ioaddr);
+ for (p = 0; p n_ports; p++) {
+ ap = host-ports[p];
- ata_port_desc(ap, cmd 0x%lx ctl 0x%lx, io_base, ctl_base);
+ ap-ops = ops;
+ ap-pio_mask = 1;/* ISA so PIO 0 cycles */
+ ap-flags |= ATA_FLAG_SLAVE_POSS;
+ ap-ioaddr.cmd_addr = io_addr + 0x10 * p;
+ ap-ioaddr.altstatus_addr = ctl_addr + 0x10 * p;
+ ap-ioaddr.ctl_addr = ctl_addr + 0x10 * p;
+ ata_std_ports(ap-ioaddr);
a bit of coordination confusion here...
This patch requires
commit 33a2d9226557c298a5df13b95bd31b8b1d749918
Author: Alan Cox [EMAIL PROTECTED]
Date: Mon Oct 15 20:44:11 2007 +0100
pata_pcmcia: Add support for dumb 8bit IDE emulations
found in #for-testing. Should that patch be promoted to #upstream
(queued for 2.6.25), and then this patch applied on top, also in #upstream?
If you're curious, here is the current content of #for-testing
(attached). You need to poke me to move stuff from #for-testing to
#upstream, since I dropped it into #for-testing at your direction.
(for other readers, #for-testing is a branch always merged into #ALL and
thus -mm)
Jeff
Alan Cox (4):
libata: fix (hopefully) all the remaining problems with devices failing
setup/identify
pata_pcmcia: Add support for dumb 8bit IDE emulations
libata-core: Don't have screaming fits over DF/ERR combinations
libata/pata_it821x: Improve handling of poorly compatible emulations
drivers/ata/libata-core.c | 61 ---
drivers/ata/pata_it821x.c | 35 +-
drivers/ata/pata_pcmcia.c | 71 +-
3 files changed, 147 insertions(+), 20 deletions(-)
Re: [PATCH] ahci: Invalid use of writel/readl with iomap
Alan Cox wrote: Should use ioread* as discussed previously Signed-off-by: Alan Cox [EMAIL PROTECTED] applied to #upstream-fixes, after s/ahci/ata_piix/ in subject line - 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] libata-core: List more documentation sources for reference
Alan Cox wrote: And next time I'll be able to find the ata tape spec easily... Signed-off-by: Alan Cox [EMAIL PROTECTED] applied #upstream-fixes - 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_hpt37x: Fix cable detect bug spotted by Sergei
Alan Cox wrote: Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c linux-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c --- linux.vanilla-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c 2007-11-16 17:55:11.0 + +++ linux-2.6.24-rc2-mm1/drivers/ata/pata_hpt37x.c 2007-11-16 18:14:19.0 + @@ -329,7 +329,7 @@ /* Restore state */ pci_write_config_byte(pdev, 0x5B, scr2); - if (ata66 (1 ap-port_no)) + if (ata66 (2 ap-port_no)) ap-cbl = ATA_CBL_PATA40; applied #upstream-fixes - 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 #upstream] ahci: update PCS programming
Tejun Heo wrote: For intel ones, ahci unconditionally OR'd 0xf to PCS. This isn't correct for the following cases. * ich6/7m's which only implement P0 and P2 (0xf works fine tho) * ich8/9's which have six ports and needs 0x3f to enable all ports This patch updates PCS programming such that... * port_map determined by ahci_save_initial_config() is OR'd instead of 0xf * PCS is updated only if necessary (there are turned off enable bits) port_map is determined from PORTS_IMPL PCI register which is implemented as write or write-once register. If the register isn't programmed, ahci automatically generates it from number of ports, which is good enough for PCS programming. ICH6/7M are probably the only ones where non-contiguous enable bits are necessary PORTS_IMPL isn't programmed properly but they're proven to work reliably with 0xf anyway. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- As there hasn't been any report of brokeness due to this, I think this change can wait and get tested till the next merge cycle. The reason why this doesn't really break anything (yet) is that BIOS programs PCS correctly during boot and the value is preserved over suspend-to-ram, which is interesting considering the default value for PCS is zero. Maybe SMM code reprograms it while resuming? drivers/ata/ahci.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) applied - 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 07/12] libata: fix ata_acpi_gtm_xfermask()
Tejun Heo wrote: ata_acpi_gtm_xfermask() as separated out from pacpi_discover_modes() has various bugs. Fix them. * The wrong comparison operator is used when finding for matching cycle resulting totally bogus result. * With the comparion operator fixed, boundary condtion handling is clumsy. * Setting of any DMA mask bit set all bits in PIO mask. * MWDMA and UDMA blocks are swapped. shouldn't this be combined with patch #6? - 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] ata_piix: reorganize controller IDs
Tejun Heo wrote:
Move piix_pata_mwdma to top, rename ich9_2port_sata to ich8_2port_sata
for consistency and use automatically incremented values instead of
assigning fixed values to ease adding new controller IDs.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
applied to #tj-upstream-fixes.
drivers/ata/ata_piix.c | 62
1 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 80b735b..77fea05 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -119,18 +119,18 @@ enum {
PIIX_80C_SEC= (1 7) | (1 6),
/* controller IDs */
- piix_pata_33= 0,/* PIIX4 at 33Mhz */
- 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 */
- ich5_sata = 5,
- ich6_sata = 6,
- ich6_sata_ahci = 7,
- ich6m_sata_ahci = 8,
- ich8_sata_ahci = 9,
- piix_pata_mwdma = 10, /* PIIX3 MWDMA only */
- tolapai_sata_ahci = 11,
- ich9_2port_sata = 12,
+ piix_pata_mwdma = 0,/* PIIX3 MWDMA only */
+ piix_pata_33, /* PIIX4 at 33Mhz */
+ ich_pata_33,/* ICH up to UDMA 33 only */
+ ich_pata_66,/* ICH up to 66 Mhz */
+ ich_pata_100, /* ICH up to UDMA 100 */
+ ich5_sata,
+ ich6_sata,
+ ich6_sata_ahci,
+ ich6m_sata_ahci,
+ ich8_sata_ahci,
+ ich8_2port_sata,
+ tolapai_sata_ahci,
When using automatically filled values, please move to a separate and
distinct enum...
ACK everything else
Jeff
-
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 #upstream-fixes] libata: bump transfer chunk size if it's odd
Tejun Heo wrote: None of the drives I have follows what the standard says about transfer chunk size. Of the four SATA and six PATA ATAPI devices tested, four ignore transfer chunk size completely and the ones which honor it don't behave according to the spec when it's odd. According to the spec, transfer chunk size can be odd if the amount of data to transfer equals or is smaller than the chunk size and the device can indicate the same odd number and transfer the whole thing at one go with a pad byte appended. However, in reality, none of the drives I have does that. They all indicate and transfer even number of bytes one byte shorter than the chunk size first; then indicate and transfer two bytes, which is clearly out of spec. In addition to unnecessary second PIO data phase, this also creates a weird problem when combined with SATA controllers which perform PIO via DMA. Some of these controllers use actualy number of bytes received to update DMA pointer so chunks which are sized 4n + 2 makes DMA pointer off by two bytes. This causes data corruption and buffer overruns. This patch rounds nbytes up to the nearest even number such that ATAPI devices don't split data transfer for the last odd byte. This shouldn't confuse controllers which depend on transfer chunk size as devices will report the rounded-up number, actually transfer that much and padding buffer is there to receive them. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - 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] [libata] Return proper ATA INT status in pata_bf54x driver.
sonic zhang wrote: INT status can be OR. Signed-off-by: Sonic Zhang [EMAIL PROTECTED] --- drivers/ata/pata_bf54x.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) applied - 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
[git patches] libata fixes
NOTE: This includes 100% of the fixes collected during the week I
was on vacation, by Tejun... rebased. So all the commit ids are
different from his push.
If you have not pulled from Tejun, then pull this.
If you have pulled from Tejun, then do not pull this (I will rebase once
Tejun's pull is pushed out).
Other notes: I have a sata_nv ATAPI fix that needs to go in too, should
push that in the next push (day or two).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c | 93 ++
drivers/ata/libata-core.c | 108 ++--
drivers/ata/libata-eh.c| 95 --
drivers/ata/libata-scsi.c | 38 ++--
drivers/ata/pata_ali.c | 20
drivers/ata/pata_bf54x.c |6 +-
drivers/ata/pata_hpt37x.c |2 +-
drivers/ata/pata_isapnp.c | 11 +++--
drivers/ata/pata_jmicron.c |9 ++--
drivers/ata/pata_sil680.c | 32 +
drivers/ata/pata_sis.c |1 +
drivers/ata/sata_sil24.c | 26 +-
include/linux/libata.h |5 +--
13 files changed, 184 insertions(+), 262 deletions(-)
Adrian Bunk (1):
libata: remove unused functions
Alan Cox (6):
ata_piix: Invalid use of writel/readl with iomap
libata-core: List more documentation sources for reference
pata_ali: Add Mitac 8317 and derivatives
pata_ali: Lots of problems still showing up with small ATAPI DMA
pata_hpt37x: Fix cable detect bug spotted by Sergei
pata_isapnp: Polled devices
Albert Lee (2):
libata: workaround DRQ=1 ERR=1 for ATAPI tape drives
libata: use ATA_HORKAGE_STUCK_ERR for ATAPI tape drives
Gabriel C (1):
pata_sis.c: Add Packard Bell EasyNote K5305 to laptops
Jeff Garzik (1):
pata_ali: trim trailing whitespace (fix checkpatch complaints)
Mark Lord (1):
libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs
Sergei Shtylyov (1):
pata_sil680: kill bogus reset code (take 2)
Tejun Heo (6):
ata_piix: add SATELLITE U205 to broken suspend list
ata_piix: reorganize controller IDs
ata_piix: port enable for the first SATA controller of ICH8 is 0xf not 0x3
pata_jmicron: fix disabled port handling in jmicron_pre_reset()
sata_sil24: fix sg table sizing
libata: bump transfer chunk size if it's odd
Thomas Rohwer (1):
ata_piix: only enable the first port on apple macbook pro
sonic zhang (1):
libata: Return proper ATA INT status in pata_bf54x driver
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 328ce8a..483269d 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -119,18 +119,19 @@ enum {
PIIX_80C_SEC= (1 7) | (1 6),
/* controller IDs */
- piix_pata_33= 0,/* PIIX4 at 33Mhz */
- 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 */
- ich5_sata = 5,
- ich6_sata = 6,
- ich6_sata_ahci = 7,
- ich6m_sata_ahci = 8,
- ich8_sata_ahci = 9,
- piix_pata_mwdma = 10, /* PIIX3 MWDMA only */
- tolapai_sata_ahci = 11,
- ich9_2port_sata = 12,
+ piix_pata_mwdma = 0,/* PIIX3 MWDMA only */
+ piix_pata_33, /* PIIX4 at 33Mhz */
+ ich_pata_33,/* ICH up to UDMA 33 only */
+ ich_pata_66,/* ICH up to 66 Mhz */
+ ich_pata_100, /* ICH up to UDMA 100 */
+ ich5_sata,
+ ich6_sata,
+ ich6_sata_ahci,
+ ich6m_sata_ahci,
+ ich8_sata_ahci,
+ ich8_2port_sata,
+ ich8m_apple_sata_ahci, /* locks up on second port enable */
+ tolapai_sata_ahci,
/* constants for mapping table */
P0 = 0, /* port 0 */
@@ -239,19 +240,21 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* SATA Controller 1 IDE (ICH8) */
{ 0x8086, 0x2820, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
/* SATA Controller 2 IDE (ICH8) */
- { 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich9_2port_sata },
+ { 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* Mobile SATA Controller IDE (ICH8M) */
{ 0x8086, 0x2828, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+ /* Mobile SATA Controller IDE (ICH8M), Apple */
+ { 0x8086, 0x2828, 0x106b, 0x00a0, 0, 0, ich8m_apple_sata_ahci },
/* SATA Controller IDE (ICH9) */
{ 0x8086, 0x2920, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
/* SATA Controller IDE (ICH9) */
- { 0x8086
Flexible SFF interrupt handling
This has been bubbling on my brain for a while. I blathered on about this on IRC to Tejun, but figured I might as well post it here and get it archived. In general, I think we should adopt a flexible or loose model for acking interrupts on SFF controllers. (a) whenever we are in bus-idle (qc == NULL), and get an interrupt, go ahead and read Status. (b) if we are expecting an interrupt, and receive one, check Status (or AltStatus if DMAing). (c) if condition (b) indicates busy, initiate status polling every 250ms until timeout occurs or BSY clears. (d) if N seconds (4?) elapses without an interrupt, initiate polling. keep a history of such fail-over events, and note each fail-over'd command's eventual success via polling, success via interrupt, or timeout. Use that history to decide to switch to 100% polling mode (i.e. reach conclusion that interrupt delivery is broken, via observation) That should cover no-interrupts, lost interrupts, early interrupts, screaming interrupts, insane devices, and of course normal operation. The model could be summarized as interrupt as a hint operation. Jeff - 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: Flexible SFF interrupt handling
Mark Lord wrote: Jeff Garzik wrote: This has been bubbling on my brain for a while. I blathered on about this on IRC to Tejun, but figured I might as well post it here and get it archived. In general, I think we should adopt a flexible or loose model for acking interrupts on SFF controllers. (a) whenever we are in bus-idle (qc == NULL), and get an interrupt, go ahead and read Status. (b) if we are expecting an interrupt, and receive one, check Status (or AltStatus if DMAing). (c) if condition (b) indicates busy, initiate status polling every 250ms until timeout occurs or BSY clears. (d) if N seconds (4?) elapses without an interrupt, initiate polling. keep a history of such fail-over events, and note each fail-over'd command's eventual success via polling, success via interrupt, or timeout. Use that history to decide to switch to 100% polling mode (i.e. reach conclusion that interrupt delivery is broken, via observation) That should cover no-interrupts, lost interrupts, early interrupts, screaming interrupts, insane devices, and of course normal operation. The model could be summarized as interrupt as a hint operation. .. The only question is, under which conditions do we return IRQ handled=1, and which times should we return 0 ? Definitely when a real IRQ wakes us up and we see (qc != NULL drive_ready), essentially exactly as we currently do it. But things might be trickier once polling is introduced, unless we also mask the device interrupt before initiating the polling. Actually no, and that is a key benefit of this scheme: if we ensure that the polling paths are resilient even in case where interrupts are being delivered -- as we must do anyway -- then we don't have to worry about interrupt masking, either on the interrupt controller or on the device[1]. If we do get an interrupt, ack it ASAP. That covers normal operation and screaming interrupts. If we don't get an interrupt, we will notice after a spell and poll Status to ensure progress occurs. Note that this polling is a different sort of polling than running an entire ATA command via a kernel thread. In this case, we're talking about periodic Status (or AltStatus or LLD-specific-register status) polling only. A lot of fiddling with irq masking is getting around ugliness that I am instead trying to eliminate altogether. A truly robust system follows the spec WRT nIEN and other interrupt masking. but then prepares for the case where hw decides to send an interrupt anyway. On SFF controllers, we should consider interrupts to be unreliable messages delivered on a best effort basis by hardware. If we get them, great, ack and act. If we lack them, make sure progress occurs. Regards, Jeff [1] well, there -are- exceptions, such as when we are bitbanging the ATA Data register - 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: sata_mv fixes: coding style preference?
Mark Lord wrote: Jeff: This fix (one I reissue it) should go upstream for 2.6.24, if possible. Fine by me... Jeff - 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: Flexible SFF interrupt handling
Alan Cox wrote: In general, I think we should adopt a flexible or loose model for acking interrupts on SFF controllers. Agreed - especially as the IRQ is often essentially the drive output not under any kind of sane control of ours. Good point (I had not thought of looking at it that way). (a) whenever we are in bus-idle (qc == NULL), and get an interrupt, go ahead and read Status. Please call into the driver. Quite a few PATA drivers have multiple IRQ sources, and SATA many. Done :) This should simply be a new behavior coded into the existing interrupt handlers. Thus you can choose per-driver whether to do this or not. (b) if we are expecting an interrupt, and receive one, check Status (or AltStatus if DMAing). Providing we are not mid data transfer (which is why we need to get into enable/disable_irq for some controllers). Right now its a problem that can't occur but on some controllers reading status mid PIO xfer causes joyous things like silent corruption. True.. (c) if condition (b) indicates busy, initiate status polling every 250ms until timeout occurs or BSY clears. Yep. (d) if N seconds (4?) elapses without an interrupt, initiate polling. keep a history of such fail-over events, and note each fail-over'd command's eventual success via polling, success via interrupt, or timeout. Use that history to decide to switch to 100% polling mode (i.e. reach conclusion that interrupt delivery is broken, via observation) N = 8 sounds good to me (7 being the normal maximum command timeout) That should cover no-interrupts, lost interrupts, early interrupts, screaming interrupts, insane devices, and of course normal operation. Should we also consider resetting the device as one of the strategies (at least once off) Might also want to think at that point about the case of command timeout where old IDE checks with the controller to spot lost IRQ cases where a command finished and stuff vanished. Old IDE doesn't do much with it but we could use that as a good hint that we want to switch to polling mode and tell the user their computer sucks. That's basically where I wanted to go with (d). Being able to both handle interrupts _and_ fall back to polling makes it easy to notice when interrupts are getting lost. If more than a couple rescues of this nature occur, do as you describe. Jeff - 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 05/14] libata: make -data_xfer return the number of consumed bytes
Alan Cox wrote: DMA alignment is host restriction so I think it belongs to ata_host if we ever need it. Do you know of any controller which require such thing? No need to add complexity when it's not necessary. If we ever get the blasted inic162x working then that appears to have some alignment limits. At least the docs say the DMA buffers must be quad word aligned and sized (although it doesn't describe what occurs if the total length of xfer disagrees with the buffers) Most DMA has alignment limits, for the front not the back of the buffer. Jeff - 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 05/14] libata: make -data_xfer return the number of consumed bytes
Mark Lord wrote: Alan Cox wrote: DMA alignment is host restriction so I think it belongs to ata_host if we ever need it. Do you know of any controller which require such thing? No need to add complexity when it's not necessary. If we ever get the blasted inic162x working then that appears to have some alignment limits. At least the docs say the DMA buffers must be quad word aligned and sized (although it doesn't describe what occurs if the total length of xfer disagrees with the buffers) ... If it's an ADMA device, then they may support bits in the CPB to direct what should happen for various overrun/underrun conditions. Yeah most devices that are not strictly SFF (i.e. have a real register space) are like that. Jeff - 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 14/14] libata: use PIO for misc ATAPI commands
Tejun Heo wrote: Alan Cox wrote: polling for media change which involves reading maybe a few tens of bytes. The overhead of doing those using PIO wouldn't be too much more than the cost of writing CDBs out. It would help more if we can cut down the number of commands used for testing media changed event (on my to do list). Actually the overhead is foul on some laptops as the command byte write wakes up the controller, which then whirrs away for a bit recovering its status before deciding to give us an answer. Yeah, but that happens whether DMA is used or not. Probably what's needed is disabling media presence polling according to power profile. Does module parameter / sysfs node sound good enough to you? You mean like the existing dma one we already have which lets you turn on/off atapi DMA and could be extended with another bit so we went from 1 - disk 2 - cd 4 - cf to 1 - disk 2 - cd (basic commands) 4 - cf 8 - cd (all) (The idea being that its ordered so troubleshooting almost always comes down to 1,3 - or 1,3,7 with this). So we have 99.9% of this Basically, yes but I think it would be nice to be able to change the value on the fly. It would also be nice to change it per-device rather than globally... Jeff - 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: SAS v SATA interface performance
Mark Lord wrote: SATA port multipliers (think, hub) permit multiple drives to be active simultaneously. Quite true, although the host controller could artificially limit this, giving the user a mistaken impression of their port multiplier being limited to one-command-per-N-drives. /nit pick :) Jeff - 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] [libata] sata_mv: fix compilation error when enabling DEBUG
Saeed Bishara wrote: From: Saeed Bishara [EMAIL PROTECTED] use sstatus instead status. Signed-off-by: Saeed Bishara [EMAIL PROTECTED] --- drivers/ata/sata_mv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index a43f64d..97c3e11 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -2170,7 +2170,7 @@ static void mv_phy_reset(struct ata_port *ap, unsigned int *class, mv_scr_read(ap, SCR_ERROR, serror); mv_scr_read(ap, SCR_CONTROL, scontrol); DPRINTK(S-regs after ATA_RST: SStat 0x%08x SErr 0x%08x - SCtrl 0x%08x\n, status, serror, scontrol); + SCtrl 0x%08x\n, sstatus, serror, scontrol); applied #upstream-fixes - 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/1] Several fixes for the AVR32 PATA driver
Kristoffer Nyborg Gregertsen wrote: Several fixes for the AVR32 PATA driver: * Updated to use new AVR32 SMC timing API. This removes the need for magic constants in signal timing. * Removed the ATA_FLAG_PIO_POLLING, the driver should use interrupts. * Removed .port_disable and .irq_ack as these are no longer needed. * Improved some comments. Signed-off-by: Kristoffer Nyborg Gregertsen [EMAIL PROTECTED] applied #upstream-fixes - 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] libata: report protocol and full CDB on error
Tejun Heo wrote: Protocol and CDB allocation size field are important in determining what went wrong with ATAPI commands. Report them on failure. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- This one is for #upstream-fixes. Thanks. nod, applied - 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: sata_mv: Fix broken Marvell 7042 support. The Marvell 7042 chip is more or less the same as the 6042 internally, but sports a PCIe bus. Despite having identical SATA cores, the 7042 does differ from its PCI bus counterparts in placment and layout of certain bus related registers. This patch fixes sata_mv to distinguish between the PCI bus registers of earlier chips, and the PCIe bus registers of the 7042. Specifically, move the offsets and bit patterns for the PCI/PCIe interrupt cause/mask registers into the struct mv_host_priv, as these values differ between the 6xxx and 7xxx series chips. This fixes the driver to not access reserved PCI addresses, and prevents the lockups reported in linux-2.6.24 with 7042 boards. Also add a new PCI ID for the Highpoint 2300 7042-based board that I'm using for testing this stuff here. Tested with Marvell 6081 + 7042 chips, on x86 x86_64. Signed-off-by: Mark Lord [EMAIL PROTECTED] applied #upstream-fixes - 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 #upstream-fixes] ata_piix: add more toshiba laptops to broken suspend list
Tejun Heo wrote: From: Peter Schwenke [EMAIL PROTECTED] Add more toshiba laptops to broken suspend list. This is from OSDL bugzilla bug 7780. tj: re-formatted patch and added description and SOB. Signed-off-by: Peter Schwenke [EMAIL PROTECTED] Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- This one is for #upstream-fixes -stable. I'll push it to Greg once it gets to Linus's tree. Thanks. drivers/ata/ata_piix.c | 28 1 file changed, 28 insertions(+) applied #upstream-fixes - 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/8] libata: implement protocol tests
Tejun Heo wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 5eb5983..8d5cd16 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5969,7 +5946,7 @@ void ata_qc_issue(struct ata_queued_cmd *qc)
*/
WARN_ON(ap-ops-error_handler ata_tag_valid(link-active_tag));
- if (qc-tf.protocol == ATA_PROT_NCQ) {
+ if (prot == ATA_PROT_NCQ) {
WARN_ON(link-sactive (1 qc-tag));
if (!link-sactive)
missed one?
-
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 4/8] libata: move ata_set_mode() to libata-eh.c
Tejun Heo wrote: Move ata_set_mode() to libata-eh.c. ata_set_mode() is surely an EH action and will be more tightly coupled with the rest of error handling. Move it to libata-eh.c. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Does this mean SET FEATURES - XFER MODE via SG_IO will be possible soon? ;-) - 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 8/8] libata: implement fast speed down for unverified data transfer mode
Tejun Heo wrote: It's very likely that the configured data transfer mode is the wrong one if device fails data transfers right after initial data transfer mode configuration (including NCQ on/off and xfermode). libata EH needs to speed down fast before upper layers give up on probing. This patch implement fast speed down rules to handle such cases better. Error occured while data transfer hasn't been verified trigger fast back-to-back speed down actions until data transfer works. This change will make cable mis-detection and other initial configuration problems corrected before partition scanning code gives up. Signed-off-by: Tejun Heo [EMAIL PROTECTED] I agree strongly. Good work! - 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 0/3] OF-platform PATA driver
Anton Vorontsov wrote:
Hi all,
Here is the second spin of the OF-platform PATA driver and
related patches.
Changes since RFC:
- nuked drivers/ata/pata_platform.h;
- powerpc bits: proper localbus node added.
Thanks for the previous review! This time I'm collecting acks,
don't be shy to give 'em generously. ;-)
if (ack_collected(PaulM))
push(ACK)
else {
/* do nothing */
}
-
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/8] libata: rearrange ATA_DFLAG_*
Tejun Heo wrote: Area for DFLAGs which are cleared on INIT is full. Extend it by 8 bits. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- include/linux/libata.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) applied 1-8 to #upstream - 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 12/12] pata_amd: update mode selection for NV PATAs
Tejun Heo wrote: Cable detection on NV PATA hosts isn't implemented and the CBLID- cable isn't wired according to the sepc either, so both host-side and generic drive-side cable detections are broken. Till now, nv_cable_detect() relied on peeking BIOS and ACPI configurations to upgrade to 80C but this often results in misdetection of 40C cable as 80C. Also, the original implementation was broken in that by the time BIOS configuration is read it has already been cleared by programming PIO0 during reset. This patch reimplements NV mode selection such that... * BIOS configuration value is stored during driver attach and restored on detach. * Cable type is fixed to ATA_CBL_PATA_IGN and mode selection is soley done by nv_mode_filter() which peeks both BIOS and ACPI configurations and filter accordingly. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Alan Cox [EMAIL PROTECTED] --- drivers/ata/pata_amd.c | 129 ++- 1 files changed, 93 insertions(+), 36 deletions(-) Yeah, I think this is a better way to do things long term. 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: [PATCH RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
Tejun Heo wrote: Make pdc_atapi_pkt() use values from qc-tf instead of creating its own. This is to ease future ATAPI handling changes. DONT APPLY YET --- Mikael, would this work? Values other than lbam and lbah remain the same. Does sata_promise have strict requirements for lbam and lbah? Thanks. drivers/ata/sata_promise.c | 34 +- 1 file changed, 13 insertions(+), 21 deletions(-) what was the outcome of this discussion? I haven't looked over the Promise datasheet nor checked my brain for details, hoping Mikael would do that for me ;-) - 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] ata: ahci: Enclosure Management via LED rev2
Kristen Carlson Accardi wrote: Enclosure Management via LED This patch implements Enclosure Management via the LED protocol as specified in AHCI specification. Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED] --- This revision makes the change to the comment requested by Mark Lord, fixes some bugs in the bit shifting for writing the new led state, and implements a show function so that led status can be read as well as written. Overall looks pretty good, from a technical review perspective. Two worries: 1) exporting ata_scsi_find_dev(), and assuming a scsi device is attached. the latter can be fixed by a !NULL check (and should be), but its a bit of a layering violation since long term we want to make the SCSI simulator optional for all ATA devices. 2) vaguely related to #1, I'm not so sure the attributes should be implemented directly in ahci. if this __or something like it__ appears on non-Intel hardware, the code should be somewhere more generic. - 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
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 28 +++
drivers/ata/libata-core.c |8 +++--
drivers/ata/libata-eh.c | 42 +++--
drivers/ata/pata_at32.c | 61 +++---
drivers/ata/pata_bf54x.c |7 +
drivers/ata/sata_mv.c | 64 ++--
6 files changed, 149 insertions(+), 61 deletions(-)
Alan Cox (1):
libata: Fix early use of port printk. (Was Re: ata4294967295: failed to
start port (errno=-19))
Kristoffer Nyborg Gregertsen (1):
Several fixes for the AVR32 PATA driver
Mark Lord (1):
sata_mv: Fix broken Marvell 7042 support.
Peter Missel (1):
libata: More IVB horkage from TSST
Peter Schwenke (1):
ata_piix: add more toshiba laptops to broken suspend list
Saeed Bishara (1):
sata_mv: fix compilation error when enabling DEBUG
Tejun Heo (1):
libata: report protocol and full CDB on error
sonic zhang (1):
Set proper ATA UDMA mode for bf548 according to system clock.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 483269d..b538e1d 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -967,6 +967,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = TECRA M3,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, Tecra M3),
+ },
+ },
+ {
.ident = TECRA M5,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
@@ -981,6 +988,20 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = TECRA A8,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, TECRA A8),
+ },
+ },
+ {
+ .ident = Satellite R25,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, Satellite R25),
+ },
+ },
+ {
.ident = Satellite U200,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
@@ -988,6 +1009,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = Satellite U200,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, SATELLITE U200),
+ },
+ },
+ {
.ident = Satellite Pro U200,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 33f0627..b514a80 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4185,6 +4185,9 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Devices which get the IVB wrong */
{ QUANTUM FIREBALLlct10 05, A03.0900, ATA_HORKAGE_IVB, },
{ TSSTcorp CDDVDW SH-S202J, SB00, ATA_HORKAGE_IVB, },
+ { TSSTcorp CDDVDW SH-S202J, SB01, ATA_HORKAGE_IVB, },
+ { TSSTcorp CDDVDW SH-S202N, SB00, ATA_HORKAGE_IVB, },
+ { TSSTcorp CDDVDW SH-S202N, SB01, ATA_HORKAGE_IVB, },
/* End Marker */
{ }
@@ -6964,12 +6967,11 @@ int ata_host_start(struct ata_host *host)
if (ap-ops-port_start) {
rc = ap-ops-port_start(ap);
if (rc) {
- ata_port_printk(ap, KERN_ERR, failed to
- start port (errno=%d)\n, rc);
+ if (rc != -ENODEV)
+ dev_printk(KERN_ERR, host-dev, failed
to start port %d (errno=%d)\n, i, rc);
goto err_out;
}
}
-
ata_eh_freeze_port(ap);
}
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 0dac69d..e6605f0 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1850,30 +1850,54 @@ static void ata_eh_link_report(struct ata_link *link)
ehc-i.serror SERR_DEV_XCHG ? DevExch : );
for (tag = 0; tag
Re: [PATCH 04/12] libata: kill ata_id_to_dma_mode()
Tejun Heo wrote: ata_id_to_dma_mode() isn't quite generic. The function is basically privately implemented ata_id_xfermask() combined with hardcoded mode printing and configuration which are specific to ata_generic. Kill the function and open code it in generic_set_mode() using generic xfermode handling functions. Signed-off-by: Tejun Heo [EMAIL PROTECTED] [responding to Alan's objection, and subsequent thread] Yeah, it's a matter of taste. I applied, figuring in for a dime in for a dozen :) I'm not thrilled with all these fine-grained exports of timing tables and mode mask functions. I applied the patches, but I would really like to hide more of these details away from LLD [if possible, the obvious disclaimed...] Jeff - 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 01/12] ata_generic: unindent loop in generic_set_mode()
Tejun Heo wrote: Unindent loop body in generic_set_mode(). This is to ease future change. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/ata_generic.c | 31 --- 1 files changed, 16 insertions(+), 15 deletions(-) applied 1-12 to #upstream, with comments - 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: libata-dev git question:
Mark Lord wrote: I am below novice when it comes to git: $ git-pull --update-head-ok --tags git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git Warning: No merge candidate found because value of config option branch.master.merge does not match any remote branch fetched. No changes. .. Is that normal ? Yes. Is that even the correct command to update my entire local existing copy of Jeff's git tree? No. Generally I would use cd $repo git-checkout master # if not already there git pull# fetches new objects, updates 'master' git-fetch -f $URL upstream:upstream # fetch updated branch git-fetch -f $URL mv-ncq:mv-ncq git-fetch -f $URL upstream-fixes:upstream-fixes git-fetch -f $URL upstream:upstream ... continue for each branch you like... There is probably an easier way to get it to download all branches, even if they have been rebased. Jeff - 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: The BIOS on the Highpoint RR 2300 *corrupts* the GRUB image, so GRUB won't boot for me there. I actually have to re-install GRUB after each attempt so that the drive is usable again with the onboard Intel (ahci) ports. So one then wonders exactly what the Highpoint BIOS is overwriting, RAID metadata, one would assume from the 'RR'... I've no idea if the standard solution is applicable to HPT RR: going through BIOS setup and turning off RAID completely, or if not possible, putting it into JBOD mode. Jeff - 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: Enabling MSI in sata_nv
Greg Freemyer wrote: On Dec 2, 2007 10:07 PM, Philip Langdale [EMAIL PROTECTED] wrote: Hi all, At least for my hardware (MCP55), the sata controller supports MSI and it seems that turning it on is as simple as inserting the call to pci_enable_msi - after that it Just Works(tm). Are there any gotchas that I'm missing? Would a patch to do this be accepted? --phil I don't know if it is relevant, but I had to disable MSI to get a MCP55 NIC to work under 2.6.22. MSI is pretty flaky, but we default it to 'on' for AHCI, which is the enhanced mode side of the sata_nv chip. So it is likely that it works on newer boards -- but even though Mark Lord's response was mistaken (he thought sata_mv was being discussed), he was right too... sata_nv has stability problems and I would prefer not to enable MSI just yet, until we cure the other problems. Jeff - 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: Enabling MSI in sata_nv
Mark Lord wrote: Mark Lord wrote: Philip Langdale wrote: Hi all, At least for my hardware (MCP55), the sata controller supports MSI and it seems that turning it on is as simple as inserting the call to pci_enable_msi - after that it Just Works(tm). Are there any gotchas that I'm missing? Would a patch to do this be accepted? .. Don't even dream about it for now. The driver is unstable enough without throwing MSI into the works. .. Oh, wait a minute.. I misread sata_nv as sata_mv there. FWIW: Marvell says they run with MSI enabled on 6440 (mvsas) in their vendor driver, but not on any of the 50xx and 60xx variants supported by sata_mv. Maybe that's changed in the past year with 7042, I dunno. But that's the latest info I have. Jeff - 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/2] [libata] sata_mv: Support integrated controllers
Mark Lord wrote: Also, I'm not sure I understand why there's a need for the new sata_mv.h file ? The embedded platform includes that, similar to include/linux/pata_platform.h. Jeff - 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: Is BIO_RW_FAILFAST really usable?
Neil Brown wrote: I've been looking at use BIO_RW_FAILFAST in md/raid to improve handling of some error cases. This is particularly significant for the DASD driver (s390 specific). I believe it uses optic fibre to connect to the drives. When one of these paths is unplugged, IO requests will block until an operator runs a command to reset the card (or until it is plugged back in). The only way to avoid this blockage is to use BIO_RW_FAILFAST. So we really need BIO_RW_FAILFAST for a reliable RAID1 configuration on DASD drives. However, I just tested BIO_RW_FAILFAST on my SATA drives: controller 02:06.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) (not using the cards minimal RAID functionality) and requests fail immediately and always with e.g. sd 2:0:0:0: [sdc] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdc, sector 2048 So fail fast obviously isn't generally usable. What is the answer here? Is the Silicon Image driver doing the wrong thing, or is DASD doing the wrong thing, or is BIO_RW_FAILFAST under-specified and we really need multiple flags or what? It's a hard thing to implement, in general, for scalability reasons. To make it work, you need to examine each driver's error handling to figure out what fail fast really means. Most storage drivers are written to try as hard as possible to complete a request, where try as hard as possible can often mean internal retries while trying various multi-path configurations and hardware mode changes. You might be catching SATA in the middle of error handling, for example. So each driver really has a /slight different/ version of try to complete this request, which has the obvious effects on BIO_RW_FAILFAST. No clue about DASD, but in SATA's case I bet that a media or transfer error could be returned to the system more rapidly, while we continue to try to recover in the background. libata doesn't have any direct knowledge of fail-fast at this point, IIRC. But overall it's a job where you must examine each driver, or set of drivers :/ Jeff - 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] sata_nv: don't use legacy DMA in ADMA mode (v3)
Robert Hancock wrote: We need to run any DMA command with result taskfile requested in ADMA mode when the port is in ADMA mode, otherwise it may try to use the legacy DMA engine in ADMA mode which is not allowed. Enforce this with BUG_ON() since data corruption could potentially result if this happened. Also, fail any attempt to try and issue NCQ commands with result taskfile requested, since the hardware doesn't allow this. Signed-off-by: Robert Hancock [EMAIL PROTECTED] applied #upstream-fixes Please make sure to copy relevant NVIDIA engineers on your patches, since they are actively contributing patches to Linux too (and, well, its their hardware :)) Jeff - 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] sata_mv: Warn about Highpoint RocketRAID BIOS treatment of Legacy drives
Mark Lord wrote:
The Highpoint RocketRAID boards using Marvell 7042 chips
overwrite the 9th sector of attached drives at boot time,
when those drives are configured as Legacy (the default)
in the HighPoint BIOS.
This kills GRUB, and probably other stuff.
But it all happens *before* Linux is even loaded.
So, for now we'll log a WARNING when such boards are detected,
and advise users to configure BIOS JBOD volumes instead,
which don't appear to suffer from this problem.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
applied #upstream-fixes with modifications (style, printk message), see
attached.
commit 306b30f74d37f289033c696285e07ce0158a5d7b
Author: Mark Lord [EMAIL PROTECTED]
Date: Tue Dec 4 14:07:52 2007 -0500
sata_mv: Warn about HPT RocketRAID BIOS treatment of Legacy drives
The Highpoint RocketRAID boards using Marvell 7042 chips
overwrite the 9th sector of attached drives at boot time,
when those drives are configured as Legacy (the default)
in the HighPoint BIOS.
This kills GRUB, and probably other stuff.
But it all happens *before* Linux is even loaded.
So, for now we'll log a WARNING when such boards are detected,
and advise users to configure BIOS JBOD volumes instead,
which don't appear to suffer from this problem.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
drivers/ata/sata_mv.c |9 +
1 file changed, 9 insertions(+)
306b30f74d37f289033c696285e07ce0158a5d7b
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 8d864e5..fe0105d 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -2503,6 +2503,15 @@ static int mv_chip_id(struct ata_host *host, unsigned
int board_idx)
case chip_7042:
hp_flags |= MV_HP_PCIE;
+ if (pdev-vendor == PCI_VENDOR_ID_TTI
+ (pdev-device == 0x2300 || pdev-device == 0x2310))
+ {
+ printk(KERN_WARNING sata_mv: Highpoint RocketRAID BIOS
+will CORRUPT DATA on attached drives when
+configured as \Legacy\. BEWARE!\n);
+ printk(KERN_WARNING sata_mv: Use BIOS \JBOD\ volumes
+instead for safety.\n);
+ }
case chip_6042:
hpriv-ops = mv6xxx_ops;
hp_flags |= MV_HP_GEN_IIE;
Re: [PATCH] ahci: add the Device IDs of MCP79 AHCI controller to ahci.c
peerchen wrote: Add the device IDs of legacy mode of MCP79 AHCI controller to ahci.c The patch base on kernel 2.6.24-rc3 Signed-off-by: Peer Chen [EMAIL PROTECTED] applied #upstream-fixes - 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] ata.h: Don't do a SATA check for 40wire_relaxed
Alan Cox wrote:
Without the valid bits at least one set of TSScorp drives report 0 in
word 93 for PATA 40 wire, which we (and the specs) say actually means
SATA. (The SATA version seems to report 80 wire...)
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc2-mm1/include/linux/ata.h
linux-2.6.24-rc2-mm1/include/linux/ata.h
--- linux.vanilla-2.6.24-rc2-mm1/include/linux/ata.h2007-11-16
17:55:20.0 +
+++ linux-2.6.24-rc2-mm1/include/linux/ata.h2007-11-16 18:42:20.0
+
@@ -560,8 +560,6 @@
static inline int ata_drive_40wire_relaxed(const u16 *dev_id)
{
- if (ata_id_is_sata(dev_id))
- return 0; /* SATA */
if ((dev_id[93] 0x2000) == 0x2000)
return 0; /* 80 wire */
return 1;
I've been thinking a lot about this, and I am really wondering if we
should fix up the IDENTIFY DEVICE page instead?
-
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 #upstream] sata_promise: make pdc_atapi_pkt() use values from qc-tf
Tejun Heo wrote: Make pdc_atapi_pkt() use values from qc-tf instead of creating its own. This is to ease future ATAPI handling changes. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Mikael Pettersson [EMAIL PROTECTED] --- Okay, Mikael says it's good for trying out. Please add this one to libata-dev#upstream. Thanks. applied - 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] ata_piix: separate controller IDs into separate enum
Tejun Heo wrote: Separate controller IDs into a separate enum as Jeff requested. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/ata_piix.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) applied - 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 01/14] libata: update atapi_eh_request_sense() such that lbam/lbah contains buffer size
Tejun Heo wrote:
While updating lbam/h for ATAPI commands, atapi_eh_request_sense() was
left out. Update it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-eh.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 77083b5..2e3d3a2 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1302,8 +1302,8 @@ static unsigned int atapi_eh_request_sense(struct
ata_queued_cmd *qc)
tf.feature |= ATAPI_PKT_DMA;
} else {
tf.protocol = ATA_PROT_ATAPI;
- tf.lbam = (8 * 1024) 0xff;
- tf.lbah = (8 * 1024) 8;
+ tf.lbam = SCSI_SENSE_BUFFERSIZE;
+ tf.lbah = 0;
seems like #upstream-fixes material?
-
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 05/14] libata: make -data_xfer return the number of consumed bytes
Tejun Heo wrote:
Depending on how many bytes are transferred as a unit, PIO data
tranasfer may consume more bytes than requested. Knowing how much
data is consumed is necessary to determine how much is left for
draining. This patch update -data_xfer such that it returns the
number of consumed bytes.
While at it, it also makes the following changes.
* s/adev/dev/
* s/buflen/len/
* use READ/WRITE constants for rw indication
* misc clean ups
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c| 56 ++---
drivers/ata/pata_bf54x.c | 34 +
drivers/ata/pata_ixp4xx_cf.c | 32 ---
drivers/ata/pata_legacy.c| 38 +++-
drivers/ata/pata_qdi.c | 32 +--
drivers/ata/pata_scc.c | 38 +++-
drivers/ata/pata_winbond.c | 32 +--
include/linux/libata.h | 11 ---
8 files changed, 152 insertions(+), 121 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index bc53492..10f3b42 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4966,48 +4966,55 @@ void swap_buf_le16(u16 *buf, unsigned int buf_words)
/**
* ata_data_xfer - Transfer data by PIO
- * @adev: device to target
+ * @dev: device to target
* @buf: data buffer
- * @buflen: buffer length
+ * @len: buffer length
* @write_data: read/write
*
* Transfer data from/to the device data register by PIO.
*
* LOCKING:
* Inherited from caller.
+ *
+ * RETURNS:
+ * Bytes consumed.
*/
-void ata_data_xfer(struct ata_device *adev, unsigned char *buf,
- unsigned int buflen, int write_data)
+unsigned int ata_data_xfer(struct ata_device *dev, unsigned char *buf,
+ unsigned int len, int rw)
{
- struct ata_port *ap = adev-link-ap;
- unsigned int words = buflen 1;
+ struct ata_port *ap = dev-link-ap;
+ void __iomem *data_addr = ap-ioaddr.data_addr;
+ unsigned int words = len 1;
/* Transfer multiple of 2 bytes */
- if (write_data)
- iowrite16_rep(ap-ioaddr.data_addr, buf, words);
+ if (rw == READ)
+ ioread16_rep(data_addr, buf, words);
else
- ioread16_rep(ap-ioaddr.data_addr, buf, words);
+ iowrite16_rep(data_addr, buf, words);
/* Transfer trailing 1 byte, if any. */
- if (unlikely(buflen 0x01)) {
+ if (unlikely(len 0x01)) {
u16 align_buf[1] = { 0 };
- unsigned char *trailing_buf = buf + buflen - 1;
+ unsigned char *trailing_buf = buf + len - 1;
- if (write_data) {
- memcpy(align_buf, trailing_buf, 1);
- iowrite16(le16_to_cpu(align_buf[0]),
ap-ioaddr.data_addr);
- } else {
- align_buf[0] =
cpu_to_le16(ioread16(ap-ioaddr.data_addr));
+ if (rw == READ) {
+ align_buf[0] = cpu_to_le16(ioread16(data_addr));
memcpy(trailing_buf, align_buf, 1);
+ } else {
+ memcpy(align_buf, trailing_buf, 1);
+ iowrite16(le16_to_cpu(align_buf[0]), data_addr);
}
+ words++;
}
+
+ return words 1;
}
/**
* ata_data_xfer_noirq - Transfer data by PIO
- * @adev: device to target
+ * @dev: device to target
* @buf: data buffer
- * @buflen: buffer length
+ * @len: buffer length
* @write_data: read/write
*
* Transfer data from/to the device data register by PIO. Do the
@@ -5015,14 +5022,21 @@ void ata_data_xfer(struct ata_device *adev, unsigned
char *buf,
*
* LOCKING:
* Inherited from caller.
+ *
+ * RETURNS:
+ * Bytes consumed.
*/
-void ata_data_xfer_noirq(struct ata_device *adev, unsigned char *buf,
-unsigned int buflen, int write_data)
+unsigned int ata_data_xfer_noirq(struct ata_device *dev, unsigned char *buf,
+unsigned int len, int rw)
{
unsigned long flags;
+ unsigned int consumed;
+
local_irq_save(flags);
- ata_data_xfer(adev, buf, buflen, write_data);
+ consumed = ata_data_xfer(dev, buf, len, rw);
local_irq_restore(flags);
+
+ return consumed;
}
diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c
index 81db405..53ae7d3 100644
--- a/drivers/ata/pata_bf54x.c
+++ b/drivers/ata/pata_bf54x.c
@@ -1161,40 +1161,42 @@ static unsigned char bfin_bmdma_status(struct ata_port
*ap)
* bfin_data_xfer - Transfer data by PIO
* @adev: device for this I/O
* @buf: data buffer
- * @buflen: buffer length
+ * @len: buffer length
* @write_data: read/write
*
* Note: Original code is
Re: [PATCH 08/14] libata: kill non-sg DMA interface
Tejun Heo wrote: With atapi_request_sense() converted to use sg, there's no user of non-sg interface. Kill non-sg interface. * ATA_QCFLAG_SINGLE and ATA_QCFLAG_SG are removed. ATA_QCFLAG_DMAMAP is used instead. (this way no LLD change is necessary) * qc-buf_virt is removed. * ata_sg_init_one() and ata_sg_setup_one() are removed. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Rusty Russel [EMAIL PROTECTED] I would move the kill-non-sg-path changes to the front of the patchset - 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 11/14] libata: add qc-dma_nbytes
Tejun Heo wrote: qc-nbytes doesn't include extra buffers setup by libata core layer and my be odd. This patch adds qc-dma_nbytes which includes any extra buffers setup by libata core layer and is guaranteed to be aligned on 4 byte boundary. This value is to be used to program the host controller. As this represents the actual length of buffer available to the controller and the controller must be able to deal with short transfers for ATAPI commands which can transfer variable length, this shouldn't break any controllers while making problems like rounding-down and controllers choking up on odd transfer bytes much less likely. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-core.c | 11 +++ drivers/ata/pata_pdc202xx_old.c |2 +- drivers/ata/sata_inic162x.c |2 +- drivers/ata/sata_qstor.c|2 +- include/linux/libata.h |3 ++- 5 files changed, 12 insertions(+), 8 deletions(-) I would suggest two values: qc-nbytes - value to program host controllers with qc-raw_nbytes - the precise value, without any padding etc. IMO this makes it more likely that people will use the right value - 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 14/14] libata: use PIO for misc ATAPI commands
Tejun Heo wrote: ATAPI devices come with plethora of bugs and many ATA controllers have trouble dealing with odd byte DMA transfers. The problem is currently somewhat masked by not allowing DMA transfers if the transfer size isn't aligned to 16 bytes plus partial masking in problematic LLDs. This masking is taken verbatim from IDE and is far from perfection. There's no fundamental explanation why this should be sufficient and there are ATAPI devices which don't work with the IDE driver. In addition, this mixture of PIO and DMA commands reduces test coverage which is already insufficient considering the crazy number of ATAPI devices out in the wild. Also, these misc ATAPI commands usually transfer small amount of data and are used infrequently. There isn't much to be gained from using DMA. Combined with the fact that another OS which is probably the only one that most ATAPI device vendors test against uses PIO for these commands, it's much wiser to use PIO for these commands and concentrate debugging efforts on getting PIO right for misc commands and DMA for bulk transfer commands. Private command type / transfer length filtering in sata_promise, pata_it821x and pata_pdc2027x are removed as core layer filtering is more conservative. Signed-off-by: Tejun Heo [EMAIL PROTECTED] The other patches were OK, but I'm still not happy about punishing the good guys - 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_pcmcia: Minor cleanups and support for dual channel cards
Alan Cox wrote: setup and it821x fixes can go to mainstream for 2.6.25 I think - no bad reports yet. BTW so we don't duplicate work right now I'm working on a full DMA engine based driver for the INIC162x. Dunno if I'll ever get it to work as the docs are a bit minimal but we shall see. - 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 Can you be a bit more specific, or confirm my guesses? In #for-testing I have Alan Cox (4): libata: fix (hopefully) all the remaining problems with devices failing setup pata_pcmcia: Add support for dumb 8bit IDE emulations libata-core: Don't have screaming fits over DF/ERR combinations libata/pata_it821x: Improve handling of poorly compatible emulations it sounds like all patches in the branch except for DF/ERR should go upstream for 2.6.25? And in addition, pata_pcmcia: Minor cleanups and support for dual channel cards should go upstream after the above pata_pcmcia change is applied? Jeff - 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_of_platform: Move electra-ide support over to new framework
Olof Johansson wrote: [POWERPC] Move electra-ide support over to new pata_of_platform framework Move electra-ide glue over to the new pata_of_platform framework, and add the quirks needed to that driver. Signed-off-by: Olof Johansson [EMAIL PROTECTED] --- I'll remove the electra-ide stuff from arch/powerpc/platforms/pasemi once this hits a common tree, since otherwise I'd be without IDE until they converge (i.e. 2.6.25 merge window). FWIW I'm presuming this work will go via a powerpc tree not libata... Generally that's not the case, but here it's largely an arch-specific work. Jeff - 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: ATA ACPI (was Re: Linux 2.6.24-rc4)
Jeff Garzik wrote: Some BIOS writer probably thought that was a good idea, but maybe not for Linus. er, s/Linus/Linux/ :) - 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: ATA ACPI (was Re: Linux 2.6.24-rc4)
Jeff Garzik wrote: ata1: failed to recover some devices, retrying in 5 secs ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata1.00: ACPI on devcfg failed the second time, disabling (errno=-5) ata1.00: revalidation failed (errno=1) ata1: failed to recover some devices, retrying in 5 secs ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/133 dmesg, lspci, hdparm: http://www.unixy.pl/maciek/download/kernel/2.6.24-rc4/ Can you also post dmidecode output? And may I presume that booting with libata module option 'noacpi=1' fixes the problem? Third question -- this is just cosmetic, right? According to the output above, error recovery succeeded and you continue booting and talking to your disk? Jeff - 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] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote: This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode on systems with memory located above 4GB. We need to delay setting the 64-bit DMA mask until the PRD table and padding buffer are allocated so that they don't get allocated above 4GB and break legacy mode (which is needed for ATAPI devices). Signed-off-by: Robert Hancock [EMAIL PROTECTED] This is a bit nasty :/ I would consider setting the consistent DMA mask to 32-bit, and setting the overall mask to 64-bit. Seems like that would solve the problem? Also, does this need to be rebased on top of what I just pushed upstream? Jeff - 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: ATA ACPI (was Re: Linux 2.6.24-rc4)
Maciej Rutecki wrote: http://www.unixy.pl/maciek/download/kernel/2.6.24-rc4/dmidecode.txt.gz Thanks. And may I presume that booting with libata module option 'noacpi=1' fixes the problem? noacpi=1 kernel command line or module parameters? First, no change: http://www.unixy.pl/maciek/download/kernel/2.6.24-rc4/dmesg_noacpi.txt.gz Kernel command line: root=/dev/sda2 ro vga=0x318 resume=/dev/sda3 selinux=1 enforcing=1 noacpi=1 Yes, that's a module option. _If_ libata is built into the kernel, and not a kernel module, then you can supply libata.noacpi=1 on the kernel command line. I don't think that works with modules. With libata built as a module (libata.ko), you will probably need to edit /etc/modprobe.conf. Jeff - 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 05/14] libata: make -data_xfer return the number of consumed bytes
Tejun Heo wrote: Jeff Garzik wrote: IMO s/buflen/len/ causes needless patch noise, and makes this harder review Separating out s/buflen/len/ to a separate patch seemed silly yet I wanted to renamed it. :-P If you want to kill it, I'll kill the renaming. If you want it in a separate patch, I'll separate it out. IMO just kill the renaming. But if you really really really want to rename, put it in a separate patch. :) - 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 14/14] libata: use PIO for misc ATAPI commands
On Thu, Dec 06, 2007 at 12:13:18AM +0900, Tejun Heo wrote: Alan Cox wrote: It eventually has to end up in -rc. If not for 2.6.25-rc1 is too early, we can put it in #testing and put it into #upstream later. Nobody cares about libata git trees. If you want some initial test coverage put it in -mm. 99% incorrect. #for-testing ends up in #ALL which Andrew always includes in -mm. #upstream also ends up in #ALL but is different in that it will get into mainline when the next -rc1 opens. Jeff, right? 100% correct. Jeff - 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. OTOH it is quite reasonable to explore auto-loading DM on top of the bare drive, and populating a DM table, if you see that particular BIOS signature or [insert other detection method]. Jeff - 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Jeff Garzik wrote: Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. .. The hardware limitation here is the SATA controller card: it corrupts data at the last GB boundary. The BIOS does that, not the controller card. If you pop the BIOS chip or plug the card into a non-x86 box (or any of several other alternatives), the problem is likely to go away. Jeff - 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Jeff Garzik wrote: Mark Lord wrote: To do so, requires that we perhaps do a similar capacity truncation in sata_mv, but only if we see a metadata block at the expected location (because a Legacy mode drive will use the *real* capacity, placing the metadata in the 9th sector instead. Definitely _not_. This is a core Linux maxim: export what the hardware exports, no more no less. We drive the bare metal. OTOH it is quite reasonable to explore auto-loading DM on top of the bare drive, and populating a DM table, if you see that particular BIOS signature or [insert other detection method]. .. We must remember that *data integrity* trumps all other principles here. If we don't strongly discourage/prevent the user from installing Linux or storing data in the corruptible region, they *will lose data*, and blame us. These are bootable cards, so people will install distro's from scratch directly to them, or to RAIDs configured onto them by the distro. So whatever we do has to be something *safe* for those situations. Then auto-load a device map that gets it right. The problem is not at the chip or device level, and this is the same problem as any number of other cards with softRAID on it. Not a new problem, not a new solution... Jeff - 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: Why we were seeing so many spurious NCQ completions
Tejun Heo wrote: Hello, all. This has been going on for quite some time now but I finally succeeded to reproduce the problem and find out what has been going on. It wasn't drive's or controller's fault. The spurious completion detection logic was wrong which makes all of this my fault. :-) The attached patch induces NCQ spurious completions by inserting artificial delays during irq handling. The following is log with the patch applied. A [ 1125.478813] ata35: MON issue=0x0 SAct=0x1 sactive=0x3 SDB FIS=004040a1:0002 B [ 1125.480248] ata35: MON issue=0x4 SAct=0x6 sactive=0x7 SDB FIS=004040a1:0001 C [ 1125.481614] ata35: MON issue=0x0 SAct=0x5 sactive=0x7 SDB FIS=004040a1:0002 D [ 1125.481704] ata35: YYY 0x2 - 0x4 E [ 1125.481722] ata35: XXX issue=0x0 SAct=0x1 sactive=0x1 SDB FIS=004040a1:0004 F [ 1125.483087] ata35: MON issue=0x0 SAct=0x0 sactive=0x1 SDB FIS=004040a1:0001 G [ 1125.484297] ata35: MON issue=0x4 SAct=0x6 sactive=0x7 SDB FIS=004040a1:0001 Thanks a lot for tracking this down, and thanks even more for being humble enough to admit mistakes. More kernel hackers should follow your example. I continue to be a proud mentor, watching you kick ass on the Linux kernel scene :) Jeff - 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] sata_mv: Fix broken Marvell 7042 support.
Mark Lord wrote: Jeff Garzik wrote: ... If you pop the BIOS chip or plug the card into a non-x86 box (or any of several other alternatives), the problem is likely to go away. .. Yeah, I was hoping for a removable BIOS chip, but it's soldered in place. And that's not a solution for most users anyway. That was an example, silly :) I'm not asking users to pop out chips. I'm illustrating that they are separate and distinct pieces, and you cannot assume. Boot into a non-x86 platform, or use your x86 BIOS to disable all optional ROMs, and the BIOS-stomps-data issue goes away. I'm not saying the _problem_ goes away; instead I am illustrating why it is incorrect to update sata_mv for this problem. The solution belongs elsewhere, because the problem is not with the chip, but the BIOS. Continuing with the other emails... What other cards do we support that automatically overwrite user data without confirmation or notice of any kind? If you use any vendor RAID (BIOS RAID / fake RAID), and fail to use DM+dmraid, then data corruption occurs due to lack of knowledge about the presence of underlying BIOS-created RAID metadata. Your case is just another case of problems caused by lack of knowledge of the underlying vendor RAID that the BIOS insists upon using. I'm pretty sure the most recently Fedora release has full dmraid support for known formats, so AFAICS the task at hand should be simply to figure out how to identify the underlying vendor RAID (on-disk signatures are greatly preferred over PCI ID matching), and update dmraid accordingly. Welcome to the suck that is BIOS RAID :) Jeff - 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
[git patches] libata fixes
Notable: kill spurious NCQ completion detection
libata disabling command queueing (aka NCQ) based on some hueristics for
detection device brokenness that ultimately turned out to be broken.
Remove the broken hueristic and turn NCQ back on for all the wrongfully
maligned hard drives.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c| 96 +++--
drivers/ata/ata_piix.c|7 +++
drivers/ata/libata-core.c | 18 +
3 files changed, 31 insertions(+), 90 deletions(-)
Peter Schwenke (1):
ata_piix: add Toshiba Tecra M4 to broken suspend list
Tejun Heo (3):
ahci: fix engine reset failed message
ahci: don't attach if ICH6 is in combined mode
libata: kill spurious NCQ completion detection
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 4688dbf..54f38c2 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -193,6 +193,8 @@ enum {
ATA_FLAG_ACPI_SATA | ATA_FLAG_AN |
ATA_FLAG_IPM,
AHCI_LFLAG_COMMON = ATA_LFLAG_SKIP_D2H_BSY,
+
+ ICH_MAP = 0x90, /* ICH MAP register */
};
struct ahci_cmd_hdr {
@@ -1271,9 +1273,9 @@ static int ahci_do_softreset(struct ata_link *link,
unsigned int *class,
/* prepare for SRST (AHCI-1.1 10.4.1) */
rc = ahci_kick_engine(ap, 1);
- if (rc)
+ if (rc rc != -EOPNOTSUPP)
ata_link_printk(link, KERN_WARNING,
- failed to reset engine (errno=%d), rc);
+ failed to reset engine (errno=%d)\n, rc);
ata_tf_init(link-device, tf);
@@ -1638,7 +1640,7 @@ static void ahci_port_intr(struct ata_port *ap)
struct ahci_host_priv *hpriv = ap-host-private_data;
int resetting = !!(ap-pflags ATA_PFLAG_RESETTING);
u32 status, qc_active;
- int rc, known_irq = 0;
+ int rc;
status = readl(port_mmio + PORT_IRQ_STAT);
writel(status, port_mmio + PORT_IRQ_STAT);
@@ -1696,80 +1698,12 @@ static void ahci_port_intr(struct ata_port *ap)
rc = ata_qc_complete_multiple(ap, qc_active, NULL);
- /* If resetting, spurious or invalid completions are expected,
-* return unconditionally.
-*/
- if (resetting)
- return;
-
- if (rc 0)
- return;
- if (rc 0) {
+ /* while resetting, invalid completions are expected */
+ if (unlikely(rc 0 !resetting)) {
ehi-err_mask |= AC_ERR_HSM;
ehi-action |= ATA_EH_SOFTRESET;
ata_port_freeze(ap);
- return;
}
-
- /* hmmm... a spurious interrupt */
-
- /* if !NCQ, ignore. No modern ATA device has broken HSM
-* implementation for non-NCQ commands.
-*/
- if (!ap-link.sactive)
- return;
-
- if (status PORT_IRQ_D2H_REG_FIS) {
- if (!pp-ncq_saw_d2h)
- ata_port_printk(ap, KERN_INFO,
- D2H reg with I during NCQ,
- this message won't be printed again\n);
- pp-ncq_saw_d2h = 1;
- known_irq = 1;
- }
-
- if (status PORT_IRQ_DMAS_FIS) {
- if (!pp-ncq_saw_dmas)
- ata_port_printk(ap, KERN_INFO,
- DMAS FIS during NCQ,
- this message won't be printed again\n);
- pp-ncq_saw_dmas = 1;
- known_irq = 1;
- }
-
- if (status PORT_IRQ_SDB_FIS) {
- const __le32 *f = pp-rx_fis + RX_FIS_SDB;
-
- if (le32_to_cpu(f[1])) {
- /* SDB FIS containing spurious completions
-* might be dangerous, whine and fail commands
-* with HSM violation. EH will turn off NCQ
-* after several such failures.
-*/
- ata_ehi_push_desc(ehi,
- spurious completions during NCQ
- issue=0x%x SAct=0x%x FIS=%08x:%08x,
- readl(port_mmio + PORT_CMD_ISSUE),
- readl(port_mmio + PORT_SCR_ACT),
- le32_to_cpu(f[0]), le32_to_cpu(f[1]));
- ehi-err_mask |= AC_ERR_HSM;
- ehi-action |= ATA_EH_SOFTRESET;
- ata_port_freeze(ap);
- } else {
- if (!pp-ncq_saw_sdb)
- ata_port_printk(ap, KERN_INFO,
- spurious SDB FIS %08x:%08x during NCQ,
-
Re: [PATCH #upstream-fixes] ata_piix: add Toshiba Tecra M4 to broken suspend list
Tejun Heo wrote:
From: Peter Schwenke [EMAIL PROTECTED]
Add Toshiba Tecra M4 to broken suspend list. This is from OSDL
bugzilla bug 7780.
Signed-off-by: Peter Schwenke [EMAIL PROTECTED]
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/ata_piix.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index b538e1d..bb62a58 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -974,6 +974,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = TECRA M4,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, Tecra M4),
+ },
+ },
+ {
.ident = TECRA M5,
applied
-
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 #upstream-fixes] libata: kill spurious NCQ completion detection
Tejun Heo wrote: Spurious NCQ completion detection implemented in ahci was incorrect. On AHCI receving and processing FISes and raising interrupts are not interlocked and spurious interrupts are expected. For example, if an interrupt occurs while interrupt handler is running and the running interrupt handler handles the event the new IRQ indicated, after IRQ handler finishes, it will be executed again because IRQ pending bit is set by the new interrupt but there won't be anything to process. Please read the following message for more information. http://article.gmane.org/gmane.linux.ide/26012 This patch... * Removes all spurious IRQ whining from ahci. Spurious NCQ completion detection was completely wrong. Spurious D2H Register FIS taught us that some early drives send spurious D2H Register FIS with I bit set while NCQ commands are in progress but none of recent drives does that and even the ones which show such behavior can do NCQ fine. * Kills all NCQ blacklist entries which were added because of spurious NCQ completions. I tracked down each commit and verified all removed ones are actually added because of spurious completions. WD740ADFD-00NLR1 wasn't deleted but moved upward because the drive not only had spurious NCQ completions but also is slow on sequential data transfers if NCQ is enabled. Maxtor 7V300F0 was added by 0e3dbc01d53940fe10e5a5cfec15ede3e929c918 from Alan Cox. I can only find evidences that the drive only had troubles with spuruious completions by searching the mailing list. This entry needs to be verified and removed if it doesn't have other NCQ related problems. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Alan Cox [EMAIL PROTECTED] --- Alan, can you please check why 7V300F0 was added? Thanks a lot. drivers/ata/ahci.c| 74 +- drivers/ata/libata-core.c | 18 --- 2 files changed, 4 insertions(+), 88 deletions(-) applied - 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 #upstream-fixes] ahci: don't attach if ICH6 is in combined mode
Tejun Heo wrote: ICH6 R/Ms share PCI ID between piix and ahci modes and we've been allowing ahci to attach regardless of how BIOS configured it. However, enabling AHCI mode when the controller is in combined mode can result in unexpected behavior. Don't attach if the controller is in combined mode. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Bill Nottingham [EMAIL PROTECTED] --- drivers/ata/ahci.c | 18 ++ 1 file changed, 18 insertions(+) applied both ahci fixes - 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: sata_mv hotplug flaky?
Orion Poplawski wrote: Not sure what the latest status of sata_mv hotplug should be, but it seems close. I'm currently running 2.6.24-0.81.rc4.git7.fc9 with a MV88SX5081. Pulled a couple drives and re-added. One device got re-added, but the other did not. It seems like I got the system to probe and re-add the first drive by doing a mount -a, but haven't been able (no idea how) to re-add the second. hotplug made great strides with the introduction of the new-EH code, but it still needs a bit of work. Mark Lord was looking into that, so you can sure your report has been noted... Jeff - 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 3/9] libata: xfer_mask is unsigned int not unsigned long
[EMAIL PROTECTED] wrote: From: Tejun Heo [EMAIL PROTECTED] xfer_mask is unsigned int not unsigned long. Change -mode_filter to take and return unsigned int. While at it, rename @adev of ata_pci_default_filter() to @dev for consistency. [EMAIL PROTECTED]: fix types] Signed-off-by: Tejun Heo [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/ata/libata-sff.c |5 +++-- drivers/ata/pata_acpi.c|2 +- drivers/ata/pata_ali.c |2 +- drivers/ata/pata_amd.c | 10 +- drivers/ata/pata_hpt366.c |2 +- drivers/ata/pata_hpt37x.c |4 ++-- drivers/ata/pata_pdc2027x.c|4 ++-- drivers/ata/pata_scc.c |2 +- drivers/ata/pata_serverworks.c |4 ++-- include/linux/libata.h |9 + 10 files changed, 23 insertions(+), 21 deletions(-) patch is outdated... - 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 01/10] libata-acpi: adjust constness in ata_acpi_gtm/stm() parameters
Tejun Heo wrote: * No internal function uses const ata_port. Drop const from @ap. * Make ata_acpi_stm() copy @stm before using it and change @stm to const. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-acpi.c |7 --- include/linux/libata.h|4 ++-- 2 files changed, 6 insertions(+), 5 deletions(-) applied 1-10 to #upstream-fixes - 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 01/10] libata-acpi: adjust constness in ata_acpi_gtm/stm() parameters
Tejun Heo wrote: * No internal function uses const ata_port. Drop const from @ap. * Make ata_acpi_stm() copy @stm before using it and change @stm to const. for the record, I -would- use const ata_port where feasible; its just so rarely feasible, since members of that struct are often being modified. However in a small query-style function, I could see some const-ness perhaps... Jeff - 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 #upstream-fixes] sata_sil: fix spurious IRQ handling
Tejun Heo wrote: Interestingly, sata_sil raises spurious interrupts if it's coupled with Sil SATA_PATA bridge. Currently, sata_sil interrupt handler is strict about spurious interrupts and freezes the port when it occurs. This patch makes it more forgiving. * On SATA PHY event interrupt, serror value is checked to see whether it really is PHYRDY CHG event. If not, SATA PHY event interrupt is ignored. * If ATA interrupt occurs while no command is in progress, it's cleared and ignored. This fixes bugzilla bug 9505. http://bugzilla.kernel.org/show_bug.cgi?id=9505 Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied #upstream-fixes - 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 #upstream-fixes] libata: clear link-eh_info.serror from ata_std_postreset()
Tejun Heo wrote: link-eh_info.serror is used to cache SError for controllers which need it cleared from interrupt handler to clear IRQ. It also should be cleared after reset just like SError itself. Make ata_std_postreset() clear link-eh_info.serror too and update sata_sil such that it doesn't care about bookkeeping the value. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-core.c |1 + drivers/ata/sata_sil.c| 11 +-- 2 files changed, 2 insertions(+), 10 deletions(-) applied #upstream-fixes - 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 #upstream-fixes] libata: add ST3160023AS / 3.42 to NCQ blacklist
Tejun Heo wrote:
Like ST380817AS / 3.42, ST3160023AS / 3.42 times out commands if NCQ
is used. Blacklist it. This is reported by Matheus Izvekov in the
following thread.
http://thread.gmane.org/gmane.linux.ide/24202
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Matheus Izvekov [EMAIL PROTECTED]
---
It could be that all devices with 3.42 firmware have this problem.
I'll ask around. Thanks.
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index e4dea86..e080b07 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4149,6 +4149,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ HITACHI HDS7250SASUN500G*, NULL,ATA_HORKAGE_NONCQ },
{ HITACHI HDS7225SBSUN250G*, NULL,ATA_HORKAGE_NONCQ },
{ ST380817AS, 3.42, ATA_HORKAGE_NONCQ },
+ { ST3160023AS, 3.42, ATA_HORKAGE_NONCQ },
applied #upstream-fixes
-
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 #upstream-fixes] libata: update atapi_eh_request_sense() such that lbam/lbah contains buffer size
Tejun Heo wrote: While updating lbam/h for ATAPI commands, atapi_eh_request_sense() was left out. Update it. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- This patch is from improve-ATAPI-data-xfer patchset pending for #upstream. drivers/ata/libata-eh.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) applied #upstream-fixes - 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 #upstream-fixes] libata: fix ATAPI draining
Tejun Heo wrote:
With ATAPI transfer chunk size properly programmed, libata PIO HSM
should be able to handle full spurious data chunks. Also, it's a good
idea to suppress trailing data warning for misc ATAPI commands as
there can be many of them per command - for example, if the chunk size
is 16 and the drive tries to transfer 510 bytes, there can be 31
trailing data messages.
This patch makes the following updates to libata ATAPI PIO HSM
implementation.
* Make it drain full spurious chunks.
* Suppress trailing data warning message for misc commands.
* Put limit on how many bytes can be drained.
* If odd, round up consumed bytes and the number of bytes to be
drained. This gets the number of bytes to drain right for drivers
which do 16bit PIO.
This patch is partial backport of improve-ATAPI-data-xfer patchset
pending for #upstream.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
This combined with the previous patch fixes bug 9346.
drivers/ata/libata-core.c | 87 ++
include/linux/libata.h|2 +
2 files changed, 67 insertions(+), 22 deletions(-)
Index: work/drivers/ata/libata-core.c
===
--- work.orig/drivers/ata/libata-core.c
+++ work/drivers/ata/libata-core.c
@@ -64,6 +64,7 @@
#include linux/libata.h
#include asm/semaphore.h
#include asm/byteorder.h
+#include linux/cdrom.h
#include libata.h
@@ -4649,6 +4650,43 @@ int ata_check_atapi_dma(struct ata_queue
}
/**
+ * atapi_qc_may_overflow - Check whether data transfer may overflow
+ * @qc: ATA command in question
+ *
+ * ATAPI commands which transfer variable length data to host
+ * might overflow due to application error or hardare bug. This
+ * function checks whether overflow should be drained and ignored
+ * for @qc.
+ *
+ * LOCKING:
+ * None.
+ *
+ * RETURNS:
+ * 1 if @qc may overflow; otherwise, 0.
+ */
+static int atapi_qc_may_overflow(struct ata_queued_cmd *qc)
+{
+ if (qc-tf.protocol != ATA_PROT_ATAPI
+ qc-tf.protocol != ATA_PROT_ATAPI_DMA)
+ return 0;
+
+ if (qc-tf.flags ATA_TFLAG_WRITE)
+ return 0;
+
+ switch (qc-cdb[0]) {
+ case READ_10:
+ case READ_12:
+ case WRITE_10:
+ case WRITE_12:
+ case GPCMD_READ_CD:
+ case GPCMD_READ_CD_MSF:
+ return 0;
+ }
+
+ return 1;
applied, though I hope we can eventually find a better solution...
-
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: git repo and #upstream merging
Tejun Heo wrote: Tejun Heo wrote: This is the second take of improve-ACPI-corner-case-handling patchset and contains the following ten patches. Jeff, this patchset can also be pulled from the following git tree. master.kernel.org:/pub/scm/linux/kernel/git/tj/libata-dev.git acpi-fixes Also, merging this into #upstream can cause some interesting conflicts w/ ACPI timing handling update patches. If you ACK the patchset, I'll prep merged git HEAD for you. It was easier for me to * merge the patches into #upstream-fixes * rebase #upstream on top of #upstream-fixes, while dropping the conflicting ACPI patches And IMO that gives you a bit more freedom to do the merged git -- though that obviously implies you will need to resend the ACPI patchset that you had previously submitted. Jeff - 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
[git patches] libata fixes
In 2.6.24, we turned on ACPI support in libata. This is needed in order
to support suspend/resume and BIOS passworded drives, but it inevitably
brought with it a host of new regressions -- which is what happens
anytime you blindly accept ATA commands the BIOS has decided to toss
your way. :)
It is bigger than I would like for -rc5, but the bulk of these
changes are Tejun addressing regressions from 2.6.23, most of which
are ACPI-related.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-acpi.c | 387 +++--
drivers/ata/libata-core.c | 101 +
drivers/ata/libata-eh.c |4 +-
drivers/ata/libata.h |8 +-
drivers/ata/sata_mv.c | 30 +++-
drivers/ata/sata_sil.c| 18 +--
include/linux/ata.h | 15 ++
include/linux/libata.h| 29 +++-
8 files changed, 419 insertions(+), 173 deletions(-)
Mark Lord (1):
sata_mv: improve warnings about Highpoint RocketRAID 23xx cards
Tejun Heo (15):
sata_sil: fix spurious IRQ handling
libata: clear link-eh_info.serror from ata_std_postreset()
libata: add ST3160023AS / 3.42 to NCQ blacklist
libata-acpi: adjust constness in ata_acpi_gtm/stm() parameters
libata: update ata_*_printk() macros such that level can be a variable
libata: add more opcodes to ata.h
libata: ata_dev_disable() should be called from EH context
libata-acpi: add new hooks ata_acpi_dissociate() and ata_acpi_on_disable()
libata-acpi: implement and use ata_acpi_init_gtm()
libata-acpi: implement dev-gtf_cache and evaluate _GTF right after _STM
during resume
libata-acpi: improve ACPI disabling
libata-acpi: improve _GTF execution error handling and reporting
libata-acpi: implement _GTF command filtering
libata: update atapi_eh_request_sense() such that lbam/lbah contains
buffer size
libata: fix ATAPI draining
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 545ea86..7bf4bef 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -6,6 +6,7 @@
* Copyright (C) 2006 Randy Dunlap
*/
+#include linux/module.h
#include linux/ata.h
#include linux/delay.h
#include linux/device.h
@@ -25,6 +26,18 @@
#include acpi/acmacros.h
#include acpi/actypes.h
+enum {
+ ATA_ACPI_FILTER_SETXFER = 1 0,
+ ATA_ACPI_FILTER_LOCK= 1 1,
+
+ ATA_ACPI_FILTER_DEFAULT = ATA_ACPI_FILTER_SETXFER |
+ ATA_ACPI_FILTER_LOCK,
+};
+
+static unsigned int ata_acpi_gtf_filter = ATA_ACPI_FILTER_DEFAULT;
+module_param_named(acpi_gtf_filter, ata_acpi_gtf_filter, int, 0644);
+MODULE_PARM_DESC(acpi_gtf_filter, filter mask for ACPI _GTF commands, set to
filter out (0x1=set xfermode, 0x2=lock/freeze lock));
+
#define NO_PORT_MULT 0x
#define SATA_ADR(root, pmp)(((root) 16) | (pmp))
@@ -41,6 +54,12 @@ static int is_pci_dev(struct device *dev)
return (dev-bus == pci_bus_type);
}
+static void ata_acpi_clear_gtf(struct ata_device *dev)
+{
+ kfree(dev-gtf_cache);
+ dev-gtf_cache = NULL;
+}
+
/**
* ata_acpi_associate_sata_port - associate SATA port with ACPI objects
* @ap: target SATA port
@@ -94,6 +113,9 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
dev-acpi_handle = acpi_get_child(ap-acpi_handle, i);
}
+
+ if (ata_acpi_gtm(ap, ap-__acpi_init_gtm) == 0)
+ ap-pflags |= ATA_PFLAG_INIT_GTM_VALID;
}
static void ata_acpi_handle_hotplug(struct ata_port *ap, struct kobject *kobj,
@@ -188,6 +210,32 @@ void ata_acpi_associate(struct ata_host *host)
}
/**
+ * ata_acpi_dissociate - dissociate ATA host from ACPI objects
+ * @host: target ATA host
+ *
+ * This function is called during driver detach after the whole host
+ * is shut down.
+ *
+ * LOCKING:
+ * EH context.
+ */
+void ata_acpi_dissociate(struct ata_host *host)
+{
+ int i;
+
+ /* Restore initial _GTM values so that driver which attaches
+* afterward can use them too.
+*/
+ for (i = 0; i host-n_ports; i++) {
+ struct ata_port *ap = host-ports[i];
+ const struct ata_acpi_gtm *gtm = ata_acpi_init_gtm(ap);
+
+ if (ap-acpi_handle gtm)
+ ata_acpi_stm(ap, gtm);
+ }
+}
+
+/**
* ata_acpi_gtm - execute _GTM
* @ap: target ATA port
* @gtm: out parameter for _GTM result
@@ -200,7 +248,7 @@ void ata_acpi_associate(struct ata_host *host)
* RETURNS:
* 0 on success, -ENOENT if _GTM doesn't exist, -errno on failure.
*/
-int ata_acpi_gtm(const struct ata_port *ap, struct ata_acpi_gtm *gtm)
+int ata_acpi_gtm(struct ata_port *ap, struct ata_acpi_gtm *gtm)
{
struct acpi_buffer output = { .length = ACPI_ALLOCATE_BUFFER };
union acpi_object *out_obj;
@@ -259,15 +307,16
