Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 10月, 2020 4 次提交
    • V
      net: mscc: ocelot: offload VLAN mangle action to VCAP IS1 · 70edfae1
      由 Vladimir Oltean 提交于 
      The VCAP_IS1_ACT_VID_REPLACE_ENA action, from the VCAP IS1 ingress TCAM,
changes the classified VLAN.

We are only exposing this ability for switch ports that are under VLAN
aware bridges. This is because in standalone ports mode and under a
bridge with vlan_filtering=0, the ocelot driver configures the switch to
operate as VLAN-unaware, so the classified VLAN is not derived from the
802.1Q header from the packet, but instead is always equal to the
port-based VLAN ID of the ingress port. We _can_ still change the
classified VLAN for packets when operating in this mode, but the end
result will most likely be a drop, since both the ingress and the egress
port need to be members of the modified VLAN. And even if we install the
new classified VLAN into the VLAN table of the switch, the result would
still not be as expected: we wouldn't see, on the output port, the
modified VLAN tag, but the original one, even though the classified VLAN
was indeed modified. This is because of how the hardware works: on
egress, what is pushed to the frame is a "port tag", which gives us the
following options:

- Tag all frames with port tag (derived from the classified VLAN)
- Tag all frames with port tag, except if the classified VLAN is 0 or
  equal to the native VLAN of the egress port
- No port tag

Needless to say, in VLAN-unaware mode we are disabling the port tag.
Otherwise, the existing VLAN tag would be ignored, and a second VLAN
tag (the port tag), holding the classified VLAN, would be pushed
(instead of replacing the existing 802.1Q tag). This is definitely not
what the user wanted when installing a "vlan modify" action.

So it is simply not worth bothering with VLAN modify rules under other
configurations except when the ports are fully VLAN-aware.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      70edfae1
    • C
      enetc: Migrate to PHYLINK and PCS_LYNX · 71b77a7a
      由 Claudiu Manoil 提交于 
      This is a methodical transition of the driver from phylib
to phylink, following the guidelines from sfp-phylink.rst.
The MAC register configurations based on interface mode
were moved from the probing path to the mac_config() hook.
MAC enable and disable commands (enabling Rx and Tx paths
at MAC level) were also extracted and assigned to their
corresponding phylink hooks.
As part of the migration to phylink, the serdes configuration
from the driver was offloaded to the PCS_LYNX module,
introduced in commit 0da4c3d3 ("net: phy: add Lynx PCS module"),
the PCS_LYNX module being a mandatory component required to
make the enetc driver work with phylink.
Signed-off-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: NIoana Ciornei <ioana.cionei@nxp.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      71b77a7a
    • C
      enetc: Clean up serdes configuration · 46456ccf
      由 Claudiu Manoil 提交于 
      Decouple internal mdio bus creation from serdes
configuration, as a prerequisite to offloading
serdes configuration to a different module.
Group together mdio bus creation routines, cleanup.
Signed-off-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: NIoana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      46456ccf
    • C
      enetc: Clean up MAC and link configuration · 08f90fc9
      由 Claudiu Manoil 提交于 
      Decouple level MAC configuration based on phy interface type
from general port configuration.
Group together MAC and link configuration code.
Decouple external mdio bus creation from interface type
parsing.  No longer return an (unhandled) error code when
phy_node not found, use phy_node to indicate whether the
port has a phy or not.  No longer fall-through when serdes
configuration fails for the link modes that require
internal link configuration.
Signed-off-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: NIoana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      08f90fc9
  3. 11 10月, 2020 3 次提交
  5. 10 10月, 2020 19 次提交
  7. 09 10月, 2020 3 次提交
  9. 06 10月, 2020 4 次提交
  11. 05 10月, 2020 7 次提交
    • V
      net: dsa: propagate switchdev vlan_filtering prepare phase to drivers · 2e554a7a
      由 Vladimir Oltean 提交于 
      A driver may refuse to enable VLAN filtering for any reason beyond what
the DSA framework cares about, such as:
- having tc-flower rules that rely on the switch being VLAN-aware
- the particular switch does not support VLAN, even if the driver does
  (the DSA framework just checks for the presence of the .port_vlan_add
  and .port_vlan_del pointers)
- simply not supporting this configuration to be toggled at runtime

