Conversion to resource-managed iomap was buggy causing init failures
on both vt6420 and 6421 - BAR5 wasn't mapped for both controllers
while on vt6420 sata_via tried to map BAR0-4 twice. Fix it.
Signed-off-by: Tejun Heo <[email protected]>
---
I thought I have a vt6421 but mine too was a vt6420. So, the patch is
verified only for vt6420 but, the vt6421 path is pretty obvious and
should be correct. Please apply.
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index baca6d7..fe9101a 100644
--- a/drivers/ata/sata_via.c
+++ b/drivers/ata/sata_via.c
@@ -423,16 +423,21 @@ static struct ata_probe_ent *vt6420_init_probe_ent(struct pci_dev *pdev)
{
struct ata_probe_ent *probe_ent;
struct ata_port_info *ppi[2];
- void __iomem * const *iomap;
+ void __iomem *bar5;
ppi[0] = ppi[1] = &vt6420_port_info;
probe_ent = ata_pci_init_native_mode(pdev, ppi, ATA_PORT_PRIMARY | ATA_PORT_SECONDARY);
if (!probe_ent)
return NULL;
- iomap = pcim_iomap_table(pdev);
- probe_ent->port[0].scr_addr = svia_scr_addr(iomap[5], 0);
- probe_ent->port[1].scr_addr = svia_scr_addr(iomap[5], 1);
+ bar5 = pcim_iomap(pdev, 5, 0);
+ if (!bar5) {
+ dev_printk(KERN_ERR, &pdev->dev, "failed to iomap PCI BAR 5\n");
+ return NULL;
+ }
+
+ probe_ent->port[0].scr_addr = svia_scr_addr(bar5, 0);
+ probe_ent->port[1].scr_addr = svia_scr_addr(bar5, 1);
return probe_ent;
}
@@ -460,6 +465,13 @@ static struct ata_probe_ent *vt6421_init_probe_ent(struct pci_dev *pdev)
probe_ent->mwdma_mask = 0x07;
probe_ent->udma_mask = 0x7f;
+ for (i = 0; i < 6; i++)
+ if (!pcim_iomap(pdev, i, 0)) {
+ dev_printk(KERN_ERR, &pdev->dev,
+ "failed to iomap PCI BAR %d\n", i);
+ return NULL;
+ }
+
for (i = 0; i < N_PORTS; i++)
vt6421_init_addrs(probe_ent, pcim_iomap_table(pdev), i);
@@ -522,7 +534,7 @@ static int svia_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
if (rc)
return rc;
- rc = pcim_iomap_regions(pdev, 0x1f, DRV_NAME);
+ rc = pci_request_regions(pdev, DRV_NAME);
if (rc) {
pcim_pin_device(pdev);
return rc;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
