summaryrefslogtreecommitdiffstats
path: root/drivers/net/designware_eqos.c
Commit message (Collapse)AuthorAgeFilesLines
* net: designware: eqos: attach PHY earlierLucas Stach2020-05-121-5/+5
| | | | | | | | | | If the PHY isn't driving the refclock, the software reset of the controller will time out. Some PHYs need some board specific configuration to properly drive the reflock. Attach the PHY before attempting the software reset, so PHY fixups have a chance to run. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* net: designware: eqos: mimic Linux gmac4 mdio_{read, write}Ahmad Fatoum2020-03-021-18/+7
| | | | | | | | | | | | | | | The code was ported over from U-Boot and has some things different than the Kernel driver: - It reads ->mdio_address, but the kernel driver doesn't - It doesn't write ->mdio_data in a read, but the kernel driver does - It has delays in addition to spinning on MII_BUSY, but the kernel driver doesn't Adopt the same flow as used by the kernel. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* net: designware: eqos: remove left-over PHY quirk work aroundAhmad Fatoum2020-03-021-6/+2
| | | | | | | | | The dummy read was a left over from an abandoned merge with the existing support for the SoCFPGA variant of the Designware MAC. It doesn't exist in either the U-Boot or kernel drivers for the EQOS, thus drop it. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* net: designware: eqos: don't funnel all MDIO writes to register 0Ahmad Fatoum2020-01-201-3/+3
| | | | | | | | | | | | | | | | eqos_mdio_write ended up using the addr parameter instead of the computed miiaddr variable, which would've factored in the reg parameter. This had the effect that all writes went to PHY register 0, which was fine as long as there were only register 0 writes. As soon there are more writes, e.g. because a PHY driver was enabled, register 0 became clobbered and erratic behavior ensued. Fix the typo and while at it rename the val parameter to a more descriptive name. Fixes: a4f709bbb ("net: add Designware Ethernet QoS for STM32MP") Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* net: designware: eqos: fix NULL pointer use in dev_printfAhmad Fatoum2019-11-151-4/+4
| | | | | | | | | | | Inside mdio_register, a read of the PHY's id register is attempted. If it fails, we print an error message with eqos_err, which uses the ethernet device's unique name, but at this time there has been none set, because eth_register was not yet called. Fix this by using the MDIO bus device instead. Signed-off-by: Ahmad Fatoum <ahmad@a3f.at> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* net: designware: eqos: enable clocks before mdio_registerAhmad Fatoum2019-11-151-4/+4
| | | | | | | | | | | | | | | | | We can't be using the MAC including the MDIO controller while the clocks are off, but this is exactly the case when mdio_register is called and the interface is not yet up. To allow reading the PHY id to succeed before the interface is up, turn on the clocks as part of the initialization in the probe. This fixes following error at probe time: ERROR: <NULL>: MDIO not idle at entry The NULL is fixed in a follow-up commit. Signed-off-by: Ahmad Fatoum <ahmad@a3f.at> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* net: designware: eqos: properly stop DMA on haltAhmad Fatoum2019-11-151-0/+2
| | | | | | | | | Specifying ->halt only means that it's called along with eth_unregister. If we want to halt the DMA, we will have to call it ourselves in the remove callback. Do this. Signed-off-by: Ahmad Fatoum <ahmad@a3f.at> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* net: add Designware Ethernet QoS for STM32MPAhmad Fatoum2019-11-061-0/+876
We already have Designware NIC support in barebox, but for the DWMAC1000, the DWMAC4 (also called GMAC4), no support was mainline so far. The DWMAC4 is different enough that sharing code with the DWMAC1000 is not really that helpful, because even basics like MDIO registers have different layout. Instead of coding bit masks and shifts into the driver data, like Linux does, we'll keep both driver kinds separate. Nevertheless, we collect functions that are not SoC-specific into a separate 'library' file. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>