On Thu, Aug 03, 2017 at 09:23:51AM +0800, Bin Meng wrote:
Hi Tom,
On Thu, Aug 3, 2017 at 8:37 AM, Tom Rini trini@konsulko.com wrote:
The function now takes a 'base' argument, and we can provide that by having dev_read_addr() get it from the struct uclass dev that we have been given.
Oops. Thanks for catching this!
Cc: Bin Meng bmeng.cn@gmail.com Signed-off-by: Tom Rini trini@konsulko.com
drivers/ata/ahci-pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci-pci.c b/drivers/ata/ahci-pci.c index f46fad899e5a..beec14f46d66 100644 --- a/drivers/ata/ahci-pci.c +++ b/drivers/ata/ahci-pci.c @@ -18,7 +18,7 @@ static int ahci_pci_bind(struct udevice *dev)
static int ahci_pci_probe(struct udevice *dev) {
return ahci_probe_scsi(dev);
return ahci_probe_scsi(dev, dev_read_addr(dev));But dev_read_addr(dev) does not work here as the AHCI device is on PCI bus. The base address should be read from PCI configuration space. There is already an API that does this, see ahci_probe_scsi_pci().
OK, so that calls dm_pci_map_bar for PCI_BASE_ADDRESS_5, which at first glance, I would have to ask why we're hard-coding that value in. And then, I wonder why we have this code in ahci-pci.c but then ahci_probe_scsi_pci() as you note in drivers/ata/ahci.c. Wouldn't both of these calls be the same code? Can you please provide a patch that fixes ahci-pci.c? It's breaking qemu-x86 and I let travis-ci (and then my lab, sigh, funky power issues) be broken long enough that some problems have slipped in to master :(, thanks!