Commit graph

13 commits

Author SHA1 Message Date
Vladimir Oltean
f27bc8afd5 net: phy: fixed: Be compatible with live OF tree
On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined
as const struct device_node *np, while on the flat DT systems it
is defined as a long of_offset into gd->fdt_blob.

It is desirable that the fixed PHY driver uses the higher-level
ofnode abstraction instead of parsing gd->fdt_blob directly,
because that enables it to work on live OF systems.

The fixed PHY driver has used a nasty hack since its introduction in
commit db40c1aa1c ("drivers/net/phy: add fixed-phy /
fixed-link support"),
which is to pass the long gd->fdt_blob offset inside int phydev->addr
(a value that normally holds the MDIO bus address at which the PHY
responds). Even ignoring the fact that the types were already
mismatched leading to a potential truncation (flat OF offset was
supposed to be a long and not an int), we really cannot extend this
hack any longer, because there's no way an int will hold the other
representation of ofnode, the struct device_node *np.

So we unfortunately need to do the right thing, which is to use the
framework introduced by Grygorii Strashko in
commit eef0b8a930 ("net: phy: add ofnode node to struct phy_device").
This will populate phydev->node for the fixed PHY.

Note that phydev->node will not be valid in the probe function, since
that is called synchronously from phy_device_create and we really have
no way of passing the ofnode directly through the phy_device_create API.
So we do what other drivers do too: we move the OF parsing logic from
the .probe to the .config method of the PHY driver. The new function
will be called at phy_config() time.

I do believe I've converted all the possible call paths for creating
a PHY with PHY_FIXED_ID, so there is really no reason to maintain
compatibility with the old logic of retrieving a flat OF tree offset
from phydev->addr. We just pass 0 to phydev->addr now.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210216224804.3355044-2-olteanv@gmail.com>
[bmeng: keep fixedphy_probe(); update mdio-uclass.c to handle fixed phy]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-04-15 14:22:17 +05:30
Bin Meng
33aad0b092 dm: mdio: Use ofnode_phy_is_fixed_link() API
Switch to use the ofnode_phy_is_fixed_link() API which can support
both the new and old DT bindings.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-04-15 14:22:17 +05:30
Rasmus Villemoes
bdf319273b mdio-uclass.c: support fixed-link subnodes
When trying to port our mpc8309-based board to DM_ETH, on top of
Heiko's patches, I found that nothing in mdio-uclass.c seems to
support the use of a fixed-link subnode of the ethernet DT node. That
is, the ethernet node looks like

		enet0: ethernet@2000 {
			device_type = "network";
			compatible = "ucc_geth";
			...
			fixed-link {
				reg = <0xffffffff>;
				speed = <100>;
				full-duplex;
			};

but the current code expects there to be phy-handle property. Adding
that, i.e.

			phy-handle = <&enet0phy>;
			enet0phy: fixed-link {

just makes the code break a few lines later since a fixed-link node
doesn't have a reg property. Ignoring the dtc complaint and adding a
dummy reg property, we of course hit "can't find MDIO bus for node
ethernet@2000" since indeed, the parent node of the phy node does not
represent an MDIO bus. So that's obviously the wrong path.

Now, in linux, it seems that the fixed link case is treated specially;
in the of_phy_get_and_connect() which roughly corresponds to
dm_eth_connect_phy_handle() we have

    if (of_phy_is_fixed_link(np)) {
        ret = of_phy_register_fixed_link(np);
        ...
    } else {
        phy_np = of_parse_phandle(np, "phy-handle", 0);
	...
    }

    phy = of_phy_connect(dev, phy_np, hndlr, 0, iface);

And U-Boot's phy_connect() does have support for fixed-link
subnodes. Calling phy_connect() directly with NULL bus and a dummy
address does seem to make the ethernet work.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Heiko Schocher <hs@denx.de>
2021-02-21 18:46:41 -05:00
Simon Glass
f10643cf8a dm: core: Access device ofnode through functions
At present ofnode is present in the device even if it is never used. With
of-platdata this field is not used, so can be removed. In preparation for
this, change the access to go through inline functions.

Signed-off-by: Simon Glass <sjg@chromium.org>
2021-01-05 12:24:41 -07:00
Simon Glass
41575d8e4c dm: treewide: Rename auto_alloc_size members to be shorter
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-13 08:00:25 -07:00
Sean Anderson
0851bd1e75 net: mdio: Fix not calling dev_dbg with a device
The name of the device we are working on is `ethdev` and not just `dev`.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-09-30 08:53:06 -04:00
Simon Glass
f7ae49fc4f common: Drop log.h from common header
Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:18 -04:00
Simon Glass
336d4615f8 dm: core: Create a new header file for 'compat' features
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05 19:33:46 -07:00
Alex Marginean
2f6245594e net: mdio-uclass: add dm_eth_phy_connect helper function
The function connects an ethernet device to a PHY using DT information.
This API is only available for eth devices with an associated device tree
node.

Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2019-12-09 09:47:43 -06:00
Alex Marginean
a5d32c37d9 net: mdio-uclass: rename arguments of dm_mdio_phy_connect for clarity
Renamed dm_mdio_phy_connect arguments dev to mdiodev and addr to phyaddr
for a bit more clarity and consistency with the following patches.
Also use NULL instead of 0 on error return path.

Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2019-12-09 09:47:43 -06:00
Alex Marginean
6b3abc0482 net: mdio-uclass: name MDIO according to device-name property if preset
Use the optional property device-name to name the MDIO bus.  This works
around limitations with using the DT node name on devices such as
Armada-8040, which integrates two cp100 cores, both featuring MDIOs at the
same relative offsets and with the same DT node names.
The concept was originally proposed by Marvell as a custom property called
mdio-name specific to Marvell driver.  This patch uses the more generic
property device-name and moves this into MDIO class code so other can use
it as well.

Signed-off-by: Alex Marginean <alexm.osslist@gmail.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-04 11:37:19 -05:00
Joe Hershberger
398e7512d8 net: Fix Covarity Defect 244093
Don't allow unterminated strings

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
2019-09-04 11:37:18 -05:00
Alex Marginean
c3452b50c3 net: introduce MDIO DM class for MDIO devices
Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as
stand-alone devices.  Useful in particular for systems that support
DM_ETH and have a stand-alone MDIO hardware block shared by multiple
Ethernet interfaces.

Signed-off-by: Alex Marginean <alexm.osslist@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2019-07-15 13:32:25 -05:00