mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Switch <kyle.switch@motor-comm.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Frank.Sae@motor-comm.com, hkallweit1@gmail.com,
	linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, ming.xu@motor-comm.com,
	xiaolin.xu@motor-comm.com, jianmin.wang@motor-comm.com,
	jie.han@motor-comm.com
Subject: Re: [PATCH net-next v5] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
Date: Sun, 26 Jul 2026 11:38:48 +0800	[thread overview]
Message-ID: <3398745a-d443-4882-9196-dd280b8ba982@motor-comm.com> (raw)
In-Reply-To: <0d789c95-5ca1-42d0-9ff5-27392cc65057@lunn.ch>



On 7/25/26 06:18, Andrew Lunn wrote:
> On Fri, Jul 24, 2026 at 03:18:47PM +0200, Andrew Lunn wrote:
> 1;4000;47c> > Ans: It is different from the m88e1111 PHY, which may support UTP, fiber, 
>>>      or combo mode. However, the PHY8824 is only used with UTPs, and 
>>>      its structure is as follows, which includes UTP0, UTP1,UTP2,UTP3 and USXGMII.
>>>
>>>      RJ45 <----> UTP0 <------>
>>>      RJ45 <----> UTP1 <------>   USXGMII  <----->  USXGMII(the side of MAC)
>>>      RJ45 <----> UTP2 <------>
>>>      RJ45 <----> UTP3 <------>
>>>
>>>      It is similar to phy8821 driver in motorcomm.c, with the difference 
>>>      being that one has one UTP port and phy8824 has four UTP ports.
>>>      YT8824_RSSR_FIBER_SPACE is used to access USXGMII reg space, Perhaps it 
>>>      would be more accurate to call it YT8824_RSSR_USXGMII_SPACE or 
>>>      YT8824_RSSR_SERDES_SPACE.
>>
>> O.K, that completely changes my understanding of this device. Yes,
>> YT8824_RSSR_FIBER_SPACE should change name. And i would include this
>> diagram in the driver, and indicate how YT8824_RSSR_*_SPACE map to
>> this.
>>
>> For the locking, look thought all the code which is touching the
>> USXGMII side and see if it can be moved into probe().
> 
> So thinking about locking:
> 
> +static int yt8824_config_aneg(struct phy_device *phydev)
> +{
> +	int phy_ctrl = 0;
> +	int ret = 0;
> +
> +	ret = phy8824_page_write_lock(phydev, YT8824_RSSR_UTP_SPACE);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
> +			      phydev->advertising))
> +		phy_ctrl = MDIO_AN_10GBT_CTRL_ADV2_5G;
> +
> +	ret = phy_modify_mmd_changed(phydev, MDIO_MMD_AN,
> +				     MDIO_AN_10GBT_CTRL,
> +				     MDIO_AN_10GBT_CTRL_ADV2_5G,
> +				     phy_ctrl);
> +	if (ret)
> +		return ret;
> +
> +	return genphy_config_aneg(phydev);
> +
> 
> This is only touching the UTP side of things. What a PHY advertises
> should not affect the USXGMII side. Why does it need
> YT8824_RSSR_UTP_SPACE? What would happen if YT8824_RSSR_USXGMII_SPACE
> has selected?
> 

Ans: yes, this place only involves the operation of UTP. The addition of 
     the operation to swap address spaces is solely to ensure that the 
     current operation is conducted on the UTP side, without affecting 
     the switching to the USXGMII side through other APIs.If the current 
     operation is performed on the USXGMII size, it cannot access the 
     standard MMD register of UTP, and all operations are configured and 
     the status obtained is the status of the UXGMII side, that is not what
     we want. That is why an operation to swap reg space has been added at 
     the beginning of each APIs.

>     Andrew

  reply	other threads:[~2026-07-26  3:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 11:48 Kyle Switch
2026-07-21 13:27 ` Andrew Lunn
2026-07-22  7:44   ` Kyle Switch
2026-07-21 14:18 ` Andrew Lunn
2026-07-22  8:06   ` Kyle Switch
2026-07-22 13:18     ` Andrew Lunn
2026-07-23  9:28       ` Kyle Switch
2026-07-23 14:27         ` Andrew Lunn
2026-07-24 11:46           ` Kyle Switch
2026-07-24 13:18             ` Andrew Lunn
2026-07-24 22:18               ` Andrew Lunn
2026-07-26  3:38                 ` Kyle Switch [this message]
2026-07-26  4:24                 ` Kyle Switch
2026-07-26  3:24               ` Kyle Switch
2026-07-26 14:51                 ` Andrew Lunn
2026-07-27  8:47                   ` Kyle Switch
2026-07-27 21:36                     ` Andrew Lunn
2026-07-28 11:25                       ` Kyle Switch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3398745a-d443-4882-9196-dd280b8ba982@motor-comm.com \
    --to=kyle.switch@motor-comm.com \
    --cc=Frank.Sae@motor-comm.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=jianmin.wang@motor-comm.com \
    --cc=jie.han@motor-comm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=ming.xu@motor-comm.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=xiaolin.xu@motor-comm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®