[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZXGJXIK3cl/9lfKi@eichest-laptop>
Date: Thu, 7 Dec 2023 10:01:08 +0100
From: Stefan Eichenberger <eichest@...il.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: mw@...ihalf.com, linux@...linux.org.uk, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: mvpp2: add support for mii
Hi Maxime,
On Wed, Dec 06, 2023 at 06:27:05PM +0100, Maxime Chevallier wrote:
> > @@ -6973,6 +6988,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,
> > port->phylink_config.supported_interfaces);
> > __set_bit(PHY_INTERFACE_MODE_SGMII,
> > port->phylink_config.supported_interfaces);
> > + } else if (phy_mode == PHY_INTERFACE_MODE_MII) {
> > + __set_bit(PHY_INTERFACE_MODE_100BASEX,
> > + port->phylink_config.supported_interfaces);
>
> Can you explain that part ? I don't understand why 100BaseX is being
> reported as a supported mode here. This whole section of the function
> is about detecting what can be reported based on the presence or not of
> a comphy driver / hardcoded comphy config. I don't think the comphy
> here has anything to do with MII / 100BaseX
>
> If 100BaseX can be carried on MII (which I don't know), shouldn't it be
> reported no matter what ?
I missunderstood that part, I thought it is a translation from interface
type to speed but it is obviously not. I already verfied that everything
works without this part and will remove it in version 2 of the patch.
Thanks a lot for the review!
Regards,
Stefan
Powered by blists - more mailing lists