[PATCH] arm: clk: Add ETH switch clock description for vf610 SoC

[Lukasz Majewski]

Hi Andrew,

> On Wed, Feb 19, 2025 at 11:38:02PM +0100, Lukasz Majewski wrote:
> > Hi Andrew,
> >   
> > > On Wed, Feb 19, 2025 at 12:49:36PM +0100, Lukasz Majewski wrote:  
> > > > The NXP's vf610 soc is equipped with L2 switch IP block from
> > > > More Than IP (MTIP) vendor.
> > > > 
> > > > It requires special clock (VF610_CLK_ESW) to be operational.    
> > > 
> > > So you have a driver for this switch? It has been talked about in
> > > the past, but nobody made any progress with it. Ah, it was you in
> > > 2020.  
> > 
> > Yes, I'm going to try another time to upstream it.... :-)
> >   
> > > It
> > > will be interesting to see what you came up with in the end, pure
> > > switchdev or a DSA driver.  
> > 
> > I think it would be:
> > 
> > 1. Standalone driver, which would configure the L2 switch from the
> > very beginning to work (this is different from FEC on imx28/vf610
> > where switch is bypassed)
> > 
> > 2. It will use the in-switch registers to have two network
> > interfaces separated. As a result - it may be slower than the
> > fec_main.c in this use case.  
> 
> Seems like a reasonable compromise. You would only load this driver if
> you intend to make use of the switch...

Yes, the main use case would be the switch (after bridge ... command
called).

However, until then we shall? have port separation.

> 
> > 3. When somebody call "bridge ..." on it - then the in-switch
> > separation would be disabled. This is the "normal" state of
> > operation for L2 switch, which would be a HW accelerator for
> > bridging.
> > 
> > 4. The switchdev would be used to manage it
> > 
> > 5. This would be just a very simple driver - just bridging and
> > startup of the L2 switch.
> > 
> > After we would have a consensus (i.e. it would be pulled to
> > mainline) - I would proceed further.
> > 
> > I will try to not touch fec_main.c driver - just write standalone,
> > new for MoreThanIP L2 switch driver.  
> 
> It might make sense to refactor the MDIO code into a helper which both
> can share? No point duplicating that.

This is a latter step (common MDIO library code), IMHO. 

> 
> > If somebody would like to use FEC, then he will insert the proper
> > module. If switch, another one can be inserted, depending o the
> > target use case.  
> 
> This all seems like a reasonable way forward.

+1

> 
> MoreThanIP is now part of Synopsys. I wounder if this IP now exists in
> other SoCs? The press release however suggests Synopsys was
> interesting in the high speed interfaces, not a two ports Fast
> Ethernet switch.

I would need some detailed documentation....

> 
> 	Andrew




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250220/5620570c/attachment.sig>