1. 07 6月, 2019 1 次提交
  2. 31 5月, 2019 1 次提交
  3. 29 5月, 2019 1 次提交
  4. 24 5月, 2019 1 次提交
  5. 21 5月, 2019 2 次提交
  6. 13 5月, 2019 1 次提交
  7. 11 5月, 2019 1 次提交
    • P
      net: ethernet: fix similar warning reported by kbuild test robot · 2d2924af
      Petr Štetiar 提交于
      This patch fixes following (similar) warning reported by kbuild test robot:
      
       In function ‘memcpy’,
        inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3,
        inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
        ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull]
        return __builtin_memcpy(p, q, size);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
        drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
        ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’
      
      I've replaced the offending memcpy with ether_addr_copy, because I'm
      100% sure, that of_get_mac_address can't return NULL as it returns valid
      pointer or ERR_PTR encoded value, nothing else.
      
      I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
      would make the warning disappear also, but it would be confusing to
      check for impossible return value just to make a compiler happy.
      
      I'm now changing all occurencies of memcpy to ether_addr_copy after the
      of_get_mac_address call, as it's very likely, that we're going to get
      similar reports from kbuild test robot in the future.
      
      Fixes: a51645f7 ("net: ethernet: support of_get_mac_address new ERR_PTR error")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NPetr Štetiar <ynezz@true.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d2924af
  8. 08 5月, 2019 2 次提交
  9. 06 5月, 2019 1 次提交
  10. 02 5月, 2019 4 次提交
    • M
      net: mvpp2: cls: Allow dropping packets with classification offload · bec2d46d
      Maxime Chevallier 提交于
      This commit introduces support for the "Drop" action in classification
      offload. This corresponds to the "-1" action with ethtool -N.
      
      This is achieved using the color marking actions available in the C2
      engine, which associate a color to a packet. These colors can be either
      Green, Yellow or Red, Red meaning that the packet should be dropped.
      
      Green and Yellow colors are interpreted by the Policer, which isn't
      supported yet.
      
      This method of dropping using the Classifier is different than the
      already existing early-drop features, such as VLAN filtering and MAC
      UC/MC filtering, which are performed during the Parsing step, and
      therefore take precedence over classification actions.
      Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bec2d46d
    • M
      net: mvpp2: cls: Add Classification offload support · 90b509b3
      Maxime Chevallier 提交于
      This commit introduces basic classification offloading support for the
      PPv2 controller.
      
      The PPv2 classifier has many classification engines, for now we only use
      the C2 TCAM match engine.
      
      This engine allows to perform ternary lookups on 64 bits keys (called
      Header Extracted Key), that are built by extracting fields from the packet
      header and concatenating them. At most 4 fields can be extracted for a
      single lookup.
      
      This basic implementation allows to build the HEK from the following
      fields :
       - L4 source and destination ports (for UDP and TCP)
      
      More fields are to be added in the future.
      
      Classification flows are added through the ethtool interface, using the
      newly introduced flow_rule infrastructure as an internal rule
      representation, allowing to more easily implement tc flower rules if
      need be.
      
      The internal design for now allocates one range of 4 rules per port
      due to the internal design of the flow table, which uses 22 sub-flows.
      
      When inserting a classification rule, the rule is created in every
      relevant sub-flow.
      
      This low rule-count is a very simple design which reaches quickly the
      limitations of the flow table ordering, but guarantees that the rule
      ordering will always be respected.
      
      This commit only introduces support for the "steer to rxq" action.
      Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90b509b3
    • M
      net: mvpp2: cls: Use a bitfield to represent the flow_type · 84e90b0b
      Maxime Chevallier 提交于
      As of today, the classification code is used only for RSS. We split the
      incoming traffic into multiple flows, that correspond to the ethtool
      flow_type parameter.
      
      We don't want to use the ethtool flow definitions such as TCP_V4_FLOW,
      for several reason :
      
       - We want to decorrelate the driver code from ethtool as much as
         possible, so that we can easily use other interfaces such as tc flower,
      
       - We want the flow_type to be a bitfield, so that we can match flows
         embedded into each other, such as TCP4 which is a subset of IP4.
      
      This commit does the conversion to the newer type.
      Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84e90b0b
    • M
      net: mvpp2: cls: Remove extra whitespace in mvpp2_cls_flow_write · 6f16a465
      Maxime Chevallier 提交于
      Cosmetic patch removing extra whitespaces when writing the flow_table
      entries
      Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f16a465
  11. 25 4月, 2019 1 次提交
  12. 08 4月, 2019 1 次提交
    • W
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon 提交于
      mmiowb() is now implied by spin_unlock() on architectures that require
      it, so there is no reason to call it from driver code. This patch was
      generated using coccinelle:
      
      	@mmiowb@
      	@@
      	- mmiowb();
      
      and invoked as:
      
      $ for d in drivers include/linux/qed sound; do \
      spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done
      
      NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
      spin_unlock(). However, pairing each mmiowb() removal in this patch with
      the corresponding call to spin_unlock() is not at all trivial, so there
      is a small chance that this change may regress any drivers incorrectly
      relying on mmiowb() to order MMIO writes between CPUs using lock-free
      synchronisation. If you've ended up bisecting to this commit, you can
      reintroduce the mmiowb() calls using wmb() instead, which should restore
      the old behaviour on all architectures other than some esoteric ia64
      systems.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fb24ea52
  13. 02 4月, 2019 1 次提交
    • F
      net: move skb->xmit_more hint to softnet data · 6b16f9ee
      Florian Westphal 提交于
      There are two reasons for this.
      
      First, the xmit_more flag conceptually doesn't fit into the skb, as
      xmit_more is not a property related to the skb.
      Its only a hint to the driver that the stack is about to transmit another
      packet immediately.
      
      Second, it was only done this way to not have to pass another argument
      to ndo_start_xmit().
      
      We can place xmit_more in the softnet data, next to the device recursion.
      The recursion counter is already written to on each transmit. The "more"
      indicator is placed right next to it.
      
      Drivers can use the netdev_xmit_more() helper instead of skb->xmit_more
      to check the "more packets coming" hint.
      
      skb->xmit_more is retained (but always 0) to not cause build breakage.
      
      This change takes care of the simple s/skb->xmit_more/netdev_xmit_more()/
      conversions.  Remaining drivers are converted in the next patches.
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b16f9ee
  14. 29 3月, 2019 1 次提交
    • M
      net: mvneta: Add 2500BaseT support · eda3d1b0
      Maxime Chevallier 提交于
      Some PHYs will use the 2500BaseX PHY_INTERFACE_MODE when being linked
      with a partner using 2.5GBaseT.
      
      Since we can't autonegotiate this speed between the MAC and the PHY, we
      need to have the proper comphy support enabled, to make sure we can
      safely advertise 2.5G and 1G in BaseT and be able to switch between both
      corresponding PHY interface modes. This is now possible since comphy
      support was added to this driver.
      
      This commit adds the 2500BaseT mode to the list of supported modes when
      using 2500BaseX, and was tested on a setup with an Armada385 and a
      88E2010 PHY, both with and without the comphy node in the DT.
      Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eda3d1b0
  15. 28 3月, 2019 18 次提交
  16. 05 3月, 2019 1 次提交
  17. 02 3月, 2019 2 次提交