android_kernel_motorola_sm6225/drivers/ata/pata_marvell.c

197 lines
4.3 KiB
C
Raw Normal View History

/*
* Marvell PATA driver.
*
* For the moment we drive the PATA port in legacy mode. That
* isn't making full use of the device functionality but it is
* easy to get working.
*
* (c) 2006 Red Hat
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/init.h>
#include <linux/blkdev.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <scsi/scsi_host.h>
#include <linux/libata.h>
#include <linux/ata.h>
#define DRV_NAME "pata_marvell"
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
#define DRV_VERSION "0.1.6"
/**
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
* marvell_pata_active - check if PATA is active
* @pdev: PCI device
*
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
* Returns 1 if the PATA port may be active. We know how to check this
* for the 6145 but not the other devices
*/
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
static int marvell_pata_active(struct pci_dev *pdev)
{
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
int i;
u32 devices;
void __iomem *barp;
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
/* We don't yet know how to do this for other devices */
if (pdev->device != 0x6145)
return 1;
barp = pci_iomap(pdev, 5, 0x10);
if (barp == NULL)
return -ENOMEM;
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
printk("BAR5:");
for(i = 0; i <= 0x0F; i++)
printk("%02X:%02X ", i, ioread8(barp + i));
printk("\n");
devices = ioread32(barp + 0x0C);
pci_iounmap(pdev, barp);
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
if (devices & 0x10)
return 1;
return 0;
}
/**
* marvell_pre_reset - check for 40/80 pin
* @link: link
* @deadline: deadline jiffies for the operation
*
* Perform the PATA port setup we need.
*/
static int marvell_pre_reset(struct ata_link *link, unsigned long deadline)
{
struct ata_port *ap = link->ap;
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
if (pdev->device == 0x6145 && ap->port_no == 0 &&
!marvell_pata_active(pdev)) /* PATA enable ? */
return -ENOENT;
return ata_sff_prereset(link, deadline);
}
static int marvell_cable_detect(struct ata_port *ap)
{
/* Cable type */
switch(ap->port_no)
{
case 0:
if (ioread8(ap->ioaddr.bmdma_addr + 1) & 1)
return ATA_CBL_PATA40;
return ATA_CBL_PATA80;
case 1: /* Legacy SATA port */
return ATA_CBL_SATA;
}
libata: add deadline support to prereset and reset methods Add @deadline to prereset and reset methods and make them honor it. ata_wait_ready() which directly takes @deadline is implemented to be used as the wait function. This patch is in preparation for EH timing improvements. * ata_wait_ready() never does busy sleep. It's only used from EH and no wait in EH is that urgent. This function also prints 'be patient' message automatically after 5 secs of waiting if more than 3 secs is remaining till deadline. * ata_bus_post_reset() now fails with error code if any of its wait fails. This is important because earlier reset tries will have shorter timeout than the spec requires. If a device fails to respond before the short timeout, reset should be retried with longer timeout rather than silently ignoring the device. There are three behavior differences. 1. Timeout is applied to both devices at once, not separately. This is more consistent with what the spec says. 2. When a device passes devchk but fails to become ready before deadline. Previouly, post_reset would just succeed and let device classification remove the device. New code fails the reset thus causing reset retry. After a few times, EH will give up disabling the port. 3. When slave device passes devchk but fails to become accessible (TF-wise) after reset. Original code disables dev1 after 30s timeout and continues as if the device doesn't exist, while the patched code fails reset. When this happens, new code fails reset on whole port rather than proceeding with only the primary device. If the failing device is suffering transient problems, new code retries reset which is a better behavior. If the failing device is actually broken, the net effect is identical to it, but not to the other device sharing the channel. In the previous code, reset would have succeeded after 30s thus detecting the working one. In the new code, reset fails and whole port gets disabled. IMO, it's a pathological case anyway (broken device sharing bus with working one) and doesn't really matter. * ata_bus_softreset() is changed to return error code from ata_bus_post_reset(). It used to return 0 unconditionally. * Spin up waiting is to be removed and not converted to honor deadline. * To be on the safe side, deadline is set to 40s for the time being. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-02-02 08:50:52 +01:00
BUG();
return 0; /* Our BUG macro needs the right markup */
}
/* No PIO or DMA methods needed for this device */
static struct scsi_host_template marvell_sht = {
ATA_BMDMA_SHT(DRV_NAME),
};
libata: implement and use ops inheritance libata lets low level drivers build ata_port_operations table and register it with libata core layer. This allows low level drivers high level of flexibility but also burdens them with lots of boilerplate entries. This becomes worse for drivers which support related similar controllers which differ slightly. They share most of the operations except for a few. However, the driver still needs to list all operations for each variant. This results in large number of duplicate entries, which is not only inefficient but also error-prone as it becomes very difficult to tell what the actual differences are. This duplicate boilerplates all over the low level drivers also make updating the core layer exteremely difficult and error-prone. When compounded with multi-branched development model, it ends up accumulating inconsistencies over time. Some of those inconsistencies cause immediate problems and fixed. Others just remain there dormant making maintenance increasingly difficult. To rectify the problem, this patch implements ata_port_operations inheritance. To allow LLDs to easily re-use their own ops tables overriding only specific methods, this patch implements poor man's class inheritance. An ops table has ->inherits field which can be set to any ops table as long as it doesn't create a loop. When the host is started, the inheritance chain is followed and any operation which isn't specified is taken from the nearest ancestor which has it specified. This operation is called finalization and done only once per an ops table and the LLD doesn't have to do anything special about it other than making the ops table non-const such that libata can update it. libata provides four base ops tables lower drivers can inherit from - base, sata, pmp, sff and bmdma. To avoid overriding these ops accidentaly, these ops are declared const and LLDs should always inherit these instead of using them directly. After finalization, all the ops table are identical before and after the patch except for setting .irq_handler to ata_interrupt in drivers which didn't use to. The .irq_handler doesn't have any actual effect and the field will soon be removed by later patch. * sata_sx4 is still using old style EH and currently doesn't take advantage of ops inheritance. Signed-off-by: Tejun Heo <htejun@gmail.com>
2008-03-25 04:22:49 +01:00
static struct ata_port_operations marvell_ops = {
.inherits = &ata_bmdma_port_ops,
.cable_detect = marvell_cable_detect,
.prereset = marvell_pre_reset,
};
/**
* marvell_init_one - Register Marvell ATA PCI device with kernel services
* @pdev: PCI device to register
* @ent: Entry in marvell_pci_tbl matching with @pdev
*
* Called from kernel PCI layer.
*
* LOCKING:
* Inherited from PCI layer (may sleep).
*
* RETURNS:
* Zero on success, or -ERRNO value.
*/
static int marvell_init_one (struct pci_dev *pdev, const struct pci_device_id *id)
{
libata: clean up SFF init mess The intention of using port_mask in SFF init helpers was to eventually support exoctic configurations such as combination of legacy and native port on the same controller. This never became actually necessary and the related code always has been subtly broken one way or the other. Now that new init model is in place, there is no reason to make common helpers capable of handling all corner cases. Exotic cases can simply dealt within LLDs as necessary. This patch removes port_mask handling in SFF init helpers. SFF init helpers don't take n_ports argument and interpret it into port_mask anymore. All information is carried via port_info. n_ports argument is dropped and always two ports are allocated. LLD can tell SFF to skip certain port by marking it dummy. Note that SFF code has been treating unuvailable ports this way for a long time until recent breakage fix from Linus and is consistent with how other drivers handle with unavailable ports. This fixes 1-port legacy host handling still broken after the recent native mode fix and simplifies SFF init logic. The following changes are made... * ata_pci_init_native_host() and ata_init_legacy_host() both now try to initialized whatever they can and mark failed ports dummy. They return 0 if any port is successfully initialized. * ata_pci_prepare_native_host() and ata_pci_init_one() now doesn't take n_ports argument. All info should be specified via port_info array. Always two ports are allocated. * ata_pci_init_bmdma() exported to be used by LLDs in exotic cases. * port_info handling in all LLDs are standardized - all port_info arrays are const stack variable named ppi. Unless the second port is different from the first, its port_info is specified as NULL (tells libata that it's identical to the last non-NULL port_info). * pata_hpt37x/hpt3x2n: don't modify static variable directly. Make an on-stack copy instead as ata_piix does. * pata_uli: It has 4 ports instead of 2. Don't use ata_pci_prepare_native_host(). Allocate the host explicitly and use init helpers. It's simple enough. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-05-04 12:43:58 +02:00
static const struct ata_port_info info = {
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
.udma_mask = ATA_UDMA5,
.port_ops = &marvell_ops,
};
libata: clean up SFF init mess The intention of using port_mask in SFF init helpers was to eventually support exoctic configurations such as combination of legacy and native port on the same controller. This never became actually necessary and the related code always has been subtly broken one way or the other. Now that new init model is in place, there is no reason to make common helpers capable of handling all corner cases. Exotic cases can simply dealt within LLDs as necessary. This patch removes port_mask handling in SFF init helpers. SFF init helpers don't take n_ports argument and interpret it into port_mask anymore. All information is carried via port_info. n_ports argument is dropped and always two ports are allocated. LLD can tell SFF to skip certain port by marking it dummy. Note that SFF code has been treating unuvailable ports this way for a long time until recent breakage fix from Linus and is consistent with how other drivers handle with unavailable ports. This fixes 1-port legacy host handling still broken after the recent native mode fix and simplifies SFF init logic. The following changes are made... * ata_pci_init_native_host() and ata_init_legacy_host() both now try to initialized whatever they can and mark failed ports dummy. They return 0 if any port is successfully initialized. * ata_pci_prepare_native_host() and ata_pci_init_one() now doesn't take n_ports argument. All info should be specified via port_info array. Always two ports are allocated. * ata_pci_init_bmdma() exported to be used by LLDs in exotic cases. * port_info handling in all LLDs are standardized - all port_info arrays are const stack variable named ppi. Unless the second port is different from the first, its port_info is specified as NULL (tells libata that it's identical to the last non-NULL port_info). * pata_hpt37x/hpt3x2n: don't modify static variable directly. Make an on-stack copy instead as ata_piix does. * pata_uli: It has 4 ports instead of 2. Don't use ata_pci_prepare_native_host(). Allocate the host explicitly and use init helpers. It's simple enough. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-05-04 12:43:58 +02:00
static const struct ata_port_info info_sata = {
/* Slave possible as its magically mapped not real */
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
.udma_mask = ATA_UDMA6,
.port_ops = &marvell_ops,
};
libata: clean up SFF init mess The intention of using port_mask in SFF init helpers was to eventually support exoctic configurations such as combination of legacy and native port on the same controller. This never became actually necessary and the related code always has been subtly broken one way or the other. Now that new init model is in place, there is no reason to make common helpers capable of handling all corner cases. Exotic cases can simply dealt within LLDs as necessary. This patch removes port_mask handling in SFF init helpers. SFF init helpers don't take n_ports argument and interpret it into port_mask anymore. All information is carried via port_info. n_ports argument is dropped and always two ports are allocated. LLD can tell SFF to skip certain port by marking it dummy. Note that SFF code has been treating unuvailable ports this way for a long time until recent breakage fix from Linus and is consistent with how other drivers handle with unavailable ports. This fixes 1-port legacy host handling still broken after the recent native mode fix and simplifies SFF init logic. The following changes are made... * ata_pci_init_native_host() and ata_init_legacy_host() both now try to initialized whatever they can and mark failed ports dummy. They return 0 if any port is successfully initialized. * ata_pci_prepare_native_host() and ata_pci_init_one() now doesn't take n_ports argument. All info should be specified via port_info array. Always two ports are allocated. * ata_pci_init_bmdma() exported to be used by LLDs in exotic cases. * port_info handling in all LLDs are standardized - all port_info arrays are const stack variable named ppi. Unless the second port is different from the first, its port_info is specified as NULL (tells libata that it's identical to the last non-NULL port_info). * pata_hpt37x/hpt3x2n: don't modify static variable directly. Make an on-stack copy instead as ata_piix does. * pata_uli: It has 4 ports instead of 2. Don't use ata_pci_prepare_native_host(). Allocate the host explicitly and use init helpers. It's simple enough. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-05-04 12:43:58 +02:00
const struct ata_port_info *ppi[] = { &info, &info_sata };
if (pdev->device == 0x6101)
libata: clean up SFF init mess The intention of using port_mask in SFF init helpers was to eventually support exoctic configurations such as combination of legacy and native port on the same controller. This never became actually necessary and the related code always has been subtly broken one way or the other. Now that new init model is in place, there is no reason to make common helpers capable of handling all corner cases. Exotic cases can simply dealt within LLDs as necessary. This patch removes port_mask handling in SFF init helpers. SFF init helpers don't take n_ports argument and interpret it into port_mask anymore. All information is carried via port_info. n_ports argument is dropped and always two ports are allocated. LLD can tell SFF to skip certain port by marking it dummy. Note that SFF code has been treating unuvailable ports this way for a long time until recent breakage fix from Linus and is consistent with how other drivers handle with unavailable ports. This fixes 1-port legacy host handling still broken after the recent native mode fix and simplifies SFF init logic. The following changes are made... * ata_pci_init_native_host() and ata_init_legacy_host() both now try to initialized whatever they can and mark failed ports dummy. They return 0 if any port is successfully initialized. * ata_pci_prepare_native_host() and ata_pci_init_one() now doesn't take n_ports argument. All info should be specified via port_info array. Always two ports are allocated. * ata_pci_init_bmdma() exported to be used by LLDs in exotic cases. * port_info handling in all LLDs are standardized - all port_info arrays are const stack variable named ppi. Unless the second port is different from the first, its port_info is specified as NULL (tells libata that it's identical to the last non-NULL port_info). * pata_hpt37x/hpt3x2n: don't modify static variable directly. Make an on-stack copy instead as ata_piix does. * pata_uli: It has 4 ports instead of 2. Don't use ata_pci_prepare_native_host(). Allocate the host explicitly and use init helpers. It's simple enough. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-05-04 12:43:58 +02:00
ppi[1] = &ata_dummy_port_info;
ahci, pata_marvell: play nicely together I've been chasing Jeff about this for months. Jeff added the Marvell device identifiers to the ahci driver without making the AHCI driver handle the PATA port. This means a lot of users can't use current kernels and in most distro cases can't even install. This has been going on since March 2008 for the 6121 Marvell, and late 2007 for the 6145!!! This was all pointed out at the time and repeatedly ignored. Bugs assigned to Jeff about this are ignored also. To quote Jeff in email > "Just switch the order of 'ahci' and 'pata_marvell' in > /etc/modprobe.conf, then use Fedora's tools regenerate the initrd. > See? It's not rocket science, and the current configuration can be > easily made to work for Fedora users." (Which isn't trivial, isn't end user, shouldn't be needed, and as it usually breaks at install time is in fact impossible) To quote Jeff in August 2007 > " mv-ahci-pata > Marvell 6121/6141 PATA support. Needs fixing in the 'PATA controller > command' area before it is usable, and can go upstream." Only he add the ids anyway later and caused regressions, adding a further id in March causing more regresions. The actual fix for the moment is very simple. If the user has included the pata_marvell driver let it drive the ports. If they've only selected for SATA support give them the AHCI driver which will run the port a fraction faster. Allow the user to control this decision via ahci.marvell_enable as a module parameter so that distributions can ship 'it works' defaults and smarter users (or config tools) can then flip it over it desired. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-09-03 15:48:34 +02:00
#if defined(CONFIG_AHCI) || defined(CONFIG_AHCI_MODULE)
if (!marvell_pata_active(pdev)) {
printk(KERN_INFO DRV_NAME ": PATA port not active, deferring to AHCI driver.\n");
return -ENODEV;
}
#endif
return ata_pci_sff_init_one(pdev, ppi, &marvell_sht, NULL);
}
static const struct pci_device_id marvell_pci_tbl[] = {
{ PCI_DEVICE(0x11AB, 0x6101), },
{ PCI_DEVICE(0x11AB, 0x6121), },
{ PCI_DEVICE(0x11AB, 0x6123), },
{ PCI_DEVICE(0x11AB, 0x6145), },
{ } /* terminate list */
};
static struct pci_driver marvell_pci_driver = {
.name = DRV_NAME,
.id_table = marvell_pci_tbl,
.probe = marvell_init_one,
.remove = ata_pci_remove_one,
#ifdef CONFIG_PM
.suspend = ata_pci_device_suspend,
.resume = ata_pci_device_resume,
#endif
};
static int __init marvell_init(void)
{
return pci_register_driver(&marvell_pci_driver);
}
static void __exit marvell_exit(void)
{
pci_unregister_driver(&marvell_pci_driver);
}
module_init(marvell_init);
module_exit(marvell_exit);
MODULE_AUTHOR("Alan Cox");
MODULE_DESCRIPTION("SCSI low-level driver for Marvell ATA in legacy mode");
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, marvell_pci_tbl);
MODULE_VERSION(DRV_VERSION);