Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
the relevant operations in am65_cpsw_nuss_mac_config() itself.
Signed-off-by: Siddharth Vadapalli <[email protected]>
---
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 40 ++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 72b1df12f320..1739c389af20 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -1494,10 +1494,50 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
phylink_config);
struct am65_cpsw_port *port = container_of(slave, struct am65_cpsw_port, slave);
struct am65_cpsw_common *common = port->common;
+ struct fwnode_handle *fwnode;
+ bool fixed_link = false;
if (common->pdata.extra_modes & BIT(state->interface))
writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
+
+ /* Detecting fixed-link */
+ fwnode = of_node_to_fwnode(port->slave.phy_node);
+ if (fwnode)
+ fixed_link = !!fwnode_get_named_child_node(fwnode, "fixed-link");
+
+ if (fixed_link) {
+ /* In fixed-link mode, mac_link_up is not invoked.
+ * Therefore, the relevant mac_link_up operations
+ * have to be moved to mac_config.
+ */
+ am65_cpsw_nuss_mac_control(port, state->interface, state->speed,
+ state->duplex, state->pause & MLO_PAUSE_TX,
+ state->pause & MLO_PAUSE_RX);
+
+ if (state->speed == SPEED_1000)
+ mr_adv_ability |= MAC2MAC_MR_ADV_ABILITY_1G;
+ if (state->speed == SPEED_100)
+ mr_adv_ability |= MAC2MAC_MR_ADV_ABILITY_100M;
+ if (state->duplex)
+ mr_adv_ability |= MAC2MAC_MR_ADV_ABILITY_FULLDUPLEX;
+
+ if (state->interface == PHY_INTERFACE_MODE_SGMII &&
+ (common->pdata.extra_modes & BIT(state->interface))) {
+ writel(mr_adv_ability,
+ port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+ writel((AM65_CPSW_SGMII_CONTROL_MASTER_MODE |
+ AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE),
+ port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
+ }
+
+ am65_cpsw_nuss_mac_enable_link(port, state->speed, state->duplex);
+ } else {
+ if (state->interface == PHY_INTERFACE_MODE_SGMII &&
+ (common->pdata.extra_modes & BIT(state->interface)))
+ writel(MAC2PHY_MR_ADV_ABILITY,
+ port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+ }
}
static void am65_cpsw_nuss_mac_link_down(struct phylink_config *config, unsigned int mode,
--
2.25.1
On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
> the relevant operations in am65_cpsw_nuss_mac_config() itself.
Further to my other comments, you also fail to explain that, when in
fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce
since you are sending the duplex setting and speed settings via the
SGMII control word. Also, as SGMII was invented for a PHY to be able
to communicate the media negotiation resolution to the MAC, SGMII
defines that the PHY fills in the speed and duplex information in
the control word to pass it to the MAC, and the MAC acknowledges this
information. There is no need (and SGMII doesn't permit) the MAC to
advertise what it's doing.
Maybe this needs to be explained in the commit message?
This doesn't have any bearing on the other comments I've made.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index 72b1df12f320..1739c389af20 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -1494,10 +1494,50 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
> phylink_config);
> struct am65_cpsw_port *port = container_of(slave, struct am65_cpsw_port, slave);
> struct am65_cpsw_common *common = port->common;
> + struct fwnode_handle *fwnode;
> + bool fixed_link = false;
>
> if (common->pdata.extra_modes & BIT(state->interface))
> writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
> port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
> +
> + /* Detecting fixed-link */
> + fwnode = of_node_to_fwnode(port->slave.phy_node);
> + if (fwnode)
> + fixed_link = !!fwnode_get_named_child_node(fwnode, "fixed-link");
> +
> + if (fixed_link) {
> + /* In fixed-link mode, mac_link_up is not invoked.
> + * Therefore, the relevant mac_link_up operations
> + * have to be moved to mac_config.
> + */
This seems very wrong. Why is mac_link_up() not invoked? Have you
debugged this? It works for other people.
Please debug rather than adding hacks to drivers when you find
things that don't seem to work.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hello Russell,
On 14/09/22 21:11, Russell King (Oracle) wrote:
> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
>> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> index 72b1df12f320..1739c389af20 100644
>> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> @@ -1494,10 +1494,50 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
>> phylink_config);
>> struct am65_cpsw_port *port = container_of(slave, struct am65_cpsw_port, slave);
>> struct am65_cpsw_common *common = port->common;
>> + struct fwnode_handle *fwnode;
>> + bool fixed_link = false;
>>
>> if (common->pdata.extra_modes & BIT(state->interface))
>> writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
>> port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
>> +
>> + /* Detecting fixed-link */
>> + fwnode = of_node_to_fwnode(port->slave.phy_node);
>> + if (fwnode)
>> + fixed_link = !!fwnode_get_named_child_node(fwnode, "fixed-link");
>> +
>> + if (fixed_link) {
>> + /* In fixed-link mode, mac_link_up is not invoked.
>> + * Therefore, the relevant mac_link_up operations
>> + * have to be moved to mac_config.
>> + */
>
> This seems very wrong. Why is mac_link_up() not invoked? Have you
> debugged this? It works for other people.
>
> Please debug rather than adding hacks to drivers when you find
> things that don't seem to work.
I will debug and find out. I had assumed that mac_link_up() is not
invoked in fixed-link mode. Thank you for clarifying.
Regards,
Siddharth.
Hello Russell,
On 14/09/22 21:39, Russell King (Oracle) wrote:
> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
>> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
>> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
>> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
>> the relevant operations in am65_cpsw_nuss_mac_config() itself.
>
> Further to my other comments, you also fail to explain that, when in
> fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce
> since you are sending the duplex setting and speed settings via the
> SGMII control word. Also, as SGMII was invented for a PHY to be able
> to communicate the media negotiation resolution to the MAC, SGMII
> defines that the PHY fills in the speed and duplex information in
> the control word to pass it to the MAC, and the MAC acknowledges this
> information. There is no need (and SGMII doesn't permit) the MAC to
> advertise what it's doing.
>
> Maybe this needs to be explained in the commit message?
I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1
PHY. Based on your clarification in the previous mails that there is an
issue with the fixed-link mode which I need to debug, I assume that what
you are referring to here also happens to be a consequence of that.
Please let me know if I have misunderstood what you meant to convey.
Regards,
Siddharth.
Hi,
On Thu, Sep 15, 2022 at 02:58:52PM +0530, Siddharth Vadapalli wrote:
> Hello Russell,
>
> On 14/09/22 21:39, Russell King (Oracle) wrote:
> > On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
> >> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
> >> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
> >> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
> >> the relevant operations in am65_cpsw_nuss_mac_config() itself.
> >
> > Further to my other comments, you also fail to explain that, when in
> > fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce
> > since you are sending the duplex setting and speed settings via the
> > SGMII control word. Also, as SGMII was invented for a PHY to be able
> > to communicate the media negotiation resolution to the MAC, SGMII
> > defines that the PHY fills in the speed and duplex information in
> > the control word to pass it to the MAC, and the MAC acknowledges this
> > information. There is no need (and SGMII doesn't permit) the MAC to
> > advertise what it's doing.
> >
> > Maybe this needs to be explained in the commit message?
>
> I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1
> PHY. Based on your clarification in the previous mails that there is an
> issue with the fixed-link mode which I need to debug, I assume that what
> you are referring to here also happens to be a consequence of that.
> Please let me know if I have misunderstood what you meant to convey.
I think what you're saying is that you have this setup:
ethernet MAC <--SGMII link--> ethernet PHY <---> media
which you are operating in fixed link mode?
From the SGMII specification: "This is achieved by using the Auto-
Negotiation functionality defined in Clause 37 of the IEEE
Specification 802.3z. Instead of the ability advertisement, the PHY
sends the control information via its tx_config_Reg[15:0] as specified
in Table 1 whenever the control information changes. Upon receiving
control information, the MAC acknowledges the update of the control
information by asserting bit 14 of its tx_config_reg{15:0] as specified
in Table 1."
For the control word sent from the MAC to the PHY, table 1 specifies a
value of 0x4001. All the zero bits in that word which are zero are
marked as "Reserved for future use." There are no fields for speed and
duplex in this acknowledgement word to the PHY.
I hope this clears up my point.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hello Russell,
On 15/09/22 15:37, Russell King (Oracle) wrote:
> Hi,
>
> On Thu, Sep 15, 2022 at 02:58:52PM +0530, Siddharth Vadapalli wrote:
>> Hello Russell,
>>
>> On 14/09/22 21:39, Russell King (Oracle) wrote:
>>> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
>>>> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
>>>> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
>>>> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
>>>> the relevant operations in am65_cpsw_nuss_mac_config() itself.
>>>
>>> Further to my other comments, you also fail to explain that, when in
>>> fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce
>>> since you are sending the duplex setting and speed settings via the
>>> SGMII control word. Also, as SGMII was invented for a PHY to be able
>>> to communicate the media negotiation resolution to the MAC, SGMII
>>> defines that the PHY fills in the speed and duplex information in
>>> the control word to pass it to the MAC, and the MAC acknowledges this
>>> information. There is no need (and SGMII doesn't permit) the MAC to
>>> advertise what it's doing.
>>>
>>> Maybe this needs to be explained in the commit message?
>>
>> I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1
>> PHY. Based on your clarification in the previous mails that there is an
>> issue with the fixed-link mode which I need to debug, I assume that what
>> you are referring to here also happens to be a consequence of that.
>> Please let me know if I have misunderstood what you meant to convey.
>
> I think what you're saying is that you have this setup:
>
> ethernet MAC <--SGMII link--> ethernet PHY <---> media
>
> which you are operating in fixed link mode?
Yes, and the other end is connected to my PC's ethernet port.
>
> From the SGMII specification: "This is achieved by using the Auto-
> Negotiation functionality defined in Clause 37 of the IEEE
> Specification 802.3z. Instead of the ability advertisement, the PHY
> sends the control information via its tx_config_Reg[15:0] as specified
> in Table 1 whenever the control information changes. Upon receiving
> control information, the MAC acknowledges the update of the control
> information by asserting bit 14 of its tx_config_reg{15:0] as specified
> in Table 1."
>
> For the control word sent from the MAC to the PHY, table 1 specifies a
> value of 0x4001. All the zero bits in that word which are zero are
> marked as "Reserved for future use." There are no fields for speed and
> duplex in this acknowledgement word to the PHY.
>
> I hope this clears up my point.
Thank you for the detailed explanation. After reading the above, my
understanding is that even in the fixed-link mode, the ethernet MAC is
not supposed to advertise the speed and duplex settings. The ethernet
MACs present on both ends of the connection are supposed to be set to
the same speed and duplex settings via the devicetree node. Thus, only
for my setup which happens to be a special case of fixed-link mode where
the ethernet PHY is present, I am having to send the control word due to
the presence of a PHY in between. And, I am supposed to mention this in
the commit message, which I haven't done. Please let me know if this is
what I was supposed to understand.
I am planning to change to a proper fixed-link setup without any
ethernet PHY between the MACs, for debugging the driver's fixed-link
mode where the "mac_link_up()" is not invoked. Additionally, with this
new setup, my MAC will not have to emulate being an ethernet PHY,
thereby making my patch cleaner in the process. The v2 series will be
based on the new setup. I hope that this is fine.
Regards,
Siddharth.
On Fri, Sep 16, 2022 at 10:24:48AM +0530, Siddharth Vadapalli wrote:
> On 15/09/22 15:37, Russell King (Oracle) wrote:
> > Hi,
> >
> > On Thu, Sep 15, 2022 at 02:58:52PM +0530, Siddharth Vadapalli wrote:
> >> Hello Russell,
> >>
> >> On 14/09/22 21:39, Russell King (Oracle) wrote:
> >>> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
> >>>> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
> >>>> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
> >>>> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
> >>>> the relevant operations in am65_cpsw_nuss_mac_config() itself.
> >>>
> >>> Further to my other comments, you also fail to explain that, when in
> >>> fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce
> >>> since you are sending the duplex setting and speed settings via the
> >>> SGMII control word. Also, as SGMII was invented for a PHY to be able
> >>> to communicate the media negotiation resolution to the MAC, SGMII
> >>> defines that the PHY fills in the speed and duplex information in
> >>> the control word to pass it to the MAC, and the MAC acknowledges this
> >>> information. There is no need (and SGMII doesn't permit) the MAC to
> >>> advertise what it's doing.
> >>>
> >>> Maybe this needs to be explained in the commit message?
> >>
> >> I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1
> >> PHY. Based on your clarification in the previous mails that there is an
> >> issue with the fixed-link mode which I need to debug, I assume that what
> >> you are referring to here also happens to be a consequence of that.
> >> Please let me know if I have misunderstood what you meant to convey.
> >
> > I think what you're saying is that you have this setup:
> >
> > ethernet MAC <--SGMII link--> ethernet PHY <---> media
> >
> > which you are operating in fixed link mode?
>
> Yes, and the other end is connected to my PC's ethernet port.
>
> >
> > From the SGMII specification: "This is achieved by using the Auto-
> > Negotiation functionality defined in Clause 37 of the IEEE
> > Specification 802.3z. Instead of the ability advertisement, the PHY
> > sends the control information via its tx_config_Reg[15:0] as specified
> > in Table 1 whenever the control information changes. Upon receiving
> > control information, the MAC acknowledges the update of the control
> > information by asserting bit 14 of its tx_config_reg{15:0] as specified
> > in Table 1."
> >
> > For the control word sent from the MAC to the PHY, table 1 specifies a
> > value of 0x4001. All the zero bits in that word which are zero are
> > marked as "Reserved for future use." There are no fields for speed and
> > duplex in this acknowledgement word to the PHY.
> >
> > I hope this clears up my point.
>
> Thank you for the detailed explanation. After reading the above, my
> understanding is that even in the fixed-link mode, the ethernet MAC is
> not supposed to advertise the speed and duplex settings. The ethernet
> MACs present on both ends of the connection are supposed to be set to
> the same speed and duplex settings via the devicetree node. Thus, only
> for my setup which happens to be a special case of fixed-link mode where
> the ethernet PHY is present, I am having to send the control word due to
> the presence of a PHY in between.
In SGMII, the control word is only passed between the ethernet MAC and
the ethernet PHY. It is not conveyed across the media.
> And, I am supposed to mention this in
> the commit message, which I haven't done. Please let me know if this is
> what I was supposed to understand.
If you implement this conventionally, then you don't need to mention it
in the commit message, because you're following the standard.
> I am planning to change to a proper fixed-link setup without any
> ethernet PHY between the MACs, for debugging the driver's fixed-link
> mode where the "mac_link_up()" is not invoked.
SGMII is designed for the setup in the diagram I provided in my previous
email. It is not designed for two MACs to talk direct to each other
without any ethernet PHY because of the asymmetric nature of the control
word.
The PHY sends e.g. a control word of 0x9801 for 1G full duplex. On
reception of that, the MAC responds with 0x4001. Finally, the PHY
responds with 0xd801 to acknowledge the receipt of the MAC response.
If both ends of the link are SGMII, both ends will be waiting for
the control word from a PHY which is not present, and the link will
not come up.
1000base-X is a symmetric protocol where both ends of the link
advertise their capabilities, acknowledge each others abilities and
resolve the duplex and pause settings.
SGMII is a Cisco proprietary modification of 1000base-X designed for
communicating the results of media autonegotiation between an
ethernet PHY and ethernet MAC.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hello Russell,
On 16/09/22 12:50, Russell King (Oracle) wrote:
> On Fri, Sep 16, 2022 at 10:24:48AM +0530, Siddharth Vadapalli wrote:
>> On 15/09/22 15:37, Russell King (Oracle) wrote:
>>> Hi,
>>>
>>> On Thu, Sep 15, 2022 at 02:58:52PM +0530, Siddharth Vadapalli wrote:
>>>> Hello Russell,
>>>>
>>>> On 14/09/22 21:39, Russell King (Oracle) wrote:
>>>>> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
>>>>>> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
>>>>>> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
>>>>>> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
>>>>>> the relevant operations in am65_cpsw_nuss_mac_config() itself.
>>>>>
>>>>> Further to my other comments, you also fail to explain that, when in
>>>>> fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce
>>>>> since you are sending the duplex setting and speed settings via the
>>>>> SGMII control word. Also, as SGMII was invented for a PHY to be able
>>>>> to communicate the media negotiation resolution to the MAC, SGMII
>>>>> defines that the PHY fills in the speed and duplex information in
>>>>> the control word to pass it to the MAC, and the MAC acknowledges this
>>>>> information. There is no need (and SGMII doesn't permit) the MAC to
>>>>> advertise what it's doing.
>>>>>
>>>>> Maybe this needs to be explained in the commit message?
>>>>
>>>> I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1
>>>> PHY. Based on your clarification in the previous mails that there is an
>>>> issue with the fixed-link mode which I need to debug, I assume that what
>>>> you are referring to here also happens to be a consequence of that.
>>>> Please let me know if I have misunderstood what you meant to convey.
>>>
>>> I think what you're saying is that you have this setup:
>>>
>>> ethernet MAC <--SGMII link--> ethernet PHY <---> media
>>>
>>> which you are operating in fixed link mode?
>>
>> Yes, and the other end is connected to my PC's ethernet port.
>>
>>>
>>> From the SGMII specification: "This is achieved by using the Auto-
>>> Negotiation functionality defined in Clause 37 of the IEEE
>>> Specification 802.3z. Instead of the ability advertisement, the PHY
>>> sends the control information via its tx_config_Reg[15:0] as specified
>>> in Table 1 whenever the control information changes. Upon receiving
>>> control information, the MAC acknowledges the update of the control
>>> information by asserting bit 14 of its tx_config_reg{15:0] as specified
>>> in Table 1."
>>>
>>> For the control word sent from the MAC to the PHY, table 1 specifies a
>>> value of 0x4001. All the zero bits in that word which are zero are
>>> marked as "Reserved for future use." There are no fields for speed and
>>> duplex in this acknowledgement word to the PHY.
>>>
>>> I hope this clears up my point.
>>
>> Thank you for the detailed explanation. After reading the above, my
>> understanding is that even in the fixed-link mode, the ethernet MAC is
>> not supposed to advertise the speed and duplex settings. The ethernet
>> MACs present on both ends of the connection are supposed to be set to
>> the same speed and duplex settings via the devicetree node. Thus, only
>> for my setup which happens to be a special case of fixed-link mode where
>> the ethernet PHY is present, I am having to send the control word due to
>> the presence of a PHY in between.
>
> In SGMII, the control word is only passed between the ethernet MAC and
> the ethernet PHY. It is not conveyed across the media.
>
>> And, I am supposed to mention this in
>> the commit message, which I haven't done. Please let me know if this is
>> what I was supposed to understand.
>
> If you implement this conventionally, then you don't need to mention it
> in the commit message, because you're following the standard.
>
>> I am planning to change to a proper fixed-link setup without any
>> ethernet PHY between the MACs, for debugging the driver's fixed-link
>> mode where the "mac_link_up()" is not invoked.
>
> SGMII is designed for the setup in the diagram I provided in my previous
> email. It is not designed for two MACs to talk direct to each other
> without any ethernet PHY because of the asymmetric nature of the control
> word.
>
> The PHY sends e.g. a control word of 0x9801 for 1G full duplex. On
> reception of that, the MAC responds with 0x4001. Finally, the PHY
> responds with 0xd801 to acknowledge the receipt of the MAC response.
>
> If both ends of the link are SGMII, both ends will be waiting for
> the control word from a PHY which is not present, and the link will
> not come up.
>
> 1000base-X is a symmetric protocol where both ends of the link
> advertise their capabilities, acknowledge each others abilities and
> resolve the duplex and pause settings.
>
> SGMII is a Cisco proprietary modification of 1000base-X designed for
> communicating the results of media autonegotiation between an
> ethernet PHY and ethernet MAC.
I will try to implement and test SGMII mode in the conventional way with
both the MAC and the PHY present. If I am unable to do so, I will revert
to the current set of patches for the special case where the MAC
emulates a PHY, and mention this setup in the commit message of the v2
series. I hope this approach would be fine to proceed with. Please let
me know in case of any suggestions.
Regards,
Siddharth.
On Fri, Sep 16, 2022 at 02:33:23PM +0530, Siddharth Vadapalli wrote:
> Hello Russell,
>
> On 16/09/22 12:50, Russell King (Oracle) wrote:
> > On Fri, Sep 16, 2022 at 10:24:48AM +0530, Siddharth Vadapalli wrote:
> >> On 15/09/22 15:37, Russell King (Oracle) wrote:
> >>> Hi,
> >>>
> >>> On Thu, Sep 15, 2022 at 02:58:52PM +0530, Siddharth Vadapalli wrote:
> >>>> Hello Russell,
> >>>>
> >>>> On 14/09/22 21:39, Russell King (Oracle) wrote:
> >>>>> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote:
> >>>>>> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct
> >>>>>> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since
> >>>>>> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform
> >>>>>> the relevant operations in am65_cpsw_nuss_mac_config() itself.
> >>>>>
> >>>>> Further to my other comments, you also fail to explain that, when in
> >>>>> fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce
> >>>>> since you are sending the duplex setting and speed settings via the
> >>>>> SGMII control word. Also, as SGMII was invented for a PHY to be able
> >>>>> to communicate the media negotiation resolution to the MAC, SGMII
> >>>>> defines that the PHY fills in the speed and duplex information in
> >>>>> the control word to pass it to the MAC, and the MAC acknowledges this
> >>>>> information. There is no need (and SGMII doesn't permit) the MAC to
> >>>>> advertise what it's doing.
> >>>>>
> >>>>> Maybe this needs to be explained in the commit message?
> >>>>
> >>>> I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1
> >>>> PHY. Based on your clarification in the previous mails that there is an
> >>>> issue with the fixed-link mode which I need to debug, I assume that what
> >>>> you are referring to here also happens to be a consequence of that.
> >>>> Please let me know if I have misunderstood what you meant to convey.
> >>>
> >>> I think what you're saying is that you have this setup:
> >>>
> >>> ethernet MAC <--SGMII link--> ethernet PHY <---> media
> >>>
> >>> which you are operating in fixed link mode?
> >>
> >> Yes, and the other end is connected to my PC's ethernet port.
> >>
> >>>
> >>> From the SGMII specification: "This is achieved by using the Auto-
> >>> Negotiation functionality defined in Clause 37 of the IEEE
> >>> Specification 802.3z. Instead of the ability advertisement, the PHY
> >>> sends the control information via its tx_config_Reg[15:0] as specified
> >>> in Table 1 whenever the control information changes. Upon receiving
> >>> control information, the MAC acknowledges the update of the control
> >>> information by asserting bit 14 of its tx_config_reg{15:0] as specified
> >>> in Table 1."
> >>>
> >>> For the control word sent from the MAC to the PHY, table 1 specifies a
> >>> value of 0x4001. All the zero bits in that word which are zero are
> >>> marked as "Reserved for future use." There are no fields for speed and
> >>> duplex in this acknowledgement word to the PHY.
> >>>
> >>> I hope this clears up my point.
> >>
> >> Thank you for the detailed explanation. After reading the above, my
> >> understanding is that even in the fixed-link mode, the ethernet MAC is
> >> not supposed to advertise the speed and duplex settings. The ethernet
> >> MACs present on both ends of the connection are supposed to be set to
> >> the same speed and duplex settings via the devicetree node. Thus, only
> >> for my setup which happens to be a special case of fixed-link mode where
> >> the ethernet PHY is present, I am having to send the control word due to
> >> the presence of a PHY in between.
> >
> > In SGMII, the control word is only passed between the ethernet MAC and
> > the ethernet PHY. It is not conveyed across the media.
> >
> >> And, I am supposed to mention this in
> >> the commit message, which I haven't done. Please let me know if this is
> >> what I was supposed to understand.
> >
> > If you implement this conventionally, then you don't need to mention it
> > in the commit message, because you're following the standard.
> >
> >> I am planning to change to a proper fixed-link setup without any
> >> ethernet PHY between the MACs, for debugging the driver's fixed-link
> >> mode where the "mac_link_up()" is not invoked.
> >
> > SGMII is designed for the setup in the diagram I provided in my previous
> > email. It is not designed for two MACs to talk direct to each other
> > without any ethernet PHY because of the asymmetric nature of the control
> > word.
> >
> > The PHY sends e.g. a control word of 0x9801 for 1G full duplex. On
> > reception of that, the MAC responds with 0x4001. Finally, the PHY
> > responds with 0xd801 to acknowledge the receipt of the MAC response.
> >
> > If both ends of the link are SGMII, both ends will be waiting for
> > the control word from a PHY which is not present, and the link will
> > not come up.
> >
> > 1000base-X is a symmetric protocol where both ends of the link
> > advertise their capabilities, acknowledge each others abilities and
> > resolve the duplex and pause settings.
> >
> > SGMII is a Cisco proprietary modification of 1000base-X designed for
> > communicating the results of media autonegotiation between an
> > ethernet PHY and ethernet MAC.
>
>
> I will try to implement and test SGMII mode in the conventional way with
> both the MAC and the PHY present. If I am unable to do so, I will revert
> to the current set of patches for the special case where the MAC
> emulates a PHY, and mention this setup in the commit message of the v2
> series. I hope this approach would be fine to proceed with. Please let
> me know in case of any suggestions.
What exact setups are you trying to support with this patch set?
If you're looking to only add support for SGMII, then all you need
to do is to make sure it works with a PHY. Fixed-link in SGMII only
makes sense if you're directly connected to something like a network
switch, but even then, network switches tend to use 1000base-X in a
fixed-link mode rather than SGMII.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hello Russell,
On 16/09/22 14:44, Russell King (Oracle) wrote:
> On Fri, Sep 16, 2022 at 02:33:23PM +0530, Siddharth Vadapalli wrote:
>> Hello Russell,
>>
>> On 16/09/22 12:50, Russell King (Oracle) wrote:
>>> SGMII is designed for the setup in the diagram I provided in my previous
>>> email. It is not designed for two MACs to talk direct to each other
>>> without any ethernet PHY because of the asymmetric nature of the control
>>> word.
>>>
>>> The PHY sends e.g. a control word of 0x9801 for 1G full duplex. On
>>> reception of that, the MAC responds with 0x4001. Finally, the PHY
>>> responds with 0xd801 to acknowledge the receipt of the MAC response.
>>>
>>> If both ends of the link are SGMII, both ends will be waiting for
>>> the control word from a PHY which is not present, and the link will
>>> not come up.
>>>
>>> 1000base-X is a symmetric protocol where both ends of the link
>>> advertise their capabilities, acknowledge each others abilities and
>>> resolve the duplex and pause settings.
>>>
>>> SGMII is a Cisco proprietary modification of 1000base-X designed for
>>> communicating the results of media autonegotiation between an
>>> ethernet PHY and ethernet MAC.
>>
>> I will try to implement and test SGMII mode in the conventional way with
>> both the MAC and the PHY present. If I am unable to do so, I will revert
>> to the current set of patches for the special case where the MAC
>> emulates a PHY, and mention this setup in the commit message of the v2
>> series. I hope this approach would be fine to proceed with. Please let
>> me know in case of any suggestions.
>
> What exact setups are you trying to support with this patch set?
>
> If you're looking to only add support for SGMII, then all you need
> to do is to make sure it works with a PHY. Fixed-link in SGMII only
> makes sense if you're directly connected to something like a network
> switch, but even then, network switches tend to use 1000base-X in a
> fixed-link mode rather than SGMII.
I plan to support the standard MAC2PHY based SGMII mode. However, the
SGMII ethernet PHY that I have with me has issues which is why I had
tried the unconventional fixed-link SGMII mode with the MAC emulating
the ethernet PHY. I will try to obtain a functional SGMII ethernet PHY
and test the standard SGMII mode.
Thank you for patiently answering my questions and helping me understand
the SGMII mode better :)
Regards,
Siddharth.