- 12 Jul, 2022 40 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220711090549.543317027@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Fenil Jain <fkjainco@gmail.com> Tested-by:
Rudi Heitbaum <rudi@heitbaum.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dave Jiang authored
commit 44c4237c upstream. Testing shown that when a wq mode is setup to be dedicated and then torn down and reconfigured to shared, the wq configured end up being dedicated anyays. The root cause is when idxd_device_wqs_clear_state() gets called during idxd_driver removal, idxd_wq_disable_cleanup() does not get called vs when the wq driver is removed first. The check of wq state being "enabled" causes the cleanup to be bypassed. However, idxd_driver->remove() releases all wq drivers. So the wqs goes to "disabled" state and will never be "enabled". By that point, the driver has no idea if the wq was previously configured or clean. So force call idxd_wq_disable_cleanup() on all wqs always to make sure everything gets cleaned up. Reported-by:
Tony Zhu <tony.zhu@intel.com> Tested-by:
Dave Jiang <dave.jiang@intel.com> Co-developed-by:
Fenghua Yu <fenghua.yu@intel.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Miaoqian Lin authored
commit 615a4bfc upstream. of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Fixes: a074ae38 ("dmaengine: Add driver for TI DMA crossbar on DRA7x") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Acked-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20220605042723.17668-1-linmq006@gmail.com Signed-off-by:
-
Caleb Connolly authored
commit 0ac9c3dd upstream. Commit dbad41e7 ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") caused unbalanced pm_runtime_get/put() calls when the bam is controlled remotely. This commit reverts it and just enables pm_runtime in all cases, the clk_* functions already just nop when the clock is NULL. Also clean up a bit by removing unnecessary bamclk null checks. Suggested-by:
Stephan Gerhold <stephan@gerhold.net> Fixes: dbad41e7 ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") Signed-off-by:
Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20220629140559.118537-1-caleb.connolly@linaro.org Signed-off-by:
-
Miaoqian Lin authored
commit c132fe78 upstream. of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in to fix this. Fixes: ec9bfa1e ("dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr") Signed-off-by:
-
Michael Walle authored
commit 3770d92b upstream. It seems that it is valid to have less than the requested number of descriptors. But what is not valid and leads to subsequent errors is to have zero descriptors. In that case, abort the probing. Fixes: e1f7c9ee ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by:
Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20220526135111.1470926-1-michael@walle.cc Signed-off-by:
-
Christophe JAILLET authored
commit 1dbe67b9 upstream. ldma_clk_disable() calls both: clk_disable_unprepare(d->core_clk); reset_control_assert(d->rst); So, should devm_reset_control_get_optional() fail, core_clk should not be prepare_enable'd before it, otherwise it will never be disable_unprepare'd. Reorder the code to handle the error handling path as expected. Fixes: 32d31c79 ("dmaengine: Add Intel LGM SoC DMA support.") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/18504549bc4d2b62a72a02cb22a2e4d8e6a58720.1653241224.git.christophe.jaillet@wanadoo.fr Signed-off-by:
-
Dmitry Osipenko authored
commit b64b3b2f upstream. The DEFINE_SPINLOCK() macro shouldn't be used for dynamically allocated spinlocks. The lockdep warns about this and disables locking validator. Fix the warning by making lock static. INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Hardware name: Radxa ROCK Pi 4C (DT) Call trace: dump_backtrace.part.0+0xcc/0xe0 show_stack+0x18/0x6c dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 register_lock_class+0x4a8/0x4cc __lock_acquire+0x78/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 _raw_spin_lock_irqsave+0x84/0xc4 add_desc+0x44/0xc0 pl330_get_desc+0x15c/0x1d0 pl330_prep_dma_cyclic+0x100/0x270 snd_dmaengine_pcm_trigger+0xec/0x1c0 dmaengine_pcm_trigger+0x18/0x24 ... Fixes: e5887103 ("dmaengine: pl330: fix descriptor allocation fail") Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20220520181432.149904-1-dmitry.osipenko@collabora.com Signed-off-by:
-
Linus Torvalds authored
commit fc82bbf4 upstream. This is another old BUG_ON() that just shouldn't exist (see also commit a382f8fe: "signal handling: don't use BUG_ON() for debugging"). In fact, as Matthew Wilcox points out, this condition shouldn't really even result in a warning, since a negative id allocation result is just a normal allocation failure: "I wonder if we should even warn here -- sure, the caller is trying to free something that wasn't allocated, but we don't warn for kfree(NULL)" and goes on to point out how that current error check is only causing people to unnecessarily do their own index range checking before freeing it. This was noted by Itay Iellin, because the bluetooth HCI socket cookie code does *not* do that range checking, and ends up just freeing the error case too, triggering the BUG_ON(). The HCI code requires CAP_NET_RAW, and seems to just result in an ugly splat, but there really is no reason to BUG_ON() here, and we have generally striven for allocation models where it's always ok to just do free(alloc()); even if the allocation were to fail for some random reason (usually obviously that "random" reason being some resource limit). Fixes: 88eca020 ("ida: simplified functions for id allocation") Reported-by:
Itay Iellin <ieitayie@gmail.com> Suggested-by:
Matthew Wilcox <willy@infradead.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Samuel Holland authored
commit 607a48c7 upstream. The conditional block for variants with a second clock should have set minItems, not maxItems, which was already 2. Since clock-names requires two items, this typo should not have caused any problems. Fixes: edd14218 ("dt-bindings: dmaengine: Convert Allwinner A31 and A64 DMA to a schema") Signed-off-by:
Samuel Holland <samuel@sholland.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220702031903.21703-1-samuel@sholland.org Signed-off-by:
-
Emil Renner Berthing authored
commit 49db68d4 upstream. When the DMA is configured for more than 8 channels the bits controlling suspend moves to another register. However when adding support for this the new register would be completely overwritten in one case and overwritten with values from the old register in another case. Found by comparing the parallel implementation of more than 8 channel support for the StarFive JH7100 SoC by Samin. Fixes: 82435166 ("dmaengine: dw-axi-dmac: support DMAX_NUM_CHANNELS > 8") Co-developed-by:
Samin Guo <samin.guo@starfivetech.com> Signed-off-by:
Emil Renner Berthing <kernel@esmil.dk> Link: https://lore.kernel.org/r/20220627090939.1775717-1-emil.renner.berthing@canonical.com Signed-off-by:
-
Shuah Khan authored
commit 2cd37c2e upstream. Set return value in rsp_buf alloc error path before going to error handling. drivers/misc/cardreader/rtsx_usb.c:639:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] if (!ucr->rsp_buf) ^~~~~~~~~~~~~ drivers/misc/cardreader/rtsx_usb.c:678:9: note: uninitialized use occurs here return ret; ^~~ drivers/misc/cardreader/rtsx_usb.c:639:2: note: remove the 'if' if its condition is always false if (!ucr->rsp_buf) ^~~~~~~~~~~~~~~~~~ drivers/misc/cardreader/rtsx_usb.c:622:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 Fixes: 3776c785 ("misc: rtsx_usb: use separate command and response buffers") Reported-by:
kernel test robot <lkp@intel.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Shuah Khan authored
commit 3776c785 upstream. rtsx_usb uses same buffer for command and response. There could be a potential conflict using the same buffer for both especially if retries and timeouts are involved. Use separate command and response buffers to avoid conflicts. Signed-off-by:
-
Shuah Khan authored
commit eb7f8e28 upstream. rtsx_usb driver allocates coherent dma buffer for urb transfers. This buffer is passed to usb_bulk_msg() and usb core tries to map already mapped buffer running into a dma mapping error. xhci_hcd 0000:01:00.0: rejecting DMA map of vmalloc memory WARNING: CPU: 1 PID: 279 at include/linux/dma-mapping.h:326 usb_ hcd_map_urb_for_dma+0x7d6/0x820 ... xhci_map_urb_for_dma+0x291/0x4e0 usb_hcd_submit_urb+0x199/0x12b0 ... usb_submit_urb+0x3b8/0x9e0 usb_start_wait_urb+0xe3/0x2d0 usb_bulk_msg+0x115/0x240 rtsx_usb_transfer_data+0x185/0x1a8 [rtsx_usb] rtsx_usb_send_cmd+0xbb/0x123 [rtsx_usb] rtsx_usb_write_register+0x12c/0x143 [rtsx_usb] rtsx_usb_probe+0x226/0x4b2 [rtsx_usb] Fix it to use kmalloc() to get DMA-able memory region instead. Signed-off-by:
-
Sascha Hauer authored
commit 09f7b80f upstream. An interrupt for a channel might be pending even after struct dma_device::device_terminate_all has been called. In that case the recently introduced warning message "restart cyclic channel..." triggers and the channel will be restarted. This is not desired as the channel has just been stopped. Only restart the channel when we still have a descriptor set for it (which will be set to NULL in sdma_terminate_all()). Fixes: 5b215c28 ("dmaengine: imx-sdma: restart cyclic channel if needed") Cc: stable@vger.kernel.org Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20220617115042.4004062-1-s.hauer@pengutronix.de Signed-off-by:
-
Peter Robinson authored
commit a7cd3cf0 upstream. The revision of the imx-sdma IP that is in the i.MX8M series is the same is that as that in the i.MX7 series but the imx7d MODULE_FIRMWARE directive is wrapped in a condiditional which means it's not defined when built for aarch64 SOC_IMX8M platforms and hence you get the following errors when the driver loads on imx8m devices: imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 imx-sdma 302c0000.dma-controller: external firmware not found, using ROM firmware Add the SOC_IMX8M into the check so the firmware can load on i.MX8. Fixes: 1474d48b ("arm64: dts: imx8mq: Add SDMA nodes") Fixes: 941acd56 ("dmaengine: imx-sdma: Only check ratio on parts that support 1:1") Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Cc: stable@vger.kernel.org # v5.2+ Reviewed-by:
Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20220606161034.3544803-1-pbrobinson@gmail.com Signed-off-by:
-
Vlad Buslov authored
[ Upstream commit 052f744f ] Offloading police with action TC_ACT_UNSPEC was erroneously disabled even though it was supported by mlx5 matchall offload implementation, which didn't verify the action type but instead assumed that any single police action attached to matchall classifier is a 'continue' action. Lack of action type check made it non-obvious what mlx5 matchall implementation actually supports and caused implementers and reviewers of referenced commits to disallow it as a part of improved validation code. Fixes: b8cd5831 ("net: flow_offload: add tc police action parameters") Fixes: b50e462b ("net/sched: act_police: Add extack messages for offload failure") Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Tested-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ido Schimmel authored
[ Upstream commit b50e462b ] For better error reporting to user space, add extack messages when police action offload fails. Example: # echo 1 > /sys/kernel/tracing/events/netlink/netlink_extack/enable # tc filter add dev dummy0 ingress pref 1 proto all matchall skip_sw action police rate 100Mbit burst 10000 Error: cls_matchall: Failed to setup flow action. We have an error talking to the kernel # cat /sys/kernel/tracing/trace_pipe tc-182 [000] b..1. 21.592969: netlink_extack: msg=act_police: Offload not supported when conform/exceed action is "reclassify" tc-182 [000] ..... 21.592982: netlink_extack: msg=cls_matchall: Failed to setup flow action # tc filter add dev dummy0 ingress pref 1 proto all matchall skip_sw action police rate 100Mbit burst 10000 conform-exceed drop/continue Error: cls_matchall: Failed to setup flow action. We have an error talking to the kernel # cat /sys/kernel/tracing/trace_pipe tc-184 [000] b..1. 38.882579: netlink_extack: msg=act_police: Offload not supported when conform/exceed action is "continue" tc-184 [000] ..... 38.882593: netlink_extack: msg=cls_matchall: Failed to setup flow action Signed-off-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
[ Upstream commit c2ccf84e ] The callback is used by various actions to populate the flow action structure prior to offload. Pass extack to this callback so that the various actions will be able to report accurate error messages to user space. Signed-off-by:
-
Satish Nagireddy authored
[ Upstream commit 3501f0c6 ] This patch ensures that the clock notifier is unregistered when driver probe is returning error. Fixes: df8eb569 ("i2c: Add driver for Cadence I2C controller") Signed-off-by:
Satish Nagireddy <satish.nagireddy@getcruise.com> Tested-by:
Lars-Peter Clausen <lars@metafoo.de> Reviewed-by:
Michal Simek <michal.simek@amd.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Heiner Kallweit authored
[ Upstream commit faa4e04e ] 66e4c8d9 ("net: warn if transport header was not set") added a check that triggers a warning in r8169, see [0]. The commit referenced in the Fixes tag refers to the change from which the patch applies cleanly, there's nothing wrong with this commit. It seems the actual issue (not bug, because the warning is harmless here) was introduced with bdfa4ed6 ("r8169: use Giant Send"). [0] https://bugzilla.kernel.org/show_bug.cgi?id=216157 Fixes: 8d520b4d ("r8169: work around RTL8125 UDP hw bug") Reported-by:
Erhard F. <erhard_f@mailbox.org> Tested-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/1b2c2b29-3dc0-f7b6-5694-97ec526d51a0@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit 843b5e75 ] In mptcp_pm_nl_rm_addr_or_subflow() we always mark as available the id corresponding to the just removed address. The used bitmap actually tracks only the local IDs: we must restrict the operation when a (local) subflow is removed. Fixes: a88c9e49 ("mptcp: do not block subflows creation on errors") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Mat Martineau authored
[ Upstream commit a6574302 ] When setting up a subflow's flags for sending MP_PRIO MPTCP options, the subflow socket lock was not held while reading and modifying several struct members that are also read and modified in mptcp_write_options(). Acquire the subflow socket lock earlier and send the MP_PRIO ACK with that lock already acquired. Add a new variant of the mptcp_subflow_send_ack() helper to use with the subflow lock held. Fixes: 06706542 ("mptcp: add the outgoing MP_PRIO support") Acked-by:
-
Mat Martineau authored
[ Upstream commit c21b50d5 ] The in-kernel path manager code for changing subflow flags acquired both the msk socket lock and the PM lock when possibly changing the "backup" and "fullmesh" flags. mptcp_pm_nl_mp_prio_send_ack() does not access anything protected by the PM lock, and it must release and reacquire the PM lock. By pushing the PM lock to where it is needed in mptcp_pm_nl_fullmesh(), the lock is only acquired when the fullmesh flag is changed and the backup flag code no longer has to release and reacquire the PM lock. The change in locking context requires the MIB update to be modified - move that to a better location instead. This change also makes it possible to call mptcp_pm_nl_mp_prio_send_ack() for the userspace PM commands without manipulating the in-kernel PM lock. Fixes: 0f9f696a ("mptcp: add set_flags command in PM netlink") Acked-by:
-
Vlad Buslov authored
[ Upstream commit 4d1e07d8 ] Referenced commit prepared the code for upcoming extension that allows mlx5 to offload police action attached to flower classifier. However, with regard to existing matchall classifier offload validation should be reversed as FLOW_ACTION_CONTINUE is the only supported notexceed police action type. Fix the problem by allowing FLOW_ACTION_CONTINUE for police action and extend scan_tc_matchall_fdb_actions() to only allow such actions with matchall classifier. Fixes: d97b4b10 ("flow_offload: reject offload for all drivers with invalid police parameters") Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Mario Limonciello authored
[ Upstream commit 8b356e53 ] commit 72f2ecb7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") added support for claiming to support CPPC in _OSC on non-Intel platforms. This unfortunately caused a regression on a vartiety of AMD platforms in the field because a number of AMD platforms don't set the `_OSC` bit 5 or 6 to indicate CPPC or CPPC v2 support. As these AMD platforms already claim CPPC support via a dedicated MSR from `X86_FEATURE_CPPC`, use this enable this feature rather than requiring the `_OSC` on platforms with a dedicated MSR. If there is additional breakage on the shared memory designs also missing this _OSC, additional follow up changes may be needed. Fixes: 72f2ecb7 ("Set CPPC _OSC bits for all and when CPPC_LIB is supported") Reported-by:
Perry Yuan <perry.yuan@amd.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Mario Limonciello authored
[ Upstream commit 7feec743 ] Previously the kernel used to ignore whether the firmware masked CPPC or CPPCv2 and would just pretend that it worked. When support for the USB4 bit in _OSC was introduced from commit 9e1f561afb ("ACPI: Execute platform _OSC also with query bit clear") the kernel began to look at the return when the query bit was clear. This caused regressions that were misdiagnosed and attempted to be solved as part of commit 2ca8e628 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag""). This caused a different regression where non-Intel systems weren't able to negotiate _OSC properly. This was reverted in commit 2ca8e628 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"") and attempted to be fixed by commit c42fa24b ("ACPI: bus: Avoid using CPPC if not supported by firmware") but the regression still returned. These systems with the regression only load support for CPPC from an SSDT dynamically when _OSC reports CPPC v2. Avoid the problem by not letting CPPC satisfy the requirement in `acpi_cppc_processor_probe`. Reported-by:
CUI Hao <cuihao.leo@gmail.com> Reported-by: maxim.novozhilov@gmail.com Reported-by: lethe.tree@protonmail.com Reported-by: garystephenwright@gmail.com Reported-by: galaxyking0419@gmail.com Fixes: c42fa24b ("ACPI: bus: Avoid using CPPC if not supported by firmware") Fixes: 2ca8e628 ("Revert "ACPI Pass the same capabilities to the _OSC regardless of the query flag"") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213023 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2075387 Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by:
-
Pierre Gondois authored
[ Upstream commit 72f2ecb7 ] The _OSC method allows the OS and firmware to communicate about supported features/capabitlities. It also allows the OS to take control of some features. In ACPI 6.4, s6.2.11.2 Platform-Wide OSPM Capabilities, the CPPC (resp. v2) bit should be set by the OS if it 'supports controlling processor performance via the interfaces described in the _CPC object'. The OS supports CPPC and parses the _CPC object only if CONFIG_ACPI_CPPC_LIB is set. Replace the x86 specific boot_cpu_has(X86_FEATURE_HWP) dynamic check with an arch generic CONFIG_ACPI_CPPC_LIB build-time check. Note: CONFIG_X86_INTEL_PSTATE selects CONFIG_ACPI_CPPC_LIB. Signed-off-by:
Pierre Gondois <pierre.gondois@arm.com> Reviewed-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Pierre Gondois authored
[ Upstream commit 0651ab90 ] ACPI 6.2 Section 6.2.11.2 'Platform-Wide OSPM Capabilities': Starting with ACPI Specification 6.2, all _CPC registers can be in PCC, System Memory, System IO, or Functional Fixed Hardware address spaces. OSPM support for this more flexible register space scheme is indicated by the “Flexible Address Space for CPPC Registers” _OSC bit Otherwise (cf ACPI 6.1, s8.4.7.1.1.X), _CPC registers must be in: - PCC or Functional Fixed Hardware address space if defined - SystemMemory address space (NULL register) if not defined Add the corresponding _OSC bit and check it when parsing _CPC objects. Signed-off-by:
-
Vladimir Oltean authored
[ Upstream commit 83844aac ] When packets are not received, they aren't received on $host1_if, so the message talking about the second host not receiving them is incorrect. Fix it. Fixes: d4deb014 ("selftests: forwarding: Add a test for FDB learning") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
-
Vladimir Oltean authored
[ Upstream commit 1a635d3e ] The first host interface has by default no interest in receiving packets MAC DA de:ad:be:ef:13:37, so it might drop them before they hit the tc filter and this might confuse the selftest. Enable promiscuous mode such that the filter properly counts received packets. Fixes: d4deb014 ("selftests: forwarding: Add a test for FDB learning") Signed-off-by:
-
Vladimir Oltean authored
[ Upstream commit b8e629b0 ] As mentioned in the blamed commit, flood_unicast_test() works by checking the match count on a tc filter placed on the receiving interface. But the second host interface (host2_if) has no interest in receiving a packet with MAC DA de:ad:be:ef:13:37, so its RX filter drops it even before the ingress tc filter gets to be executed. So we will incorrectly get the message "Packet was not flooded when should", when in fact, the packet was flooded as expected but dropped due to an unrelated reason, at some other layer on the receiving side. Force h2 to accept this packet by temporarily placing it in promiscuous mode. Alternatively we could either deliver to its MAC address or use tcpdump_start, but this has the fewest complications. This fixes the "flooding" test from bridge_vlan_aware.sh and bridge_vlan_unaware.sh, which calls flood_test from the lib. Fixes: 236dd50b ("selftests: forwarding: Add a test for flooded traffic") Signed-off-by:
-
Rick Lindsley authored
[ Upstream commit 1b18f09d ] During a reset, there may have been transmits in flight that are no longer valid and cannot be fulfilled. Resetting and clearing the queues is insufficient; each skb also needs to be explicitly freed so that upper levels are not left waiting for confirmation of a transmit that will never happen. If this happens frequently enough, the apparent backlog will cause TCP to begin "congestion control" unnecessarily, culminating in permanently decreased throughput. Fixes: d7c0ef36 ("ibmvnic: Free and re-allocate scrqs when tx/rx scrqs change") Tested-by:
Nick Child <nnac123@linux.ibm.com> Reviewed-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Rick Lindsley <ricklind@us.ibm.com> Signed-off-by:
-
Fabrice Gasnier authored
[ Upstream commit 1d0c1aad ] The USBH composed of EHCI and OHCI controllers needs the PHY clock to be initialized first, before enabling (gating) them. The reverse is also required when going to suspend. So, add USBPHY clock as 1st entry in both controllers, so the USBPHY PLL gets enabled 1st upon controller init. Upon suspend/resume, this also makes the clock to be disabled/re-enabled in the correct order. This fixes some IRQ storm conditions seen when going to low-power, due to PHY PLL being disabled before all clocks are cleanly gated. Fixes: 949a0c0d ("ARM: dts: stm32: add USB Host (USBH) support to stm32mp157c") Fixes: db7be2cb ("ARM: dts: stm32: use usbphyc ck_usbo_48m as USBH OHCI clock on stm32mp151") Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by:
Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by:
-
Norbert Zulinski authored
[ Upstream commit fed0d9f1 ] Clear VF MAC from parent PF and remove VF filter from VSI when both conditions are true: -VIRTCHNL_VF_OFFLOAD_USO is not used -VM MAC was not set from PF level It affects older version of IAVF and it allow them to change MAC Address on VM, newer IAVF won't change their behaviour. Previously it wasn't possible to change VF's MAC Address on VM because there is flag on IAVF driver that won't allow to change MAC Address if this address is given from PF driver. Fixes: 155f0ac2 ("iavf: allow permanent MAC address to change") Signed-off-by:
Norbert Zulinski <norbertx.zulinski@intel.com> Signed-off-by:
Jan Sokolowski <jan.sokolowski@intel.com> Tested-by:
Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by:
-
Lukasz Cieplicki authored
[ Upstream commit 1adb1563 ] Dropped packets caused by too large frames were not included in dropped RX packets statistics. Issue was caused by not reading the GL_RXERR1 register. That register stores count of packet which was have been dropped due to too large size. Fix it by reading GL_RXERR1 register for each interface. Repro steps: Send a packet larger than the set MTU to SUT Observe rx statists: ethtool -S <interface> | grep rx | grep -v ": 0" Fixes: 41a9e55c ("i40e: add missing VSI statistics") Signed-off-by:
Lukasz Cieplicki <lukaszx.cieplicki@intel.com> Signed-off-by:
Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by:
-
Jean Delvare authored
[ Upstream commit 8ad59b39 ] The recently added support for EFCH MMIO regions introduced a memory leak in that code path. The leak is caused by the fact that release_resource() merely removes the resource from the tree but does not free its memory. We need to call release_mem_region() instead, which does free the memory. As a nice side effect, this brings back some symmetry between the legacy and MMIO paths. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Reported-by:
Yi Zhang <yi.zhang@redhat.com> Tested-by:
Terry Bowman <terry.bowman@amd.com> Tested-by:
-
Ivan Malov authored
[ Upstream commit 512d1999 ] When a XSK pool gets mapped, xp_check_dma_contiguity() adds bit 0x1 to pages' DMA addresses that go in ascending order and at 4K stride. The problem is that the bit does not get cleared before doing unmap. As a result, a lot of warnings from iommu_dma_unmap_page() are seen in dmesg, which indicates that lookups by iommu_iova_to_phys() fail. Fixes: 2b43470a ("xsk: Introduce AF_XDP buffer allocation API") Signed-off-by:
Ivan Malov <ivan.malov@oktetlabs.ru> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Magnus Karlsson <magnus.karlsson@intel.com> Link: https://lore.kernel.org/bpf/20220628091848.534803-1-ivan.malov@oktetlabs.ru Signed-off-by:
-
Mihai Sain authored
[ Upstream commit 35074df6 ] Fix SoC detection for SAM9X60 SiPs: SAM9X60D5M SAM9X60D1G SAM9X60D6K Fixes: af3a1051 ("drivers: soc: atmel: add per soc id and version match masks") Signed-off-by:
Mihai Sain <mihai.sain@microchip.com> Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20220616081344.1978664-1-claudiu.beznea@microchip.com Signed-off-by:
-
Eugen Hristev authored
[ Upstream commit 416ce193 ] The eeprom memories on the board are microchip 24aa025e48, which are 2 Kbits and are compatible with at24c02 not at24c32. Fixes: 68a95ef7 ("ARM: dts: at91: sama5d2-icp: add SAMA5D2-ICP") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by:
-
