[PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[Stas Sergeev]

Currently for fixed-link the MAC driver decides whether to use the
link status auto-negotiation or not.
Unfortunately the auto-negotiation may not work when expected by
the MAC driver. Sebastien Rannou explains:
<< Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
inband status) is connected to the switch through QSGMII, and in this context
we are on the media side of the PHY. >>
https://lkml.org/lkml/2015/7/10/206

This patch introduces the new boolean property 'autoneg' that allows
the user to request the auto-negotiation explicitly.

Signed-off-by: Stas Sergeev <stsp-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>

CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
CC: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
CC: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
CC: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
CC: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 .../devicetree/bindings/net/fixed-link.txt         |  6 +++++-
 drivers/of/of_mdio.c                               | 23 ++++++++++++++++++++--
 include/linux/of_mdio.h                            |  5 +++++
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
index 82bf7e0..e2959a8 100644
--- a/Documentation/devicetree/bindings/net/fixed-link.txt
+++ b/Documentation/devicetree/bindings/net/fixed-link.txt
@@ -9,8 +9,12 @@ Such a fixed link situation is described by creating a 'fixed-link'
 sub-node of the Ethernet MAC device node, with the following
 properties:

+* 'autoneg' (boolean, optional), to enable the auto-negotiation of link
+  state. Auto-negotiation is MII protocol, HW and driver-specific and is
+  not supported in many cases, so use it only when you know what you do.
 * 'speed' (integer, mandatory), to indicate the link speed. Accepted
-  values are 10, 100 and 1000
+  values are 10, 100 and 1000. If the auto-negotiation is enabled,
+  'speed' may not be set. It will then be auto-negotiated, if possible.
 * '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
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 1bd4305..12b2ede 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -280,6 +280,22 @@ bool of_phy_is_fixed_link(struct device_node *np)
 }
 EXPORT_SYMBOL(of_phy_is_fixed_link);

+bool of_phy_is_autoneg_link(struct device_node *np)
+{
+	struct device_node *dn;
+	bool ret;
+
+	dn = of_get_child_by_name(np, "fixed-link");
+	if (!dn)
+		return false;
+
+	ret = of_property_read_bool(dn, "autoneg");
+
+	of_node_put(dn);
+	return ret;
+}
+EXPORT_SYMBOL(of_phy_is_autoneg_link);
+
 int of_phy_register_fixed_link(struct device_node *np)
 {
 	struct fixed_phy_status status = {};
@@ -291,10 +307,13 @@ int of_phy_register_fixed_link(struct device_node *np)
 	/* New binding */
 	fixed_link_node = of_get_child_by_name(np, "fixed-link");
 	if (fixed_link_node) {
-		status.link = 1;
+		bool autoneg = of_property_read_bool(fixed_link_node,
+						     "autoneg");
+		status.link = !autoneg;
 		status.duplex = of_property_read_bool(fixed_link_node,
 						      "full-duplex");
-		if (of_property_read_u32(fixed_link_node, "speed", &status.speed))
+		if (of_property_read_u32(fixed_link_node, "speed",
+					 &status.speed) != 0 && !autoneg)
 			return -EINVAL;
 		status.pause = of_property_read_bool(fixed_link_node, "pause");
 		status.asym_pause = of_property_read_bool(fixed_link_node,
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index d449018..647f348 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -65,6 +65,7 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
 #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);
+extern bool of_phy_is_autoneg_link(struct device_node *np);
 #else
 static inline int of_phy_register_fixed_link(struct device_node *np)
 {
@@ -74,6 +75,10 @@ static inline bool of_phy_is_fixed_link(struct device_node *np)
 {
 	return false;
 }
+static inline bool of_phy_is_autoneg_link(struct device_node *np)
+{
+	return false;
+}
 #endif


-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[Florian Fainelli]

On 10/07/15 09:43, Stas Sergeev wrote:
> 
> Currently for fixed-link the MAC driver decides whether to use the
> link status auto-negotiation or not.
> Unfortunately the auto-negotiation may not work when expected by
> the MAC driver. Sebastien Rannou explains:
> << Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
> a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
> inband status) is connected to the switch through QSGMII, and in this context
> we are on the media side of the PHY. >>
> https://lkml.org/lkml/2015/7/10/206
> 
> This patch introduces the new boolean property 'autoneg' that allows
> the user to request the auto-negotiation explicitly.

The implementation looks better, but the name might still be slightly
controversial. I would go with "use-in-band-status" which is more
strictly defined than "autoneg" which could mean anything and everything.

What do you think?

> 
> Signed-off-by: Stas Sergeev <stsp@users.sourceforge.net>
> 
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Pawel Moll <pawel.moll@arm.com>
> CC: Mark Rutland <mark.rutland@arm.com>
> CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
> CC: Kumar Gala <galak@codeaurora.org>
> CC: Florian Fainelli <f.fainelli@gmail.com>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: devicetree@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> CC: netdev@vger.kernel.org
> ---
>  .../devicetree/bindings/net/fixed-link.txt         |  6 +++++-
>  drivers/of/of_mdio.c                               | 23 ++++++++++++++++++++--
>  include/linux/of_mdio.h                            |  5 +++++
>  3 files changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
> index 82bf7e0..e2959a8 100644
> --- a/Documentation/devicetree/bindings/net/fixed-link.txt
> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
> @@ -9,8 +9,12 @@ Such a fixed link situation is described by creating a 'fixed-link'
>  sub-node of the Ethernet MAC device node, with the following
>  properties:
> 
> +* 'autoneg' (boolean, optional), to enable the auto-negotiation of link
> +  state. Auto-negotiation is MII protocol, HW and driver-specific and is
> +  not supported in many cases, so use it only when you know what you do.
>  * 'speed' (integer, mandatory), to indicate the link speed. Accepted
> -  values are 10, 100 and 1000
> +  values are 10, 100 and 1000. If the auto-negotiation is enabled,
> +  'speed' may not be set. It will then be auto-negotiated, if possible.
>  * '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
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 1bd4305..12b2ede 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -280,6 +280,22 @@ bool of_phy_is_fixed_link(struct device_node *np)
>  }
>  EXPORT_SYMBOL(of_phy_is_fixed_link);
> 
> +bool of_phy_is_autoneg_link(struct device_node *np)
> +{
> +	struct device_node *dn;
> +	bool ret;
> +
> +	dn = of_get_child_by_name(np, "fixed-link");
> +	if (!dn)
> +		return false;
> +
> +	ret = of_property_read_bool(dn, "autoneg");
> +
> +	of_node_put(dn);
> +	return ret;
> +}
> +EXPORT_SYMBOL(of_phy_is_autoneg_link);
> +
>  int of_phy_register_fixed_link(struct device_node *np)
>  {
>  	struct fixed_phy_status status = {};
> @@ -291,10 +307,13 @@ int of_phy_register_fixed_link(struct device_node *np)
>  	/* New binding */
>  	fixed_link_node = of_get_child_by_name(np, "fixed-link");
>  	if (fixed_link_node) {
> -		status.link = 1;
> +		bool autoneg = of_property_read_bool(fixed_link_node,
> +						     "autoneg");
> +		status.link = !autoneg;
>  		status.duplex = of_property_read_bool(fixed_link_node,
>  						      "full-duplex");
> -		if (of_property_read_u32(fixed_link_node, "speed", &status.speed))
> +		if (of_property_read_u32(fixed_link_node, "speed",
> +					 &status.speed) != 0 && !autoneg)
>  			return -EINVAL;
>  		status.pause = of_property_read_bool(fixed_link_node, "pause");
>  		status.asym_pause = of_property_read_bool(fixed_link_node,
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index d449018..647f348 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -65,6 +65,7 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
>  #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);
> +extern bool of_phy_is_autoneg_link(struct device_node *np);
>  #else
>  static inline int of_phy_register_fixed_link(struct device_node *np)
>  {
> @@ -74,6 +75,10 @@ static inline bool of_phy_is_fixed_link(struct device_node *np)
>  {
>  	return false;
>  }
> +static inline bool of_phy_is_autoneg_link(struct device_node *np)
> +{
> +	return false;
> +}
>  #endif
> 
> 


-- 
Florian

Re: [PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[Stas Sergeev]

10.07.2015 21:37, Florian Fainelli пишет:
> On 10/07/15 09:43, Stas Sergeev wrote:
>> Currently for fixed-link the MAC driver decides whether to use the
>> link status auto-negotiation or not.
>> Unfortunately the auto-negotiation may not work when expected by
>> the MAC driver. Sebastien Rannou explains:
>> << Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
>> a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
>> inband status) is connected to the switch through QSGMII, and in this context
>> we are on the media side of the PHY. >>
>> https://lkml.org/lkml/2015/7/10/206
>>
>> This patch introduces the new boolean property 'autoneg' that allows
>> the user to request the auto-negotiation explicitly.
> The implementation looks better, but the name might still be slightly
> controversial. I would go with "use-in-band-status" which is more
> strictly defined than "autoneg" which could mean anything and everything.
>
> What do you think?
I actually think autoneg is a bit better.

- Autonegotiation is a widely used and known term:
https://en.wikipedia.org/wiki/Autonegotiation
And who knows what in-band status is?
And, more importantly, who knows what is it used for?
Who even knows it is used for autonegotiation?

- When we set autoneg for fixed-link, we basically just
say "no MDIO here, but please do autoneg by any other
means, if possible".

- in-band status is an implementation delail, and it is
specific to a particular protocols. If you request the
in-band status for some protocol that doesn't support
it, perhaps you should get -EINVAL, because such a
config makes no sense. With autonegotiation, the rules
are not that strict: it can be "unimplemented", which doesn't
necessary mean nonsense in the config.

- autonegotiation is a wider term, and may be implemented
by some other means than the in-band status (which is
probably impossible for a fixed-link though).

- In the terms that the driver uses, it is autonegotiation, eg
MVNETA_GMAC_AUTONEG_CONFIG. And when you go down
the implementation details, you see MVNETA_GMAC_INBAND_AN_ENABLE,
which is just one AN bit of many.

So I really would prefer to keep things as is.
But if you insist, I can rename, but there will still be no
-EINVAL checks for obviously wrong configs.

Re: [PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[Florian Fainelli]

On 10/07/15 13:08, Stas Sergeev wrote:
> 10.07.2015 21:37, Florian Fainelli пишет:
>> On 10/07/15 09:43, Stas Sergeev wrote:
>>> Currently for fixed-link the MAC driver decides whether to use the
>>> link status auto-negotiation or not.
>>> Unfortunately the auto-negotiation may not work when expected by
>>> the MAC driver. Sebastien Rannou explains:
>>> << Yes, I confirm that my HW does not generate an in-band status.
>>> AFAIK, it's
>>> a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY
>>> (with
>>> inband status) is connected to the switch through QSGMII, and in this
>>> context
>>> we are on the media side of the PHY. >>
>>> https://lkml.org/lkml/2015/7/10/206
>>>
>>> This patch introduces the new boolean property 'autoneg' that allows
>>> the user to request the auto-negotiation explicitly.
>> The implementation looks better, but the name might still be slightly
>> controversial. I would go with "use-in-band-status" which is more
>> strictly defined than "autoneg" which could mean anything and everything.
>>
>> What do you think?
> I actually think autoneg is a bit better.
> 
> - Autonegotiation is a widely used and known term:
> https://en.wikipedia.org/wiki/Autonegotiation
> And who knows what in-band status is?

You and I apparently do because otherwise you would not have ran into
this problem and more generally, anyone having some mild exposure to the
(S|R)GMII protocols should at some point, but that is a pointless argument.

> And, more importantly, who knows what is it used for?
> Who even knows it is used for autonegotiation?

It is not about what do people know most, it is about being accurate and
specific.

> 
> - When we set autoneg for fixed-link, we basically just
> say "no MDIO here, but please do autoneg by any other
> means, if possible".

I agree with this.

> 
> - in-band status is an implementation delail, and it is
> specific to a particular protocols. If you request the
> in-band status for some protocol that doesn't support
> it, perhaps you should get -EINVAL, because such a
> config makes no sense. With autonegotiation, the rules
> are not that strict: it can be "unimplemented", which doesn't
> necessary mean nonsense in the config.

So by specifying "autoneg", you are not specific about the kind of
auto-negotiation protocol available, which is precisely my point: you
need to go down to that level of detail for this to be useful. So maybe
something like:

autoneg = "in-band-status" would actually be a better thing in terms of
description because then you would tell what can be made available/working?

> 
> - autonegotiation is a wider term, and may be implemented
> by some other means than the in-band status (which is
> probably impossible for a fixed-link though).
> 
> - In the terms that the driver uses, it is autonegotiation, eg
> MVNETA_GMAC_AUTONEG_CONFIG. And when you go down
> the implementation details, you see MVNETA_GMAC_INBAND_AN_ENABLE,
> which is just one AN bit of many.

But arguably, there could be another auto-negotiation method, which is
not in-band status related, which means that you would need a way to
distinguish between using in-band status, or using something else or
nothing, would not you?

> 
> So I really would prefer to keep things as is.
> But if you insist, I can rename, but there will still be no
> -EINVAL checks for obviously wrong configs.


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[Stas Sergeev]

10.07.2015 23:39, Florian Fainelli пишет:
>> - in-band status is an implementation delail, and it is
>> specific to a particular protocols. If you request the
>> in-band status for some protocol that doesn't support
>> it, perhaps you should get -EINVAL, because such a
>> config makes no sense. With autonegotiation, the rules
>> are not that strict: it can be "unimplemented", which doesn't
>> necessary mean nonsense in the config.
> So by specifying "autoneg", you are not specific about the kind of
> auto-negotiation protocol available, which is precisely my point: you
> need to go down to that level of detail for this to be useful. So maybe
> something like:
>
> autoneg = "in-band-status" would actually be a better thing in terms of
> description because then you would tell what can be made available/working?
I would agree with this if your argument below is true (see below).

>> - autonegotiation is a wider term, and may be implemented
>> by some other means than the in-band status (which is
>> probably impossible for a fixed-link though).
>>
>> - In the terms that the driver uses, it is autonegotiation, eg
>> MVNETA_GMAC_AUTONEG_CONFIG. And when you go down
>> the implementation details, you see MVNETA_GMAC_INBAND_AN_ENABLE,
>> which is just one AN bit of many.
> But arguably, there could be another auto-negotiation method, which is
> not in-band status related, which means that you would need a way to
> distinguish between using in-band status, or using something else or
> nothing, would not you?
"something else" is a big question here.
Can you think of _any_ other way that is both not an MDIO
(suits to fixed-link) and not an in-band?
If the answer is yes (even theoretically), then
autoneg = "in-band" | "off"
may make sense. Otherwise boolean just looks enough.
If we would implement autoneg outside of the fixed-link,
then its semantic would likely be
autoneg = "mdio" | "in-band" | "off"
But the fact that we put it under fixed-link where only a
single AN possibility exist, may probably be underlined by
a semantic specific to fixed-link.

One may also argue that
autoneg = "any-possible-autoneg-that-works" is better than
specifying it explicitly, which is exactly what the boolean does.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[Florian Fainelli]

On 10/07/15 14:02, Stas Sergeev wrote:
> 10.07.2015 23:39, Florian Fainelli пишет:
>>> - in-band status is an implementation delail, and it is
>>> specific to a particular protocols. If you request the
>>> in-band status for some protocol that doesn't support
>>> it, perhaps you should get -EINVAL, because such a
>>> config makes no sense. With autonegotiation, the rules
>>> are not that strict: it can be "unimplemented", which doesn't
>>> necessary mean nonsense in the config.
>> So by specifying "autoneg", you are not specific about the kind of
>> auto-negotiation protocol available, which is precisely my point: you
>> need to go down to that level of detail for this to be useful. So maybe
>> something like:
>>
>> autoneg = "in-band-status" would actually be a better thing in terms of
>> description because then you would tell what can be made
>> available/working?
> I would agree with this if your argument below is true (see below).
> 
>>> - autonegotiation is a wider term, and may be implemented
>>> by some other means than the in-band status (which is
>>> probably impossible for a fixed-link though).
>>>
>>> - In the terms that the driver uses, it is autonegotiation, eg
>>> MVNETA_GMAC_AUTONEG_CONFIG. And when you go down
>>> the implementation details, you see MVNETA_GMAC_INBAND_AN_ENABLE,
>>> which is just one AN bit of many.
>> But arguably, there could be another auto-negotiation method, which is
>> not in-band status related, which means that you would need a way to
>> distinguish between using in-band status, or using something else or
>> nothing, would not you?
> "something else" is a big question here.
> Can you think of _any_ other way that is both not an MDIO
> (suits to fixed-link) and not an in-band?

Yes, I could think about I2C or SPI PHYs that you could use alongside an
Ethernet controller that would qualify for out-of-band, not in-band, yet
could still provide auto-negotiation. You may have special hardware with
such a SPI or I2C controller which provides automatic decoding of the
auto-neg registers. Have not looked at e.g: SFP form factors or fiber
links, but they could also have additional out-of-band type of
auto-negotiation available.

> If the answer is yes (even theoretically), then
> autoneg = "in-band" | "off"
> may make sense. Otherwise boolean just looks enough.

I think the answer is yes.

> If we would implement autoneg outside of the fixed-link,
> then its semantic would likely be
> autoneg = "mdio" | "in-band" | "off"
> But the fact that we put it under fixed-link where only a
> single AN possibility exist, may probably be underlined by
> a semantic specific to fixed-link.

Right, if auto-negotiation was defined outside of fixed-link, that is
indeed how I would also specify this.

> 
> One may also argue that
> autoneg = "any-possible-autoneg-that-works" is better than
> specifying it explicitly, which is exactly what the boolean does.

I prefer excess of information rather than lack of information, because
you can always choose what to do with it. Especially when it comes to
Device Tree, plan carefully :)
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] of_mdio: add new DT property 'autoneg' for fixed-link

[Stas Sergeev]

11.07.2015 03:22, Florian Fainelli пишет:
> On 10/07/15 14:02, Stas Sergeev wrote:
>> 10.07.2015 23:39, Florian Fainelli пишет:
>>>> - in-band status is an implementation delail, and it is
>>>> specific to a particular protocols. If you request the
>>>> in-band status for some protocol that doesn't support
>>>> it, perhaps you should get -EINVAL, because such a
>>>> config makes no sense. With autonegotiation, the rules
>>>> are not that strict: it can be "unimplemented", which doesn't
>>>> necessary mean nonsense in the config.
>>> So by specifying "autoneg", you are not specific about the kind of
>>> auto-negotiation protocol available, which is precisely my point: you
>>> need to go down to that level of detail for this to be useful. So maybe
>>> something like:
>>>
>>> autoneg = "in-band-status" would actually be a better thing in terms of
>>> description because then you would tell what can be made
>>> available/working?
>> I would agree with this if your argument below is true (see below).
>>
>>>> - autonegotiation is a wider term, and may be implemented
>>>> by some other means than the in-band status (which is
>>>> probably impossible for a fixed-link though).
>>>>
>>>> - In the terms that the driver uses, it is autonegotiation, eg
>>>> MVNETA_GMAC_AUTONEG_CONFIG. And when you go down
>>>> the implementation details, you see MVNETA_GMAC_INBAND_AN_ENABLE,
>>>> which is just one AN bit of many.
>>> But arguably, there could be another auto-negotiation method, which is
>>> not in-band status related, which means that you would need a way to
>>> distinguish between using in-band status, or using something else or
>>> nothing, would not you?
>> "something else" is a big question here.
>> Can you think of _any_ other way that is both not an MDIO
>> (suits to fixed-link) and not an in-band?
> Yes, I could think about I2C or SPI PHYs that you could use alongside an
> Ethernet controller that would qualify for out-of-band, not in-band, yet
> could still provide auto-negotiation. You may have special hardware with
> such a SPI or I2C controller which provides automatic decoding of the
> auto-neg registers. Have not looked at e.g: SFP form factors or fiber
> links, but they could also have additional out-of-band type of
> auto-negotiation available.
>
>> If the answer is yes (even theoretically), then
>> autoneg = "in-band" | "off"
>> may make sense. Otherwise boolean just looks enough.
> I think the answer is yes.
>
>> If we would implement autoneg outside of the fixed-link,
>> then its semantic would likely be
>> autoneg = "mdio" | "in-band" | "off"
>> But the fact that we put it under fixed-link where only a
>> single AN possibility exist, may probably be underlined by
>> a semantic specific to fixed-link.
> Right, if auto-negotiation was defined outside of fixed-link, that is
> indeed how I would also specify this.
Hmm, okey.
But then this all doesn't fit into a fixed-link. The inband autoneg
is a very small xtension, it only allows to notify MAC about some
changes on the other end, but never control such changes, so
from some POV it is still pretty much fixed. And it also built into
the protocols that fixed-link already use, so that looked like a
natural xtension to me. But if there are so many possible ways
to abuse fixed-link making it _fully managed_, I am really starting
to think about the possibility of defining the autoneg outside of it,
and leave the poor fixed-link alone.
The patch will be bigger, but... what do you think?
This will of course first require defining the fixed-link in the
docs more strictly, as currently it is (vaguely) defined as
"non-MDIO", which leaves a lot to speculate and abuse.