On 15 September 2015 at 08:20, Bin Meng <bmeng...@gmail.com> wrote: > Hi Simon, > > On Tue, Sep 15, 2015 at 9:51 PM, Simon Glass <s...@chromium.org> wrote: >> On 11 September 2015 at 04:24, Bin Meng <bmeng...@gmail.com> wrote: >>> The Designware ethernet controller is also seen on PCI bus, e.g. >>> on Intel Quark SoC. Add this support in the DM version driver. >>> >>> Signed-off-by: Bin Meng <bmeng...@gmail.com> >>> >>> --- >>> >>> Changes in v5: >>> - Wrap PCI device support with CONFIG_DM_PCI >>> >>> Changes in v3: >>> - Change to use dm_pci_read_config32() >>> >>> Changes in v2: >>> - Change to use device_is_on_pci_bus() >>> >>> drivers/net/designware.c | 42 ++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 42 insertions(+) >> >> Acked-by: Simon Glass <s...@chromium.org> >> >> Please see below. >> >>> >>> diff --git a/drivers/net/designware.c b/drivers/net/designware.c >>> index ae78d21..6433896 100644 >>> --- a/drivers/net/designware.c >>> +++ b/drivers/net/designware.c >>> @@ -14,6 +14,7 @@ >>> #include <errno.h> >>> #include <miiphy.h> >>> #include <malloc.h> >>> +#include <pci.h> >>> #include <linux/compiler.h> >>> #include <linux/err.h> >>> #include <asm/io.h> >>> @@ -558,6 +559,22 @@ static int designware_eth_write_hwaddr(struct udevice >>> *dev) >>> return _dw_write_hwaddr(priv, pdata->enetaddr); >>> } >>> >>> +static int designware_eth_bind(struct udevice *dev) >>> +{ >>> +#ifdef CONFIG_DM_PCI >>> + static int num_cards; >>> + char name[20]; >>> + >>> + /* Create a unique device name for PCI type devices */ >>> + if (device_is_on_pci_bus(dev)) { >>> + sprintf(name, "eth_designware#%u", num_cards++); >>> + device_set_name(dev, name); >>> + } >>> +#endif >>> + >>> + return 0; >>> +} >>> + >>> static int designware_eth_probe(struct udevice *dev) >>> { >>> struct eth_pdata *pdata = dev_get_platdata(dev); >>> @@ -565,6 +582,23 @@ static int designware_eth_probe(struct udevice *dev) >>> u32 iobase = pdata->iobase; >>> int ret; >>> >>> +#ifdef CONFIG_DM_PCI >>> + /* >>> + * If we are on PCI bus, either directly attached to a PCI root >>> port, >>> + * or via a PCI bridge, fill in platdata before we probe the >>> hardware. >>> + */ >>> + if (device_is_on_pci_bus(dev)) { >>> + pci_dev_t bdf = pci_get_bdf(dev); >>> + >>> + dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, &iobase); >>> + iobase &= PCI_BASE_ADDRESS_MEM_MASK; >>> + iobase = pci_mem_to_phys(bdf, iobase); >>> + >>> + pdata->iobase = iobase; >>> + pdata->phy_interface = PHY_INTERFACE_MODE_RMII; >>> + } >>> +#endif >>> + >>> debug("%s, iobase=%x, priv=%p\n", __func__, iobase, priv); >>> priv->mac_regs_p = (struct eth_mac_regs *)iobase; >>> priv->dma_regs_p = (struct eth_dma_regs *)(iobase + >>> DW_DMA_BASE_OFFSET); >>> @@ -617,10 +651,18 @@ U_BOOT_DRIVER(eth_designware) = { >>> .id = UCLASS_ETH, >>> .of_match = designware_eth_ids, >>> .ofdata_to_platdata = designware_eth_ofdata_to_platdata, >>> + .bind = designware_eth_bind, >>> .probe = designware_eth_probe, >>> .ops = &designware_eth_ops, >>> .priv_auto_alloc_size = sizeof(struct dw_eth_dev), >>> .platdata_auto_alloc_size = sizeof(struct eth_pdata), >>> .flags = DM_FLAG_ALLOC_PRIV_DMA, >>> }; >>> + >>> +static struct pci_device_id supported[] = { >>> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_QRK_EMAC) }, >>> + { } >> >> Rather than ending up with a table of these device IDs, should this go >> in the device tree? > > I am OK for either way. In fact compared to the widely available PCI > NS16550 devices from many chipset vendors, there are just two or three > PCI variants of designware ethernet devices so far (seen from linux > driver). I guess putting a device ID table here is not that bad.
OK let's revisit it if needed. Applied to u-boot-x86, thanks! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot