Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Caleb James DeLisle <cjd@cjdns.fr>
Cc: ansuelsmth@gmail.com, netdev@vger.kernel.org,
	hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	daniel@makrotopia.org, dqfext@gmail.com,
	SkyLake.Huang@mediatek.com, matthias.bgg@gmail.com,
	angelogioacchino.delregno@collabora.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net-next 3/3] net: phy: mediatek: support EcoNet EN751221 gbit SoC PHY
Date: Wed, 26 Aug 2026 04:21:00 +0200	[thread overview]
Message-ID: <4d594c62-2ceb-43c1-a3d2-731b80493787@lunn.ch> (raw)
In-Reply-To: <a75b6b15-f86b-4cb2-934c-87583b5bb02c@cjdns.fr>

> > Does this need a change to the binding document?
> 
> 
> Not as far as I know. econet,en751221-chip-scu is defined in mfd/syscon.yaml
> because it's a catch-all for configuration that the engineers didn't know
> what to do with.

Do you need a property in the PHY node to make this work?

> > > +static int en751221_gphy_config_init(struct phy_device *phydev)
> > > +{
> > > +	phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
> > Why is the EEE register being cleared?
> 
> 
> From reading the reference implementation, I get the impression that this
> hardware is something of a basket case. There was a certain amount of "write
> three times and then read back" type magic that I just omitted because it
> really looks like they were actively debugging and as soon as it started
> working they shipped the code exactly as it was.
> 
> 
> In the case of disabling EEE, I thought it more prudent to follow them
> because I don't have every SoC that this PHY ever appeared on and I would
> rather not diverge too greatly and risk it being unreliable on some devices.

Is EEE broken? If it is, this is not the correct way to disable
it. You should call phy_disable_eee(phydev); This will also prevent
user space enabling it again.

> > > +	phy_select_page(phydev, MTK_PHY_PAGE_EXTENDED_52B5);
> > > +	__mtk_tr_write(phydev, 0x1, 0xf, 0x00, 0x00002b);
> > > +	__mtk_tr_write(phydev, 0x1, 0xf, 0x03, 0x082422);
> > > +	phy_restore_page(phydev, MTK_PHY_PAGE_STANDARD, 0);
> > > +
> > > +	ret = phy_write(phydev, MII_CTRL1000,
> > > +			ADVERTISE_1000FULL | CTL1000_PREFER_MASTER |
> > > +			CTL1000_AS_MASTER | CTL1000_ENABLE_MASTER);
> > What does this default to?
> It starts with only ADVERTISE_1000FULL. I don't know why the engineers
> wanted to set it to master, but its definitely intentional.

Generally, switches take the master role, and client take the slave
role. So this does make sense for a PHY used in a switch.

	Andrew


  reply	other threads:[~2026-08-26  2:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25 19:34 [PATCH net-next 0/3] net: phy: mediatek: support EcoNet EN751221 gbit SoC PHY Caleb James DeLisle
2026-08-25 19:34 ` [PATCH net-next 1/3] net: phy: mediatek: move mtk_cal_cycle_wait to mtk-phy-lib Caleb James DeLisle
2026-08-25 19:34 ` [PATCH net-next 2/3] net: phy: mediatek: bug fixes to airoha-ge-soc.c Caleb James DeLisle
2026-08-25 19:34 ` [PATCH net-next 3/3] net: phy: mediatek: support EcoNet EN751221 gbit SoC PHY Caleb James DeLisle
2026-08-26  0:00   ` Andrew Lunn
2026-08-26  0:59     ` Caleb James DeLisle
2026-08-26  2:21       ` Andrew Lunn [this message]
2026-08-26 16:37         ` Caleb James DeLisle
2026-08-26 16:50           ` Andrew Lunn
2026-08-26 20:27             ` Caleb James DeLisle

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=4d594c62-2ceb-43c1-a3d2-731b80493787@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=SkyLake.Huang@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=ansuelsmth@gmail.com \
    --cc=cjd@cjdns.fr \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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