netdev - Re: [PATCH net-next 2/2] net: phy: add keep_data

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] [thread-next>] [day] [month] [year] [list]

Date: Fri, 28 Jul 2023 17:27:37 +0800
From: "mengyuanlou@...-swift.com" <mengyuanlou@...-swift.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>,
 "Russell King (Oracle)" <linux@...linux.org.uk>,
 Simon Horman <simon.horman@...igine.com>,
 netdev@...r.kernel.org,
 "David S. Miller" <davem@...emloft.net>,
 Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>,
 Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next 2/2] net: phy: add keep_data_connection to struct
 phydev



> 2023年7月27日 02:29，Jakub Kicinski <kuba@...nel.org> 写道：
> 
> On Wed, 26 Jul 2023 18:43:01 +0200 Andrew Lunn wrote:
>> On Wed, Jul 26, 2023 at 09:08:12AM -0700, Jakub Kicinski wrote:
>>> On Wed, 26 Jul 2023 10:54:25 +0200 Andrew Lunn wrote:  
>>>> As far as i understand it, the host MAC is actually a switch, with the
>>>> BMC connected to the second port of the switch.  
>>> 
>>> Not a learning switch (usually, sigh), but yes.
>>> 
>>>> Does the BMC care about the PHY status?
>>>> Does it need to know about link status?   
>>> 
>>> Yes, NIC sends link state notifications over the NCSI "link?" (which 
>>> is a separate RGMII?/RMII from NIC to the BMC). BMC can select which
>>> "channel" (NIC port) it uses based on PHY status.  
>> 
>> How do you define NIC when Linux is driving the hardware, not
>> firmware? In this case we have a MAC driver, a PCS driver, a PHY
>> driver and phylink gluing it all together. Which part of this is
>> sending link state notifications over the NCSI "Link?".
> 
> I've never seen a NCSI setup where Linux on the host controls the PHY.
> So it's an open question.
> 
> The notifications are sent by the control FW on the NIC. There's a
> handful of commands that need to be handled there - mostly getting MAC
> address and configuring the filter. Commands are carried by
> encapsulated Ethernet packets with magic ethertype, over the same RMII
> as the data packets.
> 
> All of this is usually in FW so we should be able to shape the
> implementation in the way we want...
> 
We certainly can do all phy operations in Fw when we are using NCSI.

I’m confused about what other network cards do when it's used in both host os and BMC,
Because I can not find any codes in ethernet for now.

But this seems to go against the idea that we want to separate these modules.

>>>> Does the NCSI core on the host need to know about the PHY?  
>>> 
>>> There is no NCSI core on the host.. Hosts are currently completely
>>> oblivious to NCSI. The NCSI we have in tree is for the BMC, Linux
>>> running on the BMC (e.g. OpenBMC).  
>> 
>> But in this case, it is not oblivious to NCSI, since the host is
>> controlling the PHY. This patch is about Linux on the host not
>> shutting down the PHY because it is also being used by the BMC.
> 
> Yup, we're entering a new territory with this device :S
>