Currently, when a driver rejects a configuration it cannot support, it
does this from the commit phase, which triggers various warnings in
switchdev.

So propagate the prepare phase to drivers, to give them the ability to
refuse invalid configurations cleanly and avoid the warnings.

Since we need to modify all function prototypes and check for the
prepare phase from within the drivers, take that opportunity and move
the existing driver restrictions within the prepare phase where that is
possible and easy.

Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Woojung Huh <woojung.huh@microchip.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Landen Chao <Landen.Chao@mediatek.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Jonathan McDowell <noodles@earth.li>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e554a7a
    • T
      net: mvneta: fix double free of txq->buf · f4544e53
      由 Tom Rix 提交于 
      clang static analysis reports this problem:

drivers/net/ethernet/marvell/mvneta.c:3465:2: warning:
  Attempt to free released memory
        kfree(txq->buf);
        ^~~~~~~~~~~~~~~

When mvneta_txq_sw_init() fails to alloc txq->tso_hdrs,
it frees without poisoning txq->buf.  The error is caught
in the mvneta_setup_txqs() caller which handles the error
by cleaning up all of the txqs with a call to
mvneta_txq_sw_deinit which also frees txq->buf.

Since mvneta_txq_sw_deinit is a general cleaner, all of the
partial cleaning in mvneta_txq_sw_deinit()'s error handling
is not needed.

Fixes: 2adb719d ("net: mvneta: Implement software TSO")
Signed-off-by: NTom Rix <trix@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4544e53
    • M
      bnxt_en: Eliminate unnecessary RX resets. · 8d4bd96b
      由 Michael Chan 提交于 
      Currently, the driver will schedule RX ring reset when we get a buffer
error in the RX completion record.  These RX buffer errors can be due
to normal out-of-buffer conditions or a permanent error in the RX
ring.  Because the driver cannot distinguish between these 2
conditions, we assume all these buffer errors require reset.

This is very disruptive when it is just a normal out-of-buffer
condition.  Newer firmware will now monitor the rings for the permanent
failure and will send a notification to the driver when it happens.
This allows the driver to reset only when such a notification is
received.  In environments where we have predominently out-of-buffer
conditions, we now can avoid these unnecessary resets.
Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d4bd96b
    • M
      bnxt_en: Reduce unnecessary message log during RX errors. · 1b5c8b63
      由 Michael Chan 提交于 
      There is logic in the RX path to detect unexpected handles in the
RX completion.  We'll print a warning and schedule a reset.  The
next expected handle is then set to 0xffff which is guaranteed to
not match any valid handle.  This will force all remaining packets in
the ring to be discarded before the reset.  There can be hundreds of
these packets remaining in the ring and there is no need to print the
warnings for these forced errors.
Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com>
Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b5c8b63
    • M
      bnxt_en: Add a software counter for RX ring reset. · 8a27d4b9
      由 Michael Chan 提交于 
      Add a per ring rx_resets counter to count these RX resets.
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a27d4b9
    • M
      bnxt_en: Implement RX ring reset in response to buffer errors. · 8fbf58e1
      由 Michael Chan 提交于 
      On some older chips, it is necessary to do a reset when we get buffer
errors associated with an RX ring.  These buffer errors may become
frequent if the RX ring underruns under heavy traffic.  The current
code does a global reset of all reasources when this happens.  This
works but creates a big disruption of all rings when one RX ring is
having problem.  This patch implements a localized RX ring reset of
just the RX ring having the issue.  All other rings including all
TX rings will not be affected by this single RX ring reset.

Only the older chips prior to the P5 class supports this reset.
Because it is not a global reset, packets may still be arriving
while we are calling firmware to reset that ring.  We need to be
sure that we don't post any buffers during this time while the
ring is undergoing reset.  After firmware completes successfully,
the ring will be in the reset state with no buffers and we can start
filling it with new buffers and posting them.
Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: NEdwin Peer <edwin.peer@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8fbf58e1
    • M
      bnxt_en: Refactor bnxt_init_one_rx_ring(). · 7737d325
      由 Michael Chan 提交于 
      bnxt_init_one_rx_ring() includes logic to initialize the BDs for one RX
ring and to allocate the buffers.  Separate the allocation logic into a
new bnxt_alloc_one_rx_ring() function.  The allocation function will be
used later to allocate new buffers for one specified RX ring when we
reset that RX ring.
Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7737d325