netdev - Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: add internal-PHY-to-PHY CPU link example

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <TYZPR01MB5556A170A7D60C75FC134ECEC9C82@TYZPR01MB5556.apcprd01.prod.exchangelabs.com>
Date: Tue, 4 Mar 2025 13:00:58 +0800
From: Ziyang Huang <hzyitc@...look.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: olteanv@...il.com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, rmk+kernel@...linux.org.uk,
 javier.carrasco.cruz@...il.com, john@...ozen.org, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: add internal-PHY-to-PHY
 CPU link example

在 2025/3/4 1:15, Andrew Lunn 写道:
> 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@gmail.com/
>>
>> With this path, we can have multi CPU link.
> 
> So you should get that merged first. Then this patch.

After checking the code again, the demo 2 has already had 2 CPU link
(Port0 and Port6). Could I just keep this or should I need to add a new
case ?

>>> 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.

I think I known which point you are confused about. Sorry for my poor
English.

The "internal" is used to describe the localcation of PHY not the link.
In current code, qca8k has supported to use a external PHY to do a
PHY-to-PHY link (Port0 and Port6). This patch make the internal PHYs
support it too (Port1-5).

The followiing topology is existed in most IPQ50xx-based router:
      _______________________         _______________________
     |        IPQ5018        |       |        QCA8337        |
     | +------+   +--------+ |       | +--------+   +------+ |
     | | MAC0 |---| GE Phy |-+--MDI--+-|  Phy4  |---| MAC5 | |
     | +------+   +--------+ |       | +--------+   +------+ |
     | +------+   +--------+ |       | +--------+   +------+ |
     | | MAC1 |---| Uniphy |-+-SGMII-+-| SerDes |---| MAC0 | |
     | +------+   +--------+ |       | +--------+   +------+ |
     |_______________________|       |_______________________|

> 	Andrew