Re: [PATCH net-next v2 3/3] net: phy: mediatek: add driver for built-in 2.5G ethernet PHY on MT7988

["SkyLake Huang (黃啟澤)" <SkyLake.Huang@mediatek.com>]

On Wed, 2025-02-26 at 09:52 +0000, Russell King (Oracle) wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On Wed, Feb 26, 2025 at 06:48:34AM +0000, SkyLake Huang (黃啟澤) wrote:
> > On Wed, 2025-02-19 at 09:33 +0000, Russell King (Oracle) wrote:
> > > 
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > > 
> > > 
> > > On Wed, Feb 19, 2025 at 04:39:10PM +0800, Sky Huang wrote:
> > > > +static int mt798x_2p5ge_phy_config_init(struct phy_device
> > > > *phydev)
> > > > +{
> > > > +     struct pinctrl *pinctrl;
> > > > +     int ret;
> > > > +
> > > > +     /* Check if PHY interface type is compatible */
> > > > +     if (phydev->interface != PHY_INTERFACE_MODE_INTERNAL)
> > > > +             return -ENODEV;
> > > > +
> > > > +     ret = mt798x_2p5ge_phy_load_fw(phydev);
> > > > +     if (ret < 0)
> > > > +             return ret;
> > > 
> > > Firmware should not be loaded in the .config_init method. The
> > > above
> > > call will block while holding the RTNL which will prevent all
> > > other
> > > network configuration until the firmware has been loaded or the
> > > load
> > > fails.
> > > 
> > > Thanks.
> > > 
> > > --
> > > RMK's Patch system:
> > > https://urldefense.com/v3/__https://www.armlinux.org.uk/developer/patches/__;!!CTRNKA9wMg0ARbw!iV-1ViPFsUV-lLj7aIycan8nery6sQO3t6mkpdlb_GW8hswhxc4ejJozxqkU3s2WzxSizs4kfdC77yr7HGGRIuU$
> > > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> > Hi Russell,
> > mt798x_p5ge_phy_load_fw() will only load firmware once after driver
> > is
> > probed through priv->fw_loaded. And actually, firmware loading
> > procedure only takes about 11ms. This was discussed earlier in:
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20240520113456.21675-6-SkyLake.Huang@mediatek.com/*25856462__;Iw!!CTRNKA9wMg0ARbw!lQ7b7kgD0JGOHR_CLeHtF5SF-knx3hZcm2u_tYbzgBnX91a7muRwqGhDUaP3XorHlu9qQozNX_pXDMIxO1DyVIY$
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20240520113456.21675-6-SkyLake.Huang@mediatek.com/*25857174__;Iw!!CTRNKA9wMg0ARbw!lQ7b7kgD0JGOHR_CLeHtF5SF-knx3hZcm2u_tYbzgBnX91a7muRwqGhDUaP3XorHlu9qQozNX_pXDMIxHDm1IuQ$
> 
> 1. Wouldn't it be a good idea to include the loading time in the
> patch
>    description or a comment in the patch?
> 
Sure. I'll include this in v3's commit message.

> 2. What about the time it takes for request_firmware() uses the sysfs
>    fallback, which essentially passes the firmware request to
> userspace
>    to deal with? That can block for an indeterminate amount of time.
> 
I'm not really sure how to achieve this. As far as I know, I can
provide fw via /sys/class/firmware/<device-name>/ after I boot into
Linux shell. But at that moment, we need to insmod phy driver again.
Users will also need to load fw file manually. This will add a lot of
complexity. Is this what upstream style expects?

> --
> RMK's Patch system:
> https://urldefense.com/v3/__https://www.armlinux.org.uk/developer/patches/__;!!CTRNKA9wMg0ARbw!lQ7b7kgD0JGOHR_CLeHtF5SF-knx3hZcm2u_tYbzgBnX91a7muRwqGhDUaP3XorHlu9qQozNX_pXDMIxE9f2xWs$
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

BRs,
Sky