- 22 Apr, 2021 7 commits
-
-
Qi Zhang authored
Currently, RSS hash input is not available to AVF by ethtool, it is set by the PF directly. Add the RSS configure support for AVF through new virtchnl message, and define the capability flag VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF to query this new RSS offload support. Signed-off-by:
Jia Guo <jia.guo@intel.com> Signed-off-by:
Qi Zhang <qi.z.zhang@intel.com> Signed-off-by:
Haiyue Wang <haiyue.wang@intel.com> Tested-by:
Bo Chen <BoX.C.Chen@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Brett Creeley authored
Currently, the driver gets the VF's VSI by using a long string of dereferences (i.e. vf->pf->vsi[vf->lan_vsi_idx]). If the method to get the VF's VSI were to change the driver would have to change it in every location. Fix this by adding the helper ice_get_vf_vsi(). Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Tested-by:
Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by:
-
Colin Ian King authored
Pointer vsi is being re-assigned a value that is never read, the assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Brett Creeley authored
Add code to support UDP segmentation offload (USO) for hardware that supports it. Suggested-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
Brett Creeley authored
As the hardware is capable of supporting UDP segmentation offload, add a capability bit to virtchnl.h to communicate this and have the driver advertise its support. Suggested-by:
-
Michal Swiatkowski authored
Declare bitmap of allowed commands on VF. Initialize default opcodes list that should be always supported. Declare array of supported opcodes for each caps used in virtchnl code. Change allowed bitmap by setting or clearing corresponding bit to allowlist (bit set) or denylist (bit clear). Signed-off-by:
Michal Swiatkowski <michal.swiatkowski@intel.com> Tested-by:
-
Vignesh Sridhar authored
Attempt to detect malicious VFs and, if suspected, log the information but keep going to allow the user to take any desired actions. Potentially malicious VFs are identified by checking if the VFs are transmitting too many messages via the PF-VF mailbox which could cause an overflow of this channel resulting in denial of service. This is done by creating a snapshot or static capture of the mailbox buffer which can be traversed and in which the messages sent by VFs are tracked. Co-developed-by:
Yashaswini Raghuram Prathivadi Bhayankaram <yashaswini.raghuram.prathivadi.bhayankaram@intel.com> Signed-off-by:
Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Signed-off-by:
Vignesh Sridhar <vignesh.sridhar@intel.com> Tested-by:
-
- 21 Apr, 2021 18 commits
-
-
Marek Behún authored
This causes error reported by kernel test robot. Signed-off-by:
Marek Behún <kabel@kernel.org> Fixes: 41d26bf4 ("net: phy: marvell: refactor HWMON OOP style") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
When CONFIG_NET_SWITCHDEV is disabled, the shim for switchdev_port_attr_set inside br_mc_disabled_update returns -EOPNOTSUPP. This is not caught, and propagated to the caller of br_multicast_add_port, preventing ports from joining the bridge. Reported-by:
Christian Borntraeger <borntraeger@de.ibm.com> Fixes: ae1ea84b ("net: bridge: propagate error code and extack from br_mc_disabled_update") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Adam Ford authored
The call to clk_disable_unprepare() can happen before priv is initialized. This means moving clk_disable_unprepare out of out_release into a new label. Fixes: 8ef7adc6 ("net: ethernet: ravb: Enable optional refclk") Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Sergei Shtylyov <sergei.shtylyov@gmail.com> Signed-off-by:
-
Ong Boon Leong authored
TSO and TBS cannot coexist, for now we set Intel mGbE controller to use below TX Queue mapping: TxQ0 uses TSO and the rest of TXQs supports TBS. Signed-off-by:
Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by:
-
Oleksij Rempel authored
Starting with patch: a8b659e7 ("net: dsa: act as passthrough for bridge port flags") drivers without "port_bridge_flags" callback will fail to join the bridge. Looking at the code, -EOPNOTSUPP seems to be the proper return value, which makes at least microchip and atheros switches work again. Fixes: 5961d6a1 ("net: dsa: inherit the actual bridge port flags at join time") Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
-
Dan Carpenter authored
We recently added some new locking to this function but one error path was overlooked. We need to drop the lock before returning. Fixes: f4da5652 ("net: stmmac: Add support for external trigger timestamping") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by:
-
David S. Miller authored
Tobias Waldekranz says: ==================== net: dsa: mv88e6xxx: Tiny fixes/improvements Just some small things I have noticed that do not fit in any other series. ==================== Signed-off-by: -
Tobias Waldekranz authored
Export the raw PVT data in a devlink region so that it can be inspected from userspace and compared to the current bridge configuration. Signed-off-by:
Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Tobias Waldekranz authored
In the unlikely event of the VTU being loaded to the brim with 4k entries, the last one was placed in the buffer, but the size reported to devlink was off-by-one. Make sure that the final entry is available to the caller. Fixes: ca4d632a ("net: dsa: mv88e6xxx: Export VTU as devlink region") Signed-off-by:
-
Tobias Waldekranz authored
Because ADRR is not a thing. Signed-off-by:
-
David S. Miller authored
Srujana Challa says: ==================== Add support for CN10K CPT block OcteonTX3 (CN10K) silicon is a Marvell next-gen silicon. CN10K CPT introduces new features like reassembly support and some feature enhancements. This patchset adds new mailbox messages and some minor changes to existing mailbox messages to support CN10K CPT. v1-v2 Fixed sparse warnings. ==================== Signed-off-by: -
Srujana Challa authored
Adds a new mailbox to get CPT stats, includes performance counters, CPT engines status and RXC status. Signed-off-by:
Narayana Prasad Raju Atherya <pathreya@marvell.com> Signed-off-by:
Srujana Challa <schalla@marvell.com> Signed-off-by:
-
Srujana Challa authored
CN10K CPT coprocessor includes a component named RXC which is responsible for reassembly of inner IP packets. RXC has the feature to evict oldest entries based on age/threshold. This patch adds a new mailbox to configure reassembly age or threshold. Signed-off-by:
Jerin Jacob Kollanukkaran <jerinj@marvell.com> Signed-off-by:
-
Srujana Challa authored
Adds changes to existing CPT mailbox messages to support CN10K CPT block. This patch also adds new register defines for CN10K CPT. Signed-off-by:
Vidya Sagar Velumuri <vvelumuri@marvell.com> Signed-off-by:
-
Loic Poulain authored
The mhi_wwan_rx_budget_dec function is supposed to return true if RX buffer budget has been successfully decremented, allowing to queue a new RX buffer for transfer. However the current implementation is broken when RX budget is '1', in which case budget is decremented but false is returned, preventing to requeue one buffer, and leading to RX buffer starvation. Fixes: fa588eba ("net: Add Qcom WWAN control driver") Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Michael Walle authored
The commit c329e5af ("net: phy: at803x: select correct page on config init") selects the copper page during probe. This fails if the copper page was already selected. In this case, the value of the copper page (which is 1) is propagated through phy_restore_page() and is finally returned for at803x_probe(). Fix it, by just using the at803x_page_write() directly. Also in case of an error, the regulator is not disabled and leads to a WARN_ON() when the probe fails. This couldn't happen before, because at803x_parse_dt() was the last call in at803x_probe(). It is hard to see, that the parse_dt() actually enables the regulator. Thus move the regulator_enable() to the probe function and undo it in case of an error. Fixes: c329e5af ("net: phy: at803x: select correct page on config init") Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
David Bauer <mail@david-bauer.net> Signed-off-by:
-
Colin Ian King authored
The variable err is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed Addresses-Coverity: ("Unused value") Signed-off-by: -
Eric Dumazet authored
KASAN/syzbot had 4 reports, one of them being: BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline] BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480 Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445 CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436 check_region_inline mm/kasan/generic.c:180 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186 memcpy+0x20/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [inline] page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480 receive_mergeable drivers/net/virtio_net.c:1009 [inline] receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119 virtnet_receive drivers/net/virtio_net.c:1411 [inline] virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516 __napi_poll+0xaf/0x440 net/core/dev.c:6962 napi_poll net/core/dev.c:7029 [inline] net_rx_action+0x801/0xb40 net/core/dev.c:7116 __do_softirq+0x29b/0x9fe kernel/softirq.c:559 invoke_softirq kernel/softirq.c:433 [inline] __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637 irq_exit_rcu+0x5/0x20 kernel/softirq.c:649 common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240 Fixes: fb32856b ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Reported-by:
Guenter Roeck <linux@roeck-us.net> Reported-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> 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 Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
- 20 Apr, 2021 15 commits
-
-
Radu Pirea (NXP OSS) authored
Fix phase offset calculation. Signed-off-by:
Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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: -
Petr Machata authored
There was a bug introduced during the rework which cause non-zero backlog being stuck at ETS. Introduce a selftest that would have caught the issue earlier. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Petr Machata authored
mlxsw used to hold an array of qdiscs indexed by the TC number. In the previous patch, it was changed to allocate child qdiscs dynamically, and they are now indexed by band number. Follow suit with the array of future FIFOs. Signed-off-by:
-
Petr Machata authored
Instead of keeping qdiscs in globally-preallocated arrays, introduce a per-qdisc-kind value num_classes, and then allocate the necessary child qdiscs (if any) based on that value. Since now dynamic allocation is involved, mlxsw_sp_qdisc_replace() gets messy enough that it is worth it to split it to two cases: a new qdisc allocation and a change of existing qdisc. (Note that the change also includes what TC formally calls replace, if the qdisc kind is the same.) Signed-off-by:
-
