[RFC,v2,net-next,0/4] mv88e6xxx: setting 2500base-x mode for CPU/DSA port in dts

Hi,

here is another proposal for supporting setting 2500base-x mode for
CPU/DSA ports in device tree correctly.

The changes from v1 are that instead of adding .port_setup() and
.port_teardown() methods to the DSA operations struct we instead, for
CPU/DSA ports, call dsa_port_enable() from dsa_port_setup(), but only
after the port is registered (and required phylink/devlink structures
exist).

The .port_enable/.port_disable methods are now only meant to be used
for user ports, when the slave interface is brought up/down. This
proposal changes that in such a way that these methods are also called
for CPU/DSA ports, but only just after the switch is set up (and just
before the switch is tore down).

If we went this way, we would have to patch the other DSA drivers to
check if user port is being given in their respective .port_enable
and .port_disable implmentations.

What do you think about this?

Marek

Marek Behún (4):
  net: dsa: mv88e6xxx: support 2500base-x in SGMII IRQ handler
  net: dsa: call port_enable/port_disable for CPU/DSA ports
  net: dsa: mv88e6xxx: check for port type in port_disable
  net: dsa: mv88e6xxx: do not enable SERDESes in mv88e6xxx_setup

 drivers/net/dsa/mv88e6xxx/chip.c   | 15 +++------------
 drivers/net/dsa/mv88e6xxx/serdes.c | 23 +++++++++++++++++++++--
 net/dsa/dsa2.c                     | 21 ++++++++++++++++++++-
 net/dsa/port.c                     |  4 ++--
 4 files changed, 46 insertions(+), 17 deletions(-)

Hi Marek,

On Sat, 17 Aug 2019 21:14:48 +0200, Marek Behún <marek.behun@nic.cz> wrote:
> Hi,
> 
> here is another proposal for supporting setting 2500base-x mode for
> CPU/DSA ports in device tree correctly.
> 
> The changes from v1 are that instead of adding .port_setup() and
> .port_teardown() methods to the DSA operations struct we instead, for
> CPU/DSA ports, call dsa_port_enable() from dsa_port_setup(), but only
> after the port is registered (and required phylink/devlink structures
> exist).
> 
> The .port_enable/.port_disable methods are now only meant to be used
> for user ports, when the slave interface is brought up/down. This
> proposal changes that in such a way that these methods are also called
> for CPU/DSA ports, but only just after the switch is set up (and just
> before the switch is tore down).
> 
> If we went this way, we would have to patch the other DSA drivers to
> check if user port is being given in their respective .port_enable
> and .port_disable implmentations.
> 
> What do you think about this?

This looks much better. Let me pass through all patches of this RFC so that
I can include bits I would like to see in your next series.


Thanks,

	Vivien

Hi Marek,

On Sat, 17 Aug 2019 15:50:25 -0400, Vivien Didelot <vivien.didelot@gmail.com> wrote:
> > here is another proposal for supporting setting 2500base-x mode for
> > CPU/DSA ports in device tree correctly.
> > 
> > The changes from v1 are that instead of adding .port_setup() and
> > .port_teardown() methods to the DSA operations struct we instead, for
> > CPU/DSA ports, call dsa_port_enable() from dsa_port_setup(), but only
> > after the port is registered (and required phylink/devlink structures
> > exist).
> > 
> > The .port_enable/.port_disable methods are now only meant to be used
> > for user ports, when the slave interface is brought up/down. This
> > proposal changes that in such a way that these methods are also called
> > for CPU/DSA ports, but only just after the switch is set up (and just
> > before the switch is tore down).
> > 
> > If we went this way, we would have to patch the other DSA drivers to
> > check if user port is being given in their respective .port_enable
> > and .port_disable implmentations.
> > 
> > What do you think about this?
> 
> This looks much better. Let me pass through all patches of this RFC so that
> I can include bits I would like to see in your next series.

I went ahead and sent a series which enables and disables all ports
in DSA, I hope you don't mind. You can now send a single patch on
top of it focusing on the 2500base-x issue with all the details.


Thank you,

	Vivien