aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/libata.h
Commit message (Collapse)AuthorAge
* Automatic merge of /spare/repo/linux-2.6/.git branch HEAD2005-06-03
|\
| * Automatic merge of /spare/repo/linux-2.6/.git branch HEAD2005-06-02
| |\
| | * libata: Fix use-after-iounmapJeff Garzik2005-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jens Axboe pointed out that the iounmap() call in libata was occurring too early, and some drivers (ahci, probably others) were using ioremap'd memory after it had been unmapped. The patch should address that problem by way of improving the libata driver API: * move ->host_stop() call after all ->port_stop() calls have occurred. * create default helper function ata_host_stop(), and move iounmap() call there. * add ->host_stop_prewalk() hook, use it in sata_qstor.c (hi Mark). sata_qstor appears to require the host-stop-before-port-stop ordering that existed prior to applying the attached patch.
| * | libata: update inline source docsEdward Falk2005-06-02
| |/
| * [PATCH] libata: flush COMRESET set and clearBrett Russ2005-05-15
| | | | | | | | | | | | | | | | | | | | | | | | Updated patch to fix erroneous flush of COMRESET set and missing flush of COMRESET clear. Created a new routine scr_write_flush() to try to prevent this in the future. Also, this patch is based on libata-2.6 instead of the previous libata-dev-2.6 based patch. Signed-off-by: Brett Russ <russb@emc.com> Index: libata-2.6/drivers/scsi/libata-core.c ===================================================================
* | [PATCH] libata basic detection and errata for PATA->SATA bridgesBrad Campbell2005-05-12
|/ | | | | | | | This patch works around an issue with WD drives (and possibly others) over SiL PATA->SATA Bridges on SATA controllers locking up with transfers > 200 sectors. Signed-off-by: Brad Campbell <brad@wasp.net.au>
* Linux-2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!