Saeed Bishara wrote: >>> host->private_data = hpriv; >>> hpriv->n_ports = n_ports; >>> >>> - host->iomap = NULL; >>> hpriv->base = ioremap(res->start, res->end - res->start + 1); >>> + host->iomap = &hpriv->base; >>> hpriv->base -= MV_SATAHC0_REG_BASE; >>> >>> rc = mv_create_dma_pools(hpriv, &pdev->dev); >> .. >> >> Well, that's definitely one way to attack it. > the fix better be done by using the hpriv->base instead of iomap table: > void __iomem *hc_mmio = mv_hc_base_from_port( > - ap->host->iomap[MV_PRIMARY_BAR], hard_port); > + mv_host_base(ap->host), hard_port); > u32 hc_irq_cause, ipending; Yeah, that's the right thing to do. >> The original problem being, for a non-PCI device, there is no iomap[] >> table. >> sata_mv only ever uses iomap[MV_PRIMARY_BAR=0], so the above patch should >> work around it just fine. > Jeff, do the libata upper drivers use the other BARs? if not, then we can use pci_iomap to map BAR0, this way we can remove the iomap[] table and use one iomem pointer for pci and none-pci devices. libata core layer _never_ touches those device specific stuff. Using iomap directly is just a convenient way to access the address without adding host private data for PCI controllers. If it doesn't fit, the correct thing to do is to add proper host private data. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
