linux-dev/drivers/net/dsa/ocelot, branch master

net: dsa: felix: offload per-tc max SDU from tc-taprio

2022-09-30T01:52:05Z

Our current vsc9959_tas_guard_bands_update() algorithm has a limitation imposed by the hardware design. To avoid packet overruns between one gate interval and the next (which would add jitter for scheduled traffic in the next gate), we configure the switch to use guard bands. These are as large as the largest packet which is possible to be transmitted. The problem is that at tc-taprio intervals of sizes comparable to a guard band, there isn't an obvious place in which to split the interval between the useful portion (for scheduling) and the guard band portion (where scheduling is blocked). For example, a 10 us interval at 1Gbps allows 1225 octets to be transmitted. We currently split the interval between the bare minimum of 33 ns useful time (required to schedule a single packet) and the rest as guard band. But 33 ns of useful scheduling time will only allow a single packet to be sent, be that packet 1200 octets in size, or 60 octets in size. It is impossible to send 2 60 octets frames in the 10 us window. Except that if we reduced the guard band (and therefore the maximum allowable SDU size) to 5 us, the useful time for scheduling is now also 5 us, so more packets could be scheduled. The hardware inflexibility of not scheduling according to individual packet lengths must unfortunately propagate to the user, who needs to tune the queueMaxSDU values if he wants to fit more small packets into a 10 us interval, rather than one large packet. Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski

net: dsa: felix: update regmap requests to be string-based

2022-09-29T02:15:02Z

Existing felix DSA drivers (vsc9959, vsc9953) are all switches that were integrated in NXP SoCs, which makes them a bit unusual compared to the usual Microchip branded Ocelot switches. To be precise, looking at Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml, one can see 21 memory regions for the "switch" node, and these correspond to the "targets" of the switch IP, which are spread throughout the guts of that SoC's memory space. In NXP integrations, those targets still exist, but they were condensed within a single memory region, with no other peripheral in between them, so it made more sense for the driver to ioremap the entire memory space of the switch, and then find the targets within that memory space via some offsets hardcoded in the driver. The effect of this design decision is that now, the felix driver expects hardware instantiations to provide their own resource definitions, which is kind of odd when considering a typical device (those are retrieved from 'reg' properties in the device tree, using platform_get_resource() or similar). Allow other hardware instantiations that share the felix driver to not provide a hardcoded array of resources in the future. Instead, make the common denominator based on which regmaps are created be just the resource "names". Each instantiation comes with its own array of names that are mandatory for it, and with an optional array of resources. So we split the resources in 2 arrays, one is what's requested and the other is what's provided. There is one pool of provided resources, in felix->info->resources (of length felix->info->num_resources). There are 2 different ways of requesting a resource. One is by enum ocelot_target (this handles the global regmaps), and one is by int port (this handles the per-port ones). For the existing vsc9959 and vsc9953, it would be a bit stupid to request something that's not provided, given that the 2 arrays are both defined in the same place. The advantage is that we can now modify felix_request_regmap_by_name() to make felix->info->resources[] optional, and if absent, the implementation can call dev_get_regmap() and this is something that is compatible with MFD. Co-developed-by: Colin Foster Signed-off-by: Colin Foster Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski

net: dsa: felix: use DEFINE_RES_MEM_NAMED for resources

2022-09-29T02:14:56Z

Use less verbose resource definitions in vsc9959 and vsc9953. This also sets IORESOURCE_MEM in the constant array of resources, so we don't have to do this from felix_init_structs() - in fact, in the future, we may even support IORESOURCE_REG resources. Note that this macro takes start and length as argument, and we had start and end before. So transform end into length. While at it, sort the resources according to their offset. Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski

net: dsa: felix: remove felix_info :: init_regmap

2022-09-29T02:14:56Z

It turns out that the idea of having a customizable implementation of a regmap creation from a resource is not exactly useful. The idea was for the new MFD-based VSC7512 driver to use something that creates a SPI regmap from a resource. But there are problems in actually getting those resources (it involves getting them from MFD). To avoid all that, we'll be getting resources by name, so this custom init_regmap() method won't be needed. Remove it. Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski

net: dsa: felix: remove felix_info :: imdio_base

2022-09-29T02:14:55Z

This address is only relevant for the vsc9959, which is a PCIe device that holds its switch registers in a different PCIe BAR compared to the registers for the internal MDIO controller. Hide this aspect from the common felix driver and move the pci_resource_start() call to the only place that needs it, which is in vsc9959_mdio_bus_alloc(). Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski

net: dsa: felix: remove felix_info :: imdio_res

2022-09-29T02:14:55Z

The imdio_res is used only by vsc9959, which references its own vsc9959_imdio_res through the common felix_info->imdio_res pointer. Since the common code doesn't care about this resource (and it can't be part of the common array of resources, either, because it belongs in a different PCI BAR), just reference it directly. Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski

net: dsa: ocelot: remove unnecessary set_drvdata()

2022-09-23T02:30:38Z

Remove unnecessary set_drvdata(NULL) function in ->remove(), the driver_data will be set to NULL in device_unbind_cleanup() after calling ->remove(). Signed-off-by: Yang Yingliang Signed-off-by: Jakub Kicinski

net: dsa: felix: add support for changing DSA master

2022-09-20T08:32:36Z

Changing the DSA master means different things depending on the tagging protocol in use. For NPI mode ("ocelot" and "seville"), there is a single port which can be configured as NPI, but DSA only permits changing the CPU port affinity of user ports one by one. So changing a user port to a different NPI port globally changes what the NPI port is, and breaks the user ports still using the old one. To address this while still permitting the change of the NPI port, require that the user ports which are still affine to the old NPI port are down, and cannot be brought up until they are all affine to the same NPI port. The tag_8021q mode ("ocelot-8021q") is more flexible, in that each user port can be freely assigned to one CPU port or to the other. This works by filtering host addresses towards both tag_8021q CPU ports, and then restricting the forwarding from a certain user port only to one of the two tag_8021q CPU ports. Additionally, the 2 tag_8021q CPU ports can be placed in a LAG. This works by enabling forwarding via PGID_SRC from a certain user port towards the logical port ID containing both tag_8021q CPU ports, but then restricting forwarding per packet, via the LAG hash codes in PGID_AGGR, to either one or the other. When we change the DSA master to a LAG device, DSA guarantees us that the LAG has at least one lower interface as a physical DSA master. But DSA masters can come and go as lowers of that LAG, and ds->ops->port_change_master() will not get called, because the DSA master is still the same (the LAG). So we need to hook into the ds->ops->port_lag_{join,leave} calls on the CPU ports and update the logical port ID of the LAG that user ports are assigned to. Signed-off-by: Vladimir Oltean Signed-off-by: Paolo Abeni

net: dsa: propagate extack to port_lag_join

2022-09-20T08:32:36Z

Drivers could refuse to offload a LAG configuration for a variety of reasons, mainly having to do with its TX type. Additionally, since DSA masters may now also be LAG interfaces, and this will translate into a call to port_lag_join on the CPU ports, there may be extra restrictions there. Propagate the netlink extack to this DSA method in order for drivers to give a meaningful error message back to the user. Signed-off-by: Vladimir Oltean Signed-off-by: Paolo Abeni

net: mscc: ocelot: share the common stat definitions between all drivers

2022-09-09T09:59:12Z

All switch families supported by the ocelot lib (ocelot, felix, seville) export the same registers so far. But for example felix also has TSN counters, while the others don't. To reduce the bloat even further, create an OCELOT_COMMON_STATS() macro which just lists all stats that are common between switches. The array elements are still replicated among all of vsc9959_stats_layout, vsc9953_stats_layout and ocelot_stats_layout. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller