linux-dev/drivers/staging/fsl-dpaa2, branch master

staging: dpaa2-switch: move the driver out of staging

2021-03-10T21:30:36Z

Now that the dpaa2-switch driver has basic I/O capabilities on the switch port net_devices and multiple bridging domains are supported, move the driver out of staging. The dpaa2-switch driver is placed right next to the dpaa2-eth driver since, in the near future, they will be sharing most of the data path. I didn't implement code reuse in this patch series because I wanted to keep it as small as possible. Also, the README is removed from staging with the intention to add proper rst documentation afterwards to actually match was is supported by the driver. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller

staging: dpaa2-switch: prevent joining a bridge while VLAN uppers are present

2021-03-10T21:30:36Z

Each time a switch port joins a bridge, it will start to use a FDB table common with all the other switch ports that are under the same bridge. This means that any VLAN added prior to a bridge join, will retain its previous FDB table destination. With this patch, I choose to restrict when a switch port can change it's upper device (either join or leave) so that the driver does not have to delete all the previously installed VLANs from the previous FDB and add them into the new one. Thus, in the PRECHANGEUPPER notification we check if there are any VLAN type upper devices and if that's true, deny the CHANGEUPPER. This way, the user is not restricted in the topology but rather in the order in which the setup is done: it must first create the bridging domain layout and after that add the necessary VLAN devices if necessary. The teardown is similar, the VLAN devices will need to be destroyed prior to a change in the bridging layout. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller

staging: dpaa2-switch: add fast-ageing on bridge leave

2021-03-10T21:30:36Z

Upon leaving a bridge, any MAC addresses learnt on the switch port prior to this point have to be removed so that we preserve the bridging domain configuration. Restructure the dpaa2_switch_port_fdb_dump() function in order to have a common dpaa2_switch_fdb_iterate() function between the FDB dump callback and the fast age procedure. To accomplish this, add a new callback - dpaa2_switch_fdb_cb_t - which will be called on each MAC addr and, depending on the situation, will either dump the FDB entry into a netlink message or will delete the address from the FDB table, in case of the fast-age. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller

staging: dpaa2-switch: accept only vlan-aware upper devices

2021-03-10T21:30:36Z

The DPAA2 Switch is not capable to handle traffic in a VLAN unaware fashion, thus the previous handling of both the accepted upper devices and the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING flag was wrong. Fix this by checking if the bridge that we are joining is indeed VLAN aware, if not return an error. Also, the RX VLAN filtering feature is defined as 'on [fixed]' and the .ndo_vlan_rx_add_vid() and .ndo_vlan_rx_kill_vid() callbacks are implemented just by recreating a switchdev_obj_port_vlan object and then calling the same functions used on the switchdev notifier path. In addition, changing the vlan_filtering flag to 0 on a bridge under which a DPAA2 switch interface is present is not supported, thus rejected when SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING is received with such a request. This patch is also adding the use of the switchdev_handle_port_attr_set function so that we can iterate through all the lower devices of the bridge that the notification was received on and actually catch if the user is trying to change the vlan_filtering state. Since on a VLAN filtering change the net_device is the bridge, we also move the dpaa2_switch_port_dev_check call so that we do not return NOTIFY_DONE right away. Signed-off-by: Ioana Ciornei Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller

staging: dpaa2-switch: move the notifier register to module_init()

2021-03-10T21:30:36Z

Move the notifier blocks register into the module_init() step, instead of object probe, so that all DPSW devices probed by the dpaa2-switch driver can use the same notifiers. This will enable us to have a more straightforward approach in determining if an event is intended for an object managed by this driver or not. Previously, the dpaa2_switch_port_dev_check() function was forced to also check the notifier block beside the net_device_ops structure to determine if the event is for us or not. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller

staging: dpaa2-switch: properly setup switching domains

2021-03-10T21:30:36Z

