| Message ID | 1393930704-24374-4-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
Hi Thomas, 2014-03-04 2:58 GMT-08:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Some Ethernet MACs have a "fixed link", and are not connected to a > normal MDIO-managed PHY device. For those situations, a Device Tree > binding allows to describe a "fixed link" using a special PHY node. > > This patch adds: > > * A documentation for the fixed PHY Device Tree binding. > > * An of_phy_is_fixed_link() function that an Ethernet driver can call > on its PHY phandle to find out whether it's a fixed link PHY or > not. It should typically be used to know if > of_phy_register_fixed_link() should be called. > > * An of_phy_register_fixed_link() function that instantiates the > fixed PHY into the PHY subsystem, so that when the driver calls > of_phy_connect(), the PHY device associated to the OF node will be > found. I have a better understanding of why Grant objected last time, and I just found yet another argument which should hopefully be in favor of this new binding. One of the problems mentioned earlier about the 'fixed-link' 5-digit property is that it is inflexible. It turns out that it seems to capture everything we need, as nobody needed to extend it with a 6th type for instance. This new binding allows for more flexibility and is more human readable, which is a net bonus, though not a compelling reason (yet). Another problem with that "old" 'fixed-link' property is that we are not properly capturing and representing Ethernet switches/PHYs whose data-path are isolated from the control path. For instance such devices will traditionally expose their control path as a MMIO/GPIO/I2C/SPI interface. Using the 5-digit 'fixed-link' property we are not representing this, on one side the Ethernet MAC is just told to hardcode the link parameters with some parameters, and on other side, any MMIO/GPIO/I2C/SPI device is not equipped with the correct properties to express the fact that is also has a data-path connected to an Ethernet MAC. What I like about this new binding is that we could place the 'fixed-link' related properties in e.g: a SPI slave node, and have the Ethernet MAC be pointed at it by a phandle to tell it: look this is your PHY, it might not be one you could address on a MDIO bus, so I have been providing additional properties to help you with the link configuration. One thing that needs to be addressed in this patch is how to deal with the existing 5-digit fixed-link, something that sounds fairly easy and which would not require changing the callers of of_phy_connect_fixed() is to do the following: - of_phy_is_fixed_link() needs to look for *all* required compatible properties of the new binding to give an accurate verdict on the nature of the PHY (to avoid false positives as mentioned in PATCH 4), and it also needs to look for the 5-digit fixed-link property and ensure the property is 5-digits long if existing - of_phy_register_fixed_link() needs to also parse the old 5-digit fixed-link property, most likely just copy-pasting what arch/powerpc/sysdev/fsl_soc.c::of_add_fixed_phys does with the property endian-swapping (as this code is for PowerPC) Then we can deal with how to make that semi-automatic for the new binding users to make it smoother to use a regular or "fixed PHY" device. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > --- > .../devicetree/bindings/net/fixed-link.txt | 34 ++++++++++++++++++++++ > drivers/of/of_mdio.c | 24 +++++++++++++++ > include/linux/of_mdio.h | 15 ++++++++++ > 3 files changed, 73 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt > > diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt > new file mode 100644 > index 0000000..9f2a1a50 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/fixed-link.txt > @@ -0,0 +1,34 @@ > +Fixed link Device Tree binding > +------------------------------ > + > +Some Ethernet MACs have a "fixed link", and are not connected to a > +normal MDIO-managed PHY device. For those situations, a Device Tree > +binding allows to describe a "fixed link". > + > +Such a fixed link situation is described by creating a PHY node as a > +sub-node of an Ethernet device, with the following properties: > + > +* 'fixed-link' (boolean, mandatory), to indicate that this PHY is a > + fixed link PHY. > +* 'speed' (integer, mandatory), to indicate the link speed. Accepted > + values are 10, 100 and 1000 > +* 'full-duplex' (boolean, optional), to indicate that full duplex is > + used. When absent, half duplex is assumed. > +* 'pause' (boolean, optional), to indicate that pause should be > + enabled. > +* 'asym-pause' (boolean, optional), to indicate that asym_pause should > + be enabled. > + > +Example: > + > +ethernet@0 { > + ... > + phy = <&phy0>; > + phy0: phy@0 { > + fixed-link; > + speed = <1000>; > + full-duplex; > + }; > + ... > +}; > + > diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c > index 875b7b6..c645fb8 100644 > --- a/drivers/of/of_mdio.c > +++ b/drivers/of/of_mdio.c > @@ -14,6 +14,7 @@ > #include <linux/netdevice.h> > #include <linux/err.h> > #include <linux/phy.h> > +#include <linux/phy_fixed.h> > #include <linux/of.h> > #include <linux/of_irq.h> > #include <linux/of_mdio.h> > @@ -274,3 +275,26 @@ struct phy_device *of_phy_attach(struct net_device *dev, > return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy; > } > EXPORT_SYMBOL(of_phy_attach); > + > +#if defined(CONFIG_FIXED_PHY) > +bool of_phy_is_fixed_link(struct device_node *np) > +{ > + return of_property_read_bool(np, "fixed-link"); > +} > +EXPORT_SYMBOL(of_phy_is_fixed_link); > + > +int of_phy_register_fixed_link(struct device_node *np) > +{ > + struct fixed_phy_status status = {}; > + > + status.link = 1; > + status.duplex = of_property_read_bool(np, "full-duplex"); > + if (of_property_read_u32(np, "speed", &status.speed)) > + return -EINVAL; > + status.pause = of_property_read_bool(np, "pause"); > + status.asym_pause = of_property_read_bool(np, "asym-pause"); > + > + return fixed_phy_register(PHY_POLL, &status, np); > +} > +EXPORT_SYMBOL(of_phy_register_fixed_link); > +#endif > diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h > index 6fe8464..77a6e32 100644 > --- a/include/linux/of_mdio.h > +++ b/include/linux/of_mdio.h > @@ -67,4 +67,19 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np) > } > #endif /* CONFIG_OF */ > > +#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY) > +extern int of_phy_register_fixed_link(struct device_node *np); > +extern bool of_phy_is_fixed_link(struct device_node *np); > +#else > +static inline int of_phy_register_fixed_link(struct device_node *np) > +{ > + return -ENOSYS; > +} > +static inline bool of_phy_is_fixed_link(struct device_node *np) > +{ > + return false; > +} > +#endif > + > + > #endif /* __LINUX_OF_MDIO_H */ > -- > 1.8.3.2
Dear Florian Fainelli, On Tue, 4 Mar 2014 12:58:41 -0800, Florian Fainelli wrote: > What I like about this new binding is that we could place the > 'fixed-link' related properties in e.g: a SPI slave node, and have the > Ethernet MAC be pointed at it by a phandle to tell it: look this is > your PHY, it might not be one you could address on a MDIO bus, so I > have been providing additional properties to help you with the link > configuration. > > One thing that needs to be addressed in this patch is how to deal with > the existing 5-digit fixed-link, something that sounds fairly easy and > which would not require changing the callers of of_phy_connect_fixed() > is to do the following: I am not sure to understand "would not require changing the callers of of_phy_connect_fixed()". This function is precisely introduced by the patch set, so how would we need to "change the callers" ? Maybe you're making a confusion with the existing of_phy_connect_fixed_link(), which is used by network drivers to create a PHY using the old-style fixed-link = <5 digits> binding ? > - of_phy_is_fixed_link() needs to look for *all* required compatible > properties of the new binding to give an accurate verdict on the > nature of the PHY (to avoid false positives as mentioned in PATCH 4), Hum? The false positive problem only exists if you want to automatically instantiate the fixed PHYs, as I proposed in a patch as a reply to my series. And checking for *all* required properties does not make the problem better: you could very well have other nodes in the tree that have a "fixed-link" and a "speed" property, for example. > and it also needs to look for the 5-digit fixed-link property and > ensure the property is 5-digits long if existing I don't understand how this could work. The of_phy_is_fixed_link() function is meant to take as argument a Device Tree node that describes a fixed PHY, using the new proposed DT binding for fixed PHYs. The old 'fixed-link' binding has the fixed-link property as part of the Ethernet node itself. So I don't really see how a sane function could check both. > - of_phy_register_fixed_link() needs to also parse the old 5-digit > fixed-link property, most likely just copy-pasting what > arch/powerpc/sysdev/fsl_soc.c::of_add_fixed_phys does with the > property endian-swapping (as this code is for PowerPC) > > Then we can deal with how to make that semi-automatic for the new > binding users to make it smoother to use a regular or "fixed PHY" > device. I still don't understand. With the old binding, the "fixed-link" property is within some random Ethernet node, and there is no way for us to find out whether a given node having a "fixed-link" property corresponds to a fixed PHY, or something completely unrelated. So to conclude, I'm sorry, but I didn't understand at all what you meant to say here, so I'm completely puzzled about what your suggestions are. Best regards, Thomas
2014-03-05 1:24 GMT-08:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Florian Fainelli, > > On Tue, 4 Mar 2014 12:58:41 -0800, Florian Fainelli wrote: > > >> What I like about this new binding is that we could place the >> 'fixed-link' related properties in e.g: a SPI slave node, and have the >> Ethernet MAC be pointed at it by a phandle to tell it: look this is >> your PHY, it might not be one you could address on a MDIO bus, so I >> have been providing additional properties to help you with the link >> configuration. >> >> One thing that needs to be addressed in this patch is how to deal with >> the existing 5-digit fixed-link, something that sounds fairly easy and >> which would not require changing the callers of of_phy_connect_fixed() >> is to do the following: > > I am not sure to understand "would not require changing the callers of > of_phy_connect_fixed()". This function is precisely introduced by the > patch set, so how would we need to "change the callers" ? Maybe you're > making a confusion with the existing of_phy_connect_fixed_link(), which > is used by network drivers to create a PHY using the old-style > fixed-link = <5 digits> binding ? I meant to write of_phy_connect_fixed_link() here. > >> - of_phy_is_fixed_link() needs to look for *all* required compatible >> properties of the new binding to give an accurate verdict on the >> nature of the PHY (to avoid false positives as mentioned in PATCH 4), > > Hum? > > The false positive problem only exists if you want to automatically > instantiate the fixed PHYs, as I proposed in a patch as a reply to my > series. And checking for *all* required properties does not make the > problem better: you could very well have other nodes in the tree that > have a "fixed-link" and a "speed" property, for example. Correct, but that means there is probably something missing here to uniquely identify this type of fixed PHYs then. 'fixed-link' could indeed be too generic, so we need to find a better name which is guaranteed to be unique to our use-case here. You offered a compatible string solution earlier, I am not sure that will fly very well too as we would need to keep an ever-growing list of special devices. > >> and it also needs to look for the 5-digit fixed-link property and >> ensure the property is 5-digits long if existing > > I don't understand how this could work. The of_phy_is_fixed_link() > function is meant to take as argument a Device Tree node that describes > a fixed PHY, using the new proposed DT binding for fixed PHYs. > > The old 'fixed-link' binding has the fixed-link property as part of the > Ethernet node itself. The drivers using the 5-digit 'fixed-link' property already have that knowledge, so they can call of_phy_is_fixed_link() with a Ethernet Device Tree node argument, whereas newer driver using the new binding would call you with a phandle device tree node. This makes no difference for your specific function which will return a verdict. Once we know that we are dealing with such a fixed PHY, we can call of_phy_register_fixed_link() which will do what arch/powerpc/sysdev/fsl_soc.c::of_add_fixed_phys does today, except that it will be for users beyond PowerPC (e.g: bcmgenet). > > So I don't really see how a sane function could check both. Something like: int sz; of_property_read_bool(np, "fixed-link") || (of_get_property(np, "fixed-link", &sz) && sz == sizeof(u32) * 5); The key point is that drivers using the "old" 5-digit 'fixed-link' already know that their 'fixed-link' property belongs to their Ethernet Device Tree node. > >> - of_phy_register_fixed_link() needs to also parse the old 5-digit >> fixed-link property, most likely just copy-pasting what >> arch/powerpc/sysdev/fsl_soc.c::of_add_fixed_phys does with the >> property endian-swapping (as this code is for PowerPC) >> >> Then we can deal with how to make that semi-automatic for the new >> binding users to make it smoother to use a regular or "fixed PHY" >> device. > > I still don't understand. With the old binding, the "fixed-link" > property is within some random Ethernet node, and there is no way for > us to find out whether a given node having a "fixed-link" property > corresponds to a fixed PHY, or something completely unrelated. By then, I meant, once we have sorted out that specific patchset, we can try to work on a solution to make > > So to conclude, I'm sorry, but I didn't understand at all what you > meant to say here, so I'm completely puzzled about what your > suggestions are. > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com
On Tue, 4 Mar 2014 11:58:23 +0100, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Some Ethernet MACs have a "fixed link", and are not connected to a > normal MDIO-managed PHY device. For those situations, a Device Tree > binding allows to describe a "fixed link" using a special PHY node. > > This patch adds: > > * A documentation for the fixed PHY Device Tree binding. > > * An of_phy_is_fixed_link() function that an Ethernet driver can call > on its PHY phandle to find out whether it's a fixed link PHY or > not. It should typically be used to know if > of_phy_register_fixed_link() should be called. > > * An of_phy_register_fixed_link() function that instantiates the > fixed PHY into the PHY subsystem, so that when the driver calls > of_phy_connect(), the PHY device associated to the OF node will be > found. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > --- > .../devicetree/bindings/net/fixed-link.txt | 34 ++++++++++++++++++++++ > drivers/of/of_mdio.c | 24 +++++++++++++++ > include/linux/of_mdio.h | 15 ++++++++++ > 3 files changed, 73 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt > > diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt > new file mode 100644 > index 0000000..9f2a1a50 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/fixed-link.txt > @@ -0,0 +1,34 @@ > +Fixed link Device Tree binding > +------------------------------ > + > +Some Ethernet MACs have a "fixed link", and are not connected to a > +normal MDIO-managed PHY device. For those situations, a Device Tree > +binding allows to describe a "fixed link". > + > +Such a fixed link situation is described by creating a PHY node as a > +sub-node of an Ethernet device, with the following properties: > + > +* 'fixed-link' (boolean, mandatory), to indicate that this PHY is a > + fixed link PHY. > +* 'speed' (integer, mandatory), to indicate the link speed. Accepted > + values are 10, 100 and 1000 > +* 'full-duplex' (boolean, optional), to indicate that full duplex is > + used. When absent, half duplex is assumed. > +* 'pause' (boolean, optional), to indicate that pause should be > + enabled. > +* 'asym-pause' (boolean, optional), to indicate that asym_pause should > + be enabled. > + > +Example: > + > +ethernet@0 { > + ... > + phy = <&phy0>; > + phy0: phy@0 { > + fixed-link; > + speed = <1000>; > + full-duplex; > + }; The phy phandle to a child node is superfluous. A phandle to a fixed child node doesn't make a whole lot of sense. You've worn me down though. I'll ack the binding with a few tweaks in usage. This binding provides a direct super-set of the old fixed-link property binding. There should be a single function for parsing it. That way we can allow the new behaviour on drivers using the old. The new binding should be preferred over the old. ie. a call to of_phy_is_fixed_link() should look for a fixed link node first, followed by the older property version. There should be a strong recommendation for the child node name. Make it "fixed-link". The only reason a device should ever deviate from that is if it has multiple links that all need to be processed. If anyone complains that "fixed-link" is ambiguous, then perhaps "mii-fixed-link" would be better. I don't see a problem though. There should be no address portion in the node name. It isn't a child device, the node is merely more configuration data for the parent. Example: ethernet@0 { ... fixed-link { speed = <1000>; full-duplex; }; g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear Grant Likely, Sorry for bringing back this old topic, but I'm working on this again, hopefully reaching an acceptable solution this time. One question for you below. On Sat, 08 Mar 2014 05:50:33 +0000, Grant Likely wrote: > > +Example: > > + > > +ethernet@0 { > > + ... > > + phy = <&phy0>; > > + phy0: phy@0 { > > + fixed-link; > > + speed = <1000>; > > + full-duplex; > > + }; > > The phy phandle to a child node is superfluous. A phandle to a fixed > child node doesn't make a whole lot of sense. [...] > There should be no address portion in the node name. It isn't a child > device, the node is merely more configuration data for the parent. > > Example: > > ethernet@0 { > ... > fixed-link { > speed = <1000>; > full-duplex; > }; For my current use case, I'm personally fine with that. But that doesn't work well with Florian Fainelli's which to potentially have the "fixed-link" node as part of another node in the DT, in the case the PHY is configurable through some separate SPI/I2C bus. See his comment in http://article.gmane.org/gmane.linux.network/306789: """ Another problem with that "old" 'fixed-link' property is that we are not properly capturing and representing Ethernet switches/PHYs whose data-path are isolated from the control path. For instance such devices will traditionally expose their control path as a MMIO/GPIO/I2C/SPI interface. Using the 5-digit 'fixed-link' property we are not representing this, on one side the Ethernet MAC is just told to hardcode the link parameters with some parameters, and on other side, any MMIO/GPIO/I2C/SPI device is not equipped with the correct properties to express the fact that is also has a data-path connected to an Ethernet MAC. What I like about this new binding is that we could place the 'fixed-link' related properties in e.g: a SPI slave node, and have the Ethernet MAC be pointed at it by a phandle to tell it: look this is your PHY, it might not be one you could address on a MDIO bus, so I have been providing additional properties to help you with the link configuration. """ What is your opinion about this? Thanks, Thomas
Hi Thomas, 2014-05-15 6:39 GMT-07:00 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Grant Likely, > > Sorry for bringing back this old topic, but I'm working on this again, > hopefully reaching an acceptable solution this time. One question for > you below. > > On Sat, 08 Mar 2014 05:50:33 +0000, Grant Likely wrote: > >> > +Example: >> > + >> > +ethernet@0 { >> > + ... >> > + phy = <&phy0>; >> > + phy0: phy@0 { >> > + fixed-link; >> > + speed = <1000>; >> > + full-duplex; >> > + }; >> >> The phy phandle to a child node is superfluous. A phandle to a fixed >> child node doesn't make a whole lot of sense. > > [...] > >> There should be no address portion in the node name. It isn't a child >> device, the node is merely more configuration data for the parent. >> >> Example: >> >> ethernet@0 { >> ... >> fixed-link { >> speed = <1000>; >> full-duplex; >> }; > > For my current use case, I'm personally fine with that. But that > doesn't work well with Florian Fainelli's which to potentially have the > "fixed-link" node as part of another node in the DT, in the case the > PHY is configurable through some separate SPI/I2C bus. See his comment > in http://article.gmane.org/gmane.linux.network/306789: I just re-read Grant's comments, and I don't think we contradict with each other here. Since the data-path is symetrical by nature, whether you place the 'fixed-link' property on one end (Ethernet MAC) or the other (SPI/I2C/GPIO node) does make a huge difference, except you want it to be placed where it makes the most sense: in the Ethernet MAC node. Properties like the speed, duplex, pause are definitively Ethernet MAC only properties. In case we need to specifically associate these two nodes with each other, a phandle property to the Ethernet MAC node, or e.g: the SPI node can be used. That said, I think we should go with Grant's proposal of having the following representation: ethernet@0 { ... fixed-link { speed = <1000>; full-duplex; }; we might want to use 'max-speed' instead of speed, but that's debatable. > > """ > Another problem with that "old" 'fixed-link' property is that we are > not properly capturing and representing Ethernet switches/PHYs whose > data-path are isolated from the control path. For instance such > devices will traditionally expose their control path as a > MMIO/GPIO/I2C/SPI interface. Using the 5-digit 'fixed-link' property > we are not representing this, on one side the Ethernet MAC is just > told to hardcode the link parameters with some parameters, and on > other side, any MMIO/GPIO/I2C/SPI device is not equipped with the > correct properties to express the fact that is also has a data-path > connected to an Ethernet MAC. > > What I like about this new binding is that we could place the > 'fixed-link' related properties in e.g: a SPI slave node, and have the > Ethernet MAC be pointed at it by a phandle to tell it: look this is > your PHY, it might not be one you could address on a MDIO bus, so I > have been providing additional properties to help you with the link > configuration. > """ > > What is your opinion about this? > > Thanks, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt new file mode 100644 index 0000000..9f2a1a50 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fixed-link.txt @@ -0,0 +1,34 @@ +Fixed link Device Tree binding +------------------------------ + +Some Ethernet MACs have a "fixed link", and are not connected to a +normal MDIO-managed PHY device. For those situations, a Device Tree +binding allows to describe a "fixed link". + +Such a fixed link situation is described by creating a PHY node as a +sub-node of an Ethernet device, with the following properties: + +* 'fixed-link' (boolean, mandatory), to indicate that this PHY is a + fixed link PHY. +* 'speed' (integer, mandatory), to indicate the link speed. Accepted + values are 10, 100 and 1000 +* 'full-duplex' (boolean, optional), to indicate that full duplex is + used. When absent, half duplex is assumed. +* 'pause' (boolean, optional), to indicate that pause should be + enabled. +* 'asym-pause' (boolean, optional), to indicate that asym_pause should + be enabled. + +Example: + +ethernet@0 { + ... + phy = <&phy0>; + phy0: phy@0 { + fixed-link; + speed = <1000>; + full-duplex; + }; + ... +}; + diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c index 875b7b6..c645fb8 100644 --- a/drivers/of/of_mdio.c +++ b/drivers/of/of_mdio.c @@ -14,6 +14,7 @@ #include <linux/netdevice.h> #include <linux/err.h> #include <linux/phy.h> +#include <linux/phy_fixed.h> #include <linux/of.h> #include <linux/of_irq.h> #include <linux/of_mdio.h> @@ -274,3 +275,26 @@ struct phy_device *of_phy_attach(struct net_device *dev, return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy; } EXPORT_SYMBOL(of_phy_attach); + +#if defined(CONFIG_FIXED_PHY) +bool of_phy_is_fixed_link(struct device_node *np) +{ + return of_property_read_bool(np, "fixed-link"); +} +EXPORT_SYMBOL(of_phy_is_fixed_link); + +int of_phy_register_fixed_link(struct device_node *np) +{ + struct fixed_phy_status status = {}; + + status.link = 1; + status.duplex = of_property_read_bool(np, "full-duplex"); + if (of_property_read_u32(np, "speed", &status.speed)) + return -EINVAL; + status.pause = of_property_read_bool(np, "pause"); + status.asym_pause = of_property_read_bool(np, "asym-pause"); + + return fixed_phy_register(PHY_POLL, &status, np); +} +EXPORT_SYMBOL(of_phy_register_fixed_link); +#endif diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h index 6fe8464..77a6e32 100644 --- a/include/linux/of_mdio.h +++ b/include/linux/of_mdio.h @@ -67,4 +67,19 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np) } #endif /* CONFIG_OF */ +#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY) +extern int of_phy_register_fixed_link(struct device_node *np); +extern bool of_phy_is_fixed_link(struct device_node *np); +#else +static inline int of_phy_register_fixed_link(struct device_node *np) +{ + return -ENOSYS; +} +static inline bool of_phy_is_fixed_link(struct device_node *np) +{ + return false; +} +#endif + + #endif /* __LINUX_OF_MDIO_H */
Some Ethernet MACs have a "fixed link", and are not connected to a normal MDIO-managed PHY device. For those situations, a Device Tree binding allows to describe a "fixed link" using a special PHY node. This patch adds: * A documentation for the fixed PHY Device Tree binding. * An of_phy_is_fixed_link() function that an Ethernet driver can call on its PHY phandle to find out whether it's a fixed link PHY or not. It should typically be used to know if of_phy_register_fixed_link() should be called. * An of_phy_register_fixed_link() function that instantiates the fixed PHY into the PHY subsystem, so that when the driver calls of_phy_connect(), the PHY device associated to the OF node will be found. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- .../devicetree/bindings/net/fixed-link.txt | 34 ++++++++++++++++++++++ drivers/of/of_mdio.c | 24 +++++++++++++++ include/linux/of_mdio.h | 15 ++++++++++ 3 files changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt