Skip to content

L
linux
Switch branch/tag
  1. 22 Apr, 2021 10 commits
  3. 21 Apr, 2021 18 commits
  5. 20 Apr, 2021 12 commits
    • Radu Pirea (NXP OSS)'s avatar
      phy: nxp-c45-tja11xx: fix phase offset calculation · 6b3a6310
      Radu Pirea (NXP OSS) authored 
      Fix phase offset calculation.
Signed-off-by: default avatarRadu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b3a6310
    • Michael Walle's avatar
      net: enetc: automatically select IERB module · 1b8caefa
      Michael Walle authored 
      Now that enetc supports flow control we have to make sure the settings in
the IERB are correct. Therefore, we actually depend on the enetc-ierb
module. Previously it was possible that this module was disabled while the
enetc was enabled. Fix it by automatically select the enetc-ierb module.

Fixes: e7d48e5f ("net: enetc: add a mini driver for the Integrated Endpoint Register Block")
Signed-off-by: default avatarMichael Walle <michael@walle.cc>
Acked-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b8caefa
    • Eric Dumazet's avatar
      virtio-net: restrict build_skb() use to some arches · f5d7872a
      Eric Dumazet authored 
      build_skb() is supposed to be followed by
skb_reserve(skb, NET_IP_ALIGN), so that IP headers are word-aligned.
(Best practice is to reserve NET_IP_ALIGN+NET_SKB_PAD, but the NET_SKB_PAD
part is only a performance optimization if tunnel encaps are added.)

Unfortunately virtio_net has not provisioned this reserve.
We can only use build_skb() for arches where NET_IP_ALIGN == 0

We might refine this later, with enough testing.

Fixes: fb32856b ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5d7872a
    • Loic Poulain's avatar
      net: wwan: Fix bit ops double shift · b8c55ce2
      Loic Poulain authored 
      bit operation helpers such as test_bit, clear_bit, etc take bit
position as parameter and not value. Current usage causes double
shift => BIT(BIT(0)). Fix that in wwan_core and mhi_wwan_ctrl.

Fixes: 9a44c1cc ("net: Add a WWAN subsystem")
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarLoic Poulain <loic.poulain@linaro.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8c55ce2
    • David S. Miller's avatar
      Merge branch 'dsa-tag-override' · ebbcac3d
      David S. Miller authored 
      Tobias Waldekranz says:

====================
net: dsa: Allow default tag protocol to be overridden from DT

This is a continuation of the work started in this patch:
https://lore.kernel.org/netdev/20210323102326.3677940-1-tobias@waldekranz.com/

In addition to the mv88e6xxx support to dynamically change the
protocol, it is now possible to override the protocol from the device
tree. This means that when a board vendor finds an incompatibility,
they can specify a working protocol in the DT, and users will not have
to worry about it.

Some background information:

In a system using an NXP T1023 SoC connected to a 6390X switch, we
noticed that TO_CPU frames where not reaching the CPU. This only
happened on hardware port 8. Looking at the DSA master interface
(dpaa-ethernet) we could see that an Rx error counter was bumped at
the same rate. The logs indicated a parser error.

It just so happens that a TO_CPU coming in on device 0, port 8, will
result in the first two bytes of the DSA tag being one of:

00 40
00 44
00 46

My guess was that since these values looked like 802.3 length fields,
the controller's parser would signal an error if the frame length did
not match what was in the header.

This was later confirmed using two different workarounds provided by
Vladimir. Unfortunately these either bypass or ignore the hardware
parser and thus robs working combinations of the ability to do RSS and
other nifty things. It was therefore decided to go with the option of
a DT override.

v1 -> v2:
  - Fail if the device does not support changing protocols instead of
    falling back to the default. (Andrew)
  - Only call change_tag_protocol on CPU ports. (Andrew/Vladimir)
  - Only allow changing the protocol on chips that have at least
    "undocumented" level of support for EDSA. (Andrew).
  - List the supported protocols in the binding documentation. I opted
    for only listing the protocols that I have tested. As more people
    test their drivers, they can add them. (Rob)

v2 -> v3:
  - Rename "dsa,tag-protocol" -> "dsa-tag-protocol". (Rob)
  - Some cleanups to 4/5. (Vladimir)
  - Add a comment detailing how tree/driver agreement on the tag
    protocol is enforced. (Vladimir).
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebbcac3d
    • Tobias Waldekranz's avatar
      dt-bindings: net: dsa: Document dsa-tag-protocol property · eb78cace
      Tobias Waldekranz authored 
      The 'dsa-tag-protocol' is used to force a switch tree to use a
