[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240223161057.07b7aa5c@device-28.home>
Date: Fri, 23 Feb 2024 16:10:57 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>, Bastien
Curutchet <bastien.curutchet@...tlin.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Krzysztof Kozlowski
<krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Richard Cochran <richardcochran@...il.com>, Heiner Kallweit
<hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, Herve Codina <herve.codina@...tlin.com>
Subject: Re: [PATCH 1/2] dt-bindings: net: Add TI DP83640
>
> I've missed that thread initially. I guess that if Fiber is to be used,
> this would be done through sfp, then we have all the regular interfaces
> to configure the phy_interface_mode, in that case that would be
> 100BaseX.
>
> So, a sane behaviour could simply be to configure the PHY in copper
> mode by default, without relying on any DT property ? If anyone wants to
> use fiber mode, then they would have to implement the
> sfp_upstreamp_ops, which would take care of reconfiguring the MDI
> interface of the PHY in the correct mode.
I missed the fact that this isn't a new driver... So this would indeed
break existing setups who would have fiber-mode strapped-in but don't
use SFP for some reason :(
Maxime
> Maxime
>
Powered by blists - more mailing lists