linux-kernel - Re: [PATCH net-next v6 5/5] net: phy: add driver for built-in 2.5G ethernet PHY on MT7988

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 for Android: free password hash cracker in your pocket

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

Message-ID: <b7ee870be0ecee7eacfbd1424356d2e8fe369cec.camel@mediatek.com>
Date: Tue, 4 Jun 2024 08:57:55 +0000
From: SkyLake Huang (黃啟澤)
	<SkyLake.Huang@...iatek.com>
To: "daniel@...rotopia.org" <daniel@...rotopia.org>
CC: "andrew@...n.ch" <andrew@...n.ch>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, "linux@...linux.org.uk"
	<linux@...linux.org.uk>, "kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"dqfext@...il.com" <dqfext@...il.com>,
	Steven Liu (劉人豪) <steven.liu@...iatek.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>, "davem@...emloft.net"
	<davem@...emloft.net>, "hkallweit1@...il.com" <hkallweit1@...il.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
	"angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH net-next v6 5/5] net: phy: add driver for built-in 2.5G
 ethernet PHY on MT7988

On Mon, 2024-06-03 at 20:40 +0100, Daniel Golle wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On Mon, Jun 03, 2024 at 08:18:34PM +0800, Sky Huang wrote:
> > From: "SkyLake.Huang" <skylake.huang@...iatek.com>
> > +
> > +static int mt798x_2p5ge_phy_get_rate_matching(struct phy_device
> *phydev,
> > +      phy_interface_t iface)
> > +{
> > +if (iface == PHY_INTERFACE_MODE_XGMII ||
> > +    iface == PHY_INTERFACE_MODE_INTERNAL)
> > +return RATE_MATCH_PAUSE;
> > +return RATE_MATCH_NONE;
> 
> As the phy is always connected in the same way internally inside the
> MT7988
> this check and destinction doesn't make sense to me.
> 
> Imho you should always return RATE_MATCH_PAUSE, unless the same PHY
> also
> exists in other SoCs and/or is connected in different interface
> modes.
> 
> In any way, please explain this part to us, especially in which
> situation
> exactly you want to return RATE_MATCH_NONE and for which reason.
> 
  Actually internal 2.5Gphy is planned to be conntected to both XFI-MAC 
and GMAC at very first: (2.5G speed relies on XGMII path and
1G/100M/10M rely on GMII/MII path)
+---------+       +--------+
|         |       |        |
| XFI-MAC |       |  GMAC  |
|         |       |        |
+---------+       +--------+
        |           |
        |           |
      (FCM)         |
    +-------+----------+
    | XGMII | GMII/MII |
    +------------------+
    |                  |
    |     built-in     |
    |      2.5Gphy     |
    |                  |
    +------------------+
  This phy's rate adaptation is implemented in FCM (flow control
module) on the XGMII path. So mt798x_2p5ge_phy_get_rate_matching() will
only return RATE_MATCH_PAUSE for this path.(for developing purpose)
  However, GMII/MII is deprecated later in our built-in 2.5Gphy
hardware design. So yes, you're right.
mt798x_2p5ge_phy_get_rate_matching() should always return
RATE_MATCH_PAUSE now. I'll change this in next version.

Sky