particular tag protocol, typically because the Ethernet controller
that it is connected to is not compatible with the default one.
Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb78cace
    • Tobias Waldekranz's avatar
      net: dsa: Allow default tag protocol to be overridden from DT · deff7107
      Tobias Waldekranz authored 
      Some combinations of tag protocols and Ethernet controllers are
incompatible, and it is hard for the driver to keep track of these.

Therefore, allow the device tree author (typically the board vendor)
to inform the driver of this fact by selecting an alternate protocol
that is known to work.
Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      deff7107
    • Tobias Waldekranz's avatar
      net: dsa: Only notify CPU ports of changes to the tag protocol · 21e0b508
      Tobias Waldekranz authored 
      Previously DSA ports were also included, on the assumption that the
protocol used by the CPU port had to the matched throughout the entire
tree.

As there is not yet any consumer in need of this, drop the call.
Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21e0b508
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol · 9a99bef5
      Tobias Waldekranz authored 
      For devices that supports both regular and Ethertyped DSA tags, allow
the user to change the protocol.

Additionally, because there are ethernet controllers that do not
handle regular DSA tags in all cases, also allow the protocol to be
changed on devices with undocumented support for EDSA. But, in those
cases, make sure to log the fact that an undocumented feature has been
enabled.
Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a99bef5
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: Mark chips with undocumented EDSA tag support · 670bb80f
      Tobias Waldekranz authored 
      All devices are capable of using regular DSA tags. Support for
Ethertyped DSA tags sort into three categories:

1. No support. Older chips fall into this category.

2. Full support. Datasheet explicitly supports configuring the CPU
   port to receive FORWARDs with a DSA tag.

3. Undocumented support. Datasheet lists the configuration from
   category 2 as "reserved for future use", but does empirically
   behave like a category 2 device.

So, instead of listing the one true protocol that should be used by a
particular chip, specify the level of support for EDSA (support for
regular DSA is implicit on all chips). As before, we use EDSA for all
chips that fully supports it.

In upcoming changes, we will use this information to support
dynamically changing the tag protocol.
Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      670bb80f
    • David S. Miller's avatar
      Merge tag 'mac80211-next-for-net-next-2021-04-20' of... · 08322284
      David S. Miller authored 
      Merge tag 'mac80211-next-for-net-next-2021-04-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

Johannes Berg says:

====================
Another set of updates, all over the map:
 * set sk_pacing_shift for 802.3->802.11 encap offload
 * some monitor support for 802.11->802.3 decap offload
 * HE (802.11ax) spec updates
 * userspace API for TDLS HE support
 * along with various other small features, cleanups and
   fixups
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      08322284
    • David S. Miller's avatar
      Merge branch 'mlxsw-refactor-qdisc-offload' · c9ad2057
      David S. Miller authored 
      Petr Machata says:

====================
mlxsw: Refactor qdisc offload

Currently, mlxsw admits for offload a suitable root qdisc, and its
children. Thus up to two levels of hierarchy are offloaded. Often, this is
enough: one can configure TCs with RED and TCs with a shaper, and can even
see counters for each TC by looking at a qdisc at a sufficiently shallow
position.

While simple, the system has obvious shortcomings. It is not possible to
configure both RED and shaping on one TC. It is not possible to place a
PRIO below root TBF, which would then be offloaded as port shaper. FIFOs
are only offloaded at root or directly below, which is confusing to users,
because RED and TBF of course have their own FIFO.

This patchset is a step towards the end goal of allowing more comprehensive
qdisc tree offload and cleans up the qdisc offload code.

- Patches #1-#4 contain small cleanups.

- Up until now, since mlxsw offloaded only a very simple qdisc
  configurations, basically all bookkeeping was done using one container
  for the root qdisc, and 8 containers for its children. Patches #5, #6, #8
  and #9 gradually introduce a more dynamic structure, where parent-child
  relationships are tracked directly at qdiscs, instead of being implicit.

- This tree management assumes only one qdisc is created at a time. In FIFO
  handlers, this condition was enforced simply by asserting RTNL lock. But
  instead of furthering this RTNL dependence, patch #7 converts the whole
  qdisc offload logic to a per-port mutex.

- Patch #10 adds a selftest.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9ad2057
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7