[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f54fcc51-3a38-49b6-be14-24a7cdcfdada@lunn.ch>
Date: Thu, 1 Aug 2024 14:26:55 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jijie Shao <shaojijie@...wei.com>
Cc: yisen.zhuang@...wei.com, salil.mehta@...wei.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
horms@...nel.org, shenjian15@...wei.com, wangpeiyang1@...wei.com,
liuyonglong@...wei.com, sudongming1@...wei.com,
xujunsheng@...wei.com, shiyongbang@...wei.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next 08/10] net: hibmcge: Implement workqueue and
some ethtool_ops functions
> > Why do you need this? phylib will poll the PHY once per second and
> > call the adjust_link callback whenever the link changes state.
>
> However, we hope that the network port can be linked only when
> the PHY and MAC are linked.
> The adjust_link callback can ensure that the PHY status is normal,
> but cannot ensure that the MAC address is linked.
So why would the SGMII link be down? My experience with SGMII is that
the link comes up as soon as both ends have power. You are also not
using in-band signalling, you configure the MAC based on the
adjust_link callback.
Basically, whenever you do something which no other driver does, you
need to explain why. Do you see any other MAC driver using SGMII doing
this?
Andrew
Powered by blists - more mailing lists