From: Caleb James DeLisle <cjd@cjdns.fr>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com, daniel@makrotopia.org,
naseefkm@gmail.com, joey@tinyisr.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net-next] net: phy: mediatek: add driver for EcoNet Fast Ethernet SoC PHYs
Date: Wed, 26 Aug 2026 02:08:50 +0200 [thread overview]
Message-ID: <4fa1ab31-cdcb-4488-b038-c5869966b6ec@cjdns.fr> (raw)
In-Reply-To: <177dc347-4cf9-48ca-97fe-b0f3cd46d8e3@lunn.ch>
On 25/08/2026 21:40, Andrew Lunn wrote:
>> Also provide support for the older EN7512 Fast Ethernet SoC PHYs found
>> in EN751221 chips with do not have the MCM switch. That is chips which
>> do not have a "G" in the name. As these PHYs bear the ID 03a2.9412
>> which collides with MTK_GPHY_ID_MT7530 gigabit PHY, do not match them
>> and instead rely on the user to override the PHY ID in the device tree
>> if they wish to use this driver.
> Is there a way to tell them apart using other registers?
The reference code differentiates this PHY from the other because this
one does not advertise gigabit capability. I sent it like this because
the idea of a matcher made me nervous and this felt more conservative,
but I'm open to guidance about what is the most appropriate solution.
>
>> +static int en751221_fephy_r50(struct phy_device *phydev)
>> +{
>> + struct econet_socphy_shared *shared = phy_package_get_priv(phydev);
>> + struct compensation ctab = get_ctab(phydev);
>> + int zcal_sz = ARRAY_SIZE(zcal_to_r50ohm);
>> + u8 rg_zcal_ctrl = ECONET_R50_ZCAL_DEFAULT;
> Please swap these two lines.
Whoops, thanks.
>
>> + for (;;) {
> It is unusual to do loops like this. Can it be turned into a do while
> loop? And without looking deep into it, it is not clear if this is
> endless if the hardware stops responding.
You raise a good point in that it's hard to reason out the default exit
scenario, and I will figure out how to improve that. I'm not sure I can
actually get rid of the infinite loop without making the code worse,
because the default exit condition needs to assign ret and goto the
error out label.
In any case I'll find something that's easier to reason out at a glance.
>
>> +static int en751221_fephy_tx_offset(struct phy_device *phydev)
>> +{
>> + struct econet_socphy_shared *shared = phy_package_get_priv(phydev);
>> + struct compensation ctab = get_ctab(phydev);
>> + int initial_comp_out;
>> + int polarity = 0;
>> + int offset = ECONET_TXOS_DEFAULT;
>> + u16 offset_bin;
>> + int comp_out;
>> + int ret = 0;
> Another reverse christmas tree issue. Please check all your functions.
Whoops, sorry for not catching this before sending.
>
>> +static int en751221_fephy_config_init(struct phy_device *phydev)
>> +{
>> + struct econet_socphy_shared *shared = phy_package_get_priv(phydev);
>> + u16 l0r26_temp;
>> + int ret;
>> + int i;
>> +
>> + if (!shared->phydev_p0) {
>> + phydev_err(phydev, "Port zero must be configured\n");
>> + return -EOPNOTSUPP;
>> + }
> What is the issue here? Why must port 0 be first?
It doesn't need to be configured first but it must be probed because
these PHYs are not independent, they exist as a group and some
configuration must be done on the first phy in the group. I will re-send
with clarification in a comment.
>
>> +
>> + for (i = 0; i < 5; i++) {
>> + ret = en751221_fephy_r50(phydev);
>> + if (!ret)
>> + break;
>> + }
>> + if (ret)
>> + return ret;
>> +
>> + for (i = 0; i < 5; i++) {
>> + ret = en751221_fephy_tx_offset(phydev);
>> + if (!ret)
>> + break;
>> + }
>> + if (ret)
>> + return ret;
>> +
>> + for (i = 0; i < 5; i++) {
>> + ret = en751221_fephy_tx_amp(phydev);
>> + if (!ret)
>> + break;
>> + }
> Why 5 ?
Following the reference implementation "keep trying until it's very
clear that it's not going to work". But this should be a define and it
slipped my mind to do so.
Thank you for your review!
Caleb
>
>
> Andrew
>
> ---
> pw-bot: cr
>
next prev parent reply other threads:[~2026-08-26 0:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 18:04 [PATCH net-next] net: phy: mediatek: add driver for EcoNet Fast Ethernet SoC PHYs Caleb James DeLisle
2026-08-25 19:40 ` Andrew Lunn
2026-08-26 0:08 ` Caleb James DeLisle [this message]
2026-08-26 2:08 ` Andrew Lunn
2026-08-27 7:13 ` Caleb James DeLisle
2026-08-26 6:51 ` kernel test robot
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=4fa1ab31-cdcb-4488-b038-c5869966b6ec@cjdns.fr \
--to=cjd@cjdns.fr \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=joey@tinyisr.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=naseefkm@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