On Tue, Mar 04, 2025 at 12:37:36AM +0800, Ziyang Huang wrote: > 在 2025/3/4 0:15, Andrew Lunn 写道: > > ... > > > > The previous patch still causes it to look at port 0 and then port 6 > > first. Only if they are not CPU ports will it look at other ports. So > > this example does not work, port 6 will be the CPU port, even with the > > properties you added. > > Sorry, I forget that the following patch is still penging: > https://lore.kernel.org/all/20230620063747.19175-1-ansuelsmth@xxxxxxxxx/ > > With this path, we can have multi CPU link. So you should get that merged first. Then this patch. > > When you fix this, i also think it would be good to extend: > > > > > + /* PHY-to-PHY CPU link */ > > > > with the work internal. > > > > This also seems an odd architecture to me. If this is SoC internal, > > why not do a MAC to MAC link? What benefit do you get from having the > > PHYs? > > This patches are for IPQ50xx platform which has only one a SGMII/SGMII+ link > and a MDI link. > > It has 2 common designs: > 1. SGMII+ is used to connect a 2.5G PHY, which make qca8337 only be able to > be connected through the MDI link. Please do not call it SGMII+. It is not SGMII if it is running at 2.5G. It is more likely to be broken 2500BaseX, broken in that it does not implement the inband signalling. > 2. Both SGMII and MDI links are used to connect the qca8337, so we can get > 2G link which is beneficial in NAT mode (total 2G bidirectional). So is this actually internally? Or do you have a IPQ50xx SoC connected to a qca8337 switch, with copper traces on a PCB? If so, it is not internal. Andrew