Until now, the DPAA2 switch was not capable to properly setup its switching domains depending on the existence, or lack thereof, of a upper bridge device. This meant that all switch ports of a DPSW object were switching by default even though they were not under the same bridge device. Another issue was the inability to actually add the CPU in the flooding domains (broadcast, unknown unicast etc) of a particular switch port. This meant that a simple ping on a switch interface was not possible since no broadcast ARP frame would actually reach the CPU queues. This patch tries to fix exactly these problems by: * Creating and managing a FDB table for each flooding domain. This means that when a switch interface is not bridged it will use its own FDB table. While in bridged mode all DPAA2 switch interfaces under the same upper will use the same FDB table, thus leverage the same FDB entries. * Adding a new MC firmware command - dpsw_set_egress_flood() - through which the driver can setup the flooding domains as needed. For example, when the switch interface is standalone, thus not in a bridge with any other DPAA2 switch port, it will setup its broadcast and unknown unicast flooding domains to only include the control interface (the queues that reach the CPU and the driver can dequeue from). This flooding domain changes when the interface joins a bridge and is configured to include, beside the control interface, all other DPAA2 switch interfaces. We impose a minimum limit of FDB tables available equal to the number of switch interfaces so that we guarantee that, in the maximal configuration - all interfaces are standalone, each switch port will have a private FDB table. At the same time, we only probe DPSW objects that have the flooding and broadcast replicators configured to be per FDB (DPSW_*_PER_FDB). Without this, the dpaa2-switch driver would not be able to configure multiple switching domains. At probe time, a FDB table will be allocated for each port. At a bridge join event, the switch port will either continue to use the current FDB table (if it's the first dpaa2-switch port to join that bridge) or will switch to use the FDB table associated with the port that it's already under the bridge. If a FDB switch is necessary, the private FDB table which was previously used will be returned to the pool of unused FDBs. Upon a bridge leave, the switch port needs a private FDB table thus it will search and get the first unused FDB table. This way, all the other ports remaining under the bridge will continue to use the same FDB table. Signed-off-by: Ioana Ciornei Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller

staging: dpaa2-switch: enable the control interface

2021-03-10T21:30:36Z

Enable the CTRL_IF of the switch object, now that all the pieces are in place (buffer and queue management, interrupts, NAPI instances etc). Signed-off-by: Ioana Ciornei Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller

staging: dpaa2-switch: add .ndo_start_xmit() callback

2021-03-10T21:30:36Z

Implement the .ndo_start_xmit() callback for the switch port interfaces. For each of the switch ports, gather the corresponding queue destination ID (QDID) necessary for Tx enqueueing. We'll reserve 64 bytes for software annotations, where we keep a skb backpointer used on the Tx confirmation side for releasing the allocated memory. At the moment, we only support linear skbs. Also, add support for the Tx confirmation path which for the most part shares the code path with the normal Rx queue. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller

staging: dpaa2-switch: handle Rx path on control interface

2021-03-10T21:30:36Z

The dpaa2-ethsw supports only one Rx queue that is shared by all switch ports. This means that information about which port was the ingress port for a specific frame needs to be passed in metadata. In our case, the Flow Context (FLC) field from the frame descriptor holds this information. Besides the interface ID of the ingress port we also receive the virtual QDID of the port. Below is a visual description of the 64 bits of FLC. 63 47 31 15 0 +---------------------------------------------------+ | | | | | | RESERVED | IF_ID | RESERVED | IF QDID | | | | | | +---------------------------------------------------+ Because all switch ports share the same Rx and Tx conf queues, NAPI management takes into consideration when there is at least one switch interface open to enable the NAPI instance. The Rx path is common, for the most part, for both Rx and Tx conf with the mention that each of them has its own consume function of a frame descriptor. Dequeueing from a FQ, consuming dequeued store and also the NAPI poll function is common between both queues. Signed-off-by: Ioana Ciornei Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller

staging: dpaa2-switch: setup dpio

2021-03-10T21:30:36Z

Setup interrupts on the control interface queues. We do not force an exact affinity between the interrupts received from a specific queue and a cpu. Signed-off-by: Ioana Ciornei Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller