linux/include/soc/mscc, branch v6.4

net: mscc: ocelot: add support for preemptible traffic classes

2023-04-18T02:01:19Z

In order to not transmit (preemptible) frames which will be received by the link partner as corrupted (because it doesn't support FP), the hardware requires the driver to program the QSYS_PREEMPTION_CFG_P_QUEUES register only after the MAC Merge layer becomes active (verification succeeds, or was disabled). There are some cases when FP is known (through experimentation) to be broken. Give priority to FP over cut-through switching, and disable FP for known broken link modes. Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Signed-off-by: Jakub Kicinski

net: mscc: ocelot: add support for mqprio offload

2023-04-18T02:01:19Z

This doesn't apply anything to hardware and in general doesn't do anything that the software variant doesn't do, except for checking that there isn't more than 1 TXQ per TC (TXQs for a DSA switch are a dubious concept anyway). The reason we add this is to be able to parse one more field added to struct tc_mqprio_qopt_offload, namely preemptible_tcs. Signed-off-by: Vladimir Oltean Reviewed-by: Ferenc Fejes Reviewed-by: Simon Horman Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski

net: mscc: ocelot: optimize ocelot_mm_irq()

2023-04-18T02:01:18Z

The MAC Merge IRQ of all ports is shared with the PTP TX timestamp IRQ of all ports, which means that currently, when a PTP TX timestamp is generated, felix_irq_handler() also polls for the MAC Merge layer status of all ports, looking for changes. This makes the kernel do more work, and under certain circumstances may make ptp4l require a tx_timestamp_timeout argument higher than before. Changes to the MAC Merge layer status are only to be expected under certain conditions - its TX direction needs to be enabled - so we can check early if that is the case, and omit register access otherwise. Make ocelot_mm_update_port_status() skip register access if mm->tx_enabled is unset, and also call it once more, outside IRQ context, from ocelot_port_set_mm(), when mm->tx_enabled transitions from true to false, because an IRQ is also expected in that case. Also, a port may have its MAC Merge layer enabled but it may not have generated the interrupt. In that case, there's no point in writing to DEV_MM_STATUS to acknowledge that IRQ. We can reduce the number of register writes per port with MM enabled by keeping an "ack" variable which writes the "write-one-to-clear" bits. Those are 3 in number: PRMPT_ACTIVE_STICKY, UNEXP_RX_PFRM_STICKY and UNEXP_TX_PFRM_STICKY. The other fields in DEV_MM_STATUS are read-only and it doesn't matter what is written to them, so writing zero is just fine. Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski

net: mscc: ocelot: remove struct ocelot_mm_state :: lock

2023-04-18T02:01:18Z

Unfortunately, the workarounds for the hardware bugs make it pointless to keep fine-grained locking for the MAC Merge state of each port. Our vsc9959_cut_through_fwd() implementation requires ocelot->fwd_domain_lock to be held, in order to serialize with changes to the bridging domains and to port speed changes (which affect which ports can be cut-through). Simultaneously, the traffic classes which can be cut-through cannot be preemptible at the same time, and this will depend on the MAC Merge layer state (which changes from threaded interrupt context). Since vsc9959_cut_through_fwd() would have to hold the mm->lock of all ports for a correct and race-free implementation with respect to ocelot_mm_irq(), in practice it means that any time a port's mm->lock is held, it would potentially block holders of ocelot->fwd_domain_lock. In the interest of simple locking rules, make all MAC Merge layer state changes (and preemptible traffic class changes) be serialized by the ocelot->fwd_domain_lock. Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski

net: mscc: ocelot: export a single ocelot_mm_irq()

2023-04-18T02:01:18Z

When the switch emits an IRQ, we don't know what caused it, and we iterate through all ports to check the MAC Merge status. Move that iteration inside the ocelot lib; we will change the locking in a future change and it would be good to encapsulate that lock completely within the ocelot lib. Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski

net: mscc: ocelot: strengthen type of "u32 reg" in I/O accessors

2023-04-14T04:56:06Z

The "u32 reg" argument that is passed to these functions is not a plain address, but rather a driver-specific encoding of another enum ocelot_target target in the upper bits, and an index into the u32 ocelot->map[target][] array in the lower bits. That encoded value takes the type "enum ocelot_reg" and is what is passed to these I/O functions, so let's actually use that to prevent type confusion. Signed-off-by: Vladimir Oltean Reviewed-by: Jacob Keller Signed-off-by: Jakub Kicinski

net: mscc: ocelot: expose serdes configuration function

2023-03-20T09:08:48Z

During chip initialization, ports that use SGMII / QSGMII to interface to external phys need to be configured on the VSC7513 and VSC7514. Expose this configuration routine, so it can be used by DSA drivers. Signed-off-by: Colin Foster Signed-off-by: David S. Miller

net: mscc: ocelot: expose generic phylink_mac_config routine

2023-03-20T09:08:48Z

The ocelot-switch driver can utilize the phylink_mac_config routine. Move this to the ocelot library location and export the symbol to make this possible. Signed-off-by: Colin Foster Signed-off-by: David S. Miller

net: mscc: ocelot: expose ocelot_pll5_init routine

2023-03-20T09:08:48Z

Ocelot chips have an internal PLL that must be used when communicating through external phys. Expose the init routine, so it can be used by other drivers. Signed-off-by: Colin Foster Signed-off-by: David S. Miller

net: mscc: ocelot: un-export unused regmap symbols

2023-02-07T06:33:15Z

There are no external users of the vsc7514_*_regmap[] symbols or vsc7514_vcap_* functions. They were exported in commit 32ecd22ba60b ("net: mscc: ocelot: split register definitions to a separate file") with the intention of being used, but the actual structure used in commit 2efaca411c96 ("net: mscc: ocelot: expose vsc7514_regmap definition") ended up being all that was needed. Bury these unnecessary symbols. Signed-off-by: Colin Foster Suggested-by: Vladimir Oltean Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20230204182056.25502-1-colin.foster@in-advantage.com Signed-off-by: Jakub Kicinski