mbox series

[0/4] net: ti: am65-cpsw-nuss: Add switchdev driver

Message ID 20201130082046.16292-1-vigneshr@ti.com
Headers show
Series net: ti: am65-cpsw-nuss: Add switchdev driver | expand

Message

Raghavendra, Vignesh Nov. 30, 2020, 8:20 a.m. UTC
This series adds switchdev support for AM65 CPSW NUSS driver to support
multi port CPSW present on J721e and AM64 SoCs.
It adds devlink hook to switch b/w switch mode and multi mac mode.


Vignesh Raghavendra (4):
  net: ti: am65-cpsw-nuss: Add devlink support
  net: ti: am65-cpsw-nuss: Add netdevice notifiers
  net: ti: am65-cpsw-nuss: Add switchdev support
  docs: networking: ti: Add driver doc for AM65 NUSS switch driver

 .../device_drivers/ethernet/index.rst         |   1 +
 .../ethernet/ti/am65_nuss_cpsw_switchdev.rst  | 143 +++++
 .../devlink/am65-nuss-cpsw-switch.rst         |  26 +
 Documentation/networking/devlink/index.rst    |   1 +
 drivers/net/ethernet/ti/Kconfig               |  10 +
 drivers/net/ethernet/ti/Makefile              |   1 +
 drivers/net/ethernet/ti/am65-cpsw-nuss.c      | 511 +++++++++++++++-
 drivers/net/ethernet/ti/am65-cpsw-nuss.h      |  26 +
 drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 572 ++++++++++++++++++
 drivers/net/ethernet/ti/am65-cpsw-switchdev.h |  34 ++
 10 files changed, 1306 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
 create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
 create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c
 create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h

Comments

Andrew Lunn Nov. 30, 2020, 5:20 p.m. UTC | #1
> +static int am65_cpsw_port_stp_state_set(struct am65_cpsw_port *port,
> +					struct switchdev_trans *trans, u8 state)
> +{
> +	struct am65_cpsw_common *cpsw = port->common;
> +	u8 cpsw_state;
> +	int ret = 0;
> +
> +	if (switchdev_trans_ph_prepare(trans))
> +		return 0;
> +
> +	switch (state) {
> +	case BR_STATE_FORWARDING:
> +		cpsw_state = ALE_PORT_STATE_FORWARD;
> +		break;
> +	case BR_STATE_LEARNING:
> +		cpsw_state = ALE_PORT_STATE_LEARN;
> +		break;
> +	case BR_STATE_DISABLED:
> +		cpsw_state = ALE_PORT_STATE_DISABLE;
> +		break;
> +	case BR_STATE_LISTENING:
> +	case BR_STATE_BLOCKING:
> +		cpsw_state = ALE_PORT_STATE_BLOCK;
> +		break;
> +	default:
> +		return -EOPNOTSUPP;
> +	}

Strictly speaking, the:

> +	if (switchdev_trans_ph_prepare(trans))
> +		return 0;

should be here. In the prepare phase, you are suppose to validate you
can do the requested action, and return an error is not. In second
phase, actually carrying out the action, you then never return an
error.

But in this case, you are handling all the bridge states, so it should
not matter.

    Andrew
Raghavendra, Vignesh Dec. 3, 2020, 1:49 p.m. UTC | #2
On 11/30/20 10:50 PM, Andrew Lunn wrote:
>> +static int am65_cpsw_port_stp_state_set(struct am65_cpsw_port *port,

>> +					struct switchdev_trans *trans, u8 state)

>> +{

>> +	struct am65_cpsw_common *cpsw = port->common;

>> +	u8 cpsw_state;

>> +	int ret = 0;

>> +

>> +	if (switchdev_trans_ph_prepare(trans))

>> +		return 0;

>> +

>> +	switch (state) {

>> +	case BR_STATE_FORWARDING:

>> +		cpsw_state = ALE_PORT_STATE_FORWARD;

>> +		break;

>> +	case BR_STATE_LEARNING:

>> +		cpsw_state = ALE_PORT_STATE_LEARN;

>> +		break;

>> +	case BR_STATE_DISABLED:

>> +		cpsw_state = ALE_PORT_STATE_DISABLE;

>> +		break;

>> +	case BR_STATE_LISTENING:

>> +	case BR_STATE_BLOCKING:

>> +		cpsw_state = ALE_PORT_STATE_BLOCK;

>> +		break;

>> +	default:

>> +		return -EOPNOTSUPP;

>> +	}

> 

> Strictly speaking, the:

> 

>> +	if (switchdev_trans_ph_prepare(trans))

>> +		return 0;

> 

> should be here. In the prepare phase, you are suppose to validate you

> can do the requested action, and return an error is not. In second

> phase, actually carrying out the action, you then never return an

> error.

> 

> But in this case, you are handling all the bridge states, so it should

> not matter.

> 


Yeah, since driver is interested in all STP states, I preferred to
terminate the function early for prepare phase. Adding switch statement
with just "return 0" for all states during prepare phase looked
redundant to me.

Thanks for the review!

Regards
Vignesh