aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-27s390: reintroduce expoline dependence to scriptsJiri Slaby (SUSE)1-1/+1
Expolines depend on scripts/basic/fixdep. And build of expolines can now race with the fixdep build: make[1]: *** Deleting file 'arch/s390/lib/expoline/expoline.o' /bin/sh: line 1: scripts/basic/fixdep: Permission denied make[1]: *** [../scripts/Makefile.build:385: arch/s390/lib/expoline/expoline.o] Error 126 make: *** [../arch/s390/Makefile:166: expoline_prepare] Error 2 The dependence was removed in the below Fixes: commit. So reintroduce the dependence on scripts. Fixes: a0b0987a7811 ("s390/nospec: remove unneeded header includes") Cc: Joe Lawrence <[email protected]> Cc: [email protected] Cc: Heiko Carstens <[email protected]> Cc: Vasily Gorbik <[email protected]> Cc: Alexander Gordeev <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: [email protected] Signed-off-by: Jiri Slaby (SUSE) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vasily Gorbik <[email protected]>
2023-03-27s390/vfio-ap: fix memory leak in vfio_ap device driverTony Krowiak1-1/+2
The device release callback function invoked to release the matrix device uses the dev_get_drvdata(device *dev) function to retrieve the pointer to the vfio_matrix_dev object in order to free its storage. The problem is, this object is not stored as drvdata with the device; since the kfree function will accept a NULL pointer, the memory for the vfio_matrix_dev object is never freed. Since the device being released is contained within the vfio_matrix_dev object, the container_of macro will be used to retrieve its pointer. Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver") Signed-off-by: Tony Krowiak <[email protected]> Reviewed-by: Harald Freudenberger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-03-27s390/uaccess: add missing earlyclobber annotations to __clear_user()Heiko Carstens1-1/+1
Add missing earlyclobber annotation to size, to, and tmp2 operands of the __clear_user() inline assembly since they are modified or written to before the last usage of all input operands. This can lead to incorrect register allocation for the inline assembly. Fixes: 6c2a9e6df604 ("[S390] Use alternative user-copy operations for new hardware.") Reported-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Reviewed-by: Gerald Schaefer <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-03-27Merge tag 'kvm-riscv-fixes-6.3-1' of https://github.com/kvm-riscv/linux into ↵Paolo Bonzini1-4/+2
HEAD KVM/riscv fixes for 6.3, take #1 - Fix VM hang in case of timer delta being zero
2023-03-27Merge tag 'kvmarm-fixes-6.3-2' of ↵Paolo Bonzini3-38/+85
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.3, part #2 Fixes for a rather interesting set of bugs relating to the MMU: - Read the MMU notifier seq before dropping the mmap lock to guard against reading a potentially stale VMA - Disable interrupts when walking user page tables to protect against the page table being freed - Read the MTE permissions for the VMA within the mmap lock critical section, avoiding the use of a potentally stale VMA pointer Additionally, some fixes targeting the vPMU: - Return the sum of the current perf event value and PMC snapshot for reads from userspace - Don't save the value of guest writes to PMCR_EL0.{C,P}, which could otherwise lead to userspace erroneously resetting the vPMU during VM save/restore
2023-03-27platform/x86: gigabyte-wmi: add support for B650 AORUS ELITE AXThomas Weißschuh1-0/+1
This has been reported as working. Suggested-by: got3nks <[email protected]> Link: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/15#issuecomment-1483942966 Signed-off-by: Thomas Weißschuh <[email protected]> Link: https://lore.kernel.org/r/20230327-gigabyte-wmi-b650-elite-ax-v1-1-d4d645c21d0b@weissschuh.net Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-03-27can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_writeIvan Orlov1-6/+10
Syzkaller reported the following issue: ===================================================== BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline] BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600 aio_rw_done fs/aio.c:1520 [inline] aio_write+0x899/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc+0x11d/0x3b0 mm/slab_common.c:981 kmalloc_array include/linux/slab.h:636 [inline] bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930 bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] sock_write_iter+0x495/0x5e0 net/socket.c:1108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 ===================================================== We can follow the call chain and find that 'bcm_tx_setup' function calls 'memcpy_from_msg' to copy some content to the newly allocated frame of 'op->frames'. After that the 'len' field of copied structure being compared with some constant value (64 or 8). However, if 'memcpy_from_msg' returns an error, we will compare some uninitialized memory. This triggers 'uninit-value' issue. This patch will add 'memcpy_from_msg' possible errors processing to avoid uninit-value issue. Tested via syzkaller Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?id=47f897f8ad958bbde5790ebf389b5e7e0a345089 Signed-off-by: Ivan Orlov <[email protected]> Fixes: 6f3b911d5f29b ("can: bcm: add support for CAN FD frames") Acked-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-03-27platform/x86/intel/pmc: Alder Lake PCH slp_s0_residency fixRajvi Jingar1-1/+12
For platforms with Alder Lake PCH (Alder Lake S and Raptor Lake S) the slp_s0_residency attribute has been reporting the wrong value. Unlike other platforms, ADL PCH does not have a counter for the time that the SLP_S0 signal was asserted. Instead, firmware uses the aggregate of the Low Power Mode (LPM) substate counters as the S0ix value. Since the LPM counters run at a different frequency, this lead to misreporting of the S0ix time. Add a check for Alder Lake PCH and adjust the frequency accordingly when display slp_s0_residency. Fixes: bbab31101f44 ("platform/x86/intel: pmc/core: Add Alderlake support to pmc core driver") Signed-off-by: Rajvi Jingar <[email protected]> Signed-off-by: David E. Box <[email protected]> Reviewed-by: Rajneesh Bhardwaj <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-03-27drm/i915/perf: Drop wakeref on GuC RC errorChris Wilson2-5/+15
If we fail to adjust the GuC run-control on opening the perf stream, make sure we unwind the wakeref just taken. v2: Retain old goto label names (Ashutosh) v3: Drop bitfield boolean Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2810ac6c753d17ee2572ffb57fe2382a786a080a) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/dpt: Treat the DPT BO as a framebufferVille Syrjälä3-1/+6
Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... Cc: [email protected] Cc: Juha-Pekka Heikkila <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Imre Deak <[email protected]> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]> (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/gem: Flush lmem contents after constructionChris Wilson1-1/+2
i915_gem_object_create_lmem_from_data() lacks the flush of the data written to lmem to ensure the object is marked as dirty and the writes flushed to the backing store. Once created, we can immediately release the obj->mm.mapping caching of the vmap. Fixes: 7acbbc7cf485 ("drm/i915/guc: put all guc objects in lmem when available") Cc: Matthew Auld <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Matthew Brost <[email protected]> Cc: John Harrison <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: <[email protected]> # v5.16+ Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e2ee10474ce766686e7a7496585cdfaf79e3a1bf) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/tc: Fix the ICL PHY ownership check in TC-cold stateImre Deak1-2/+2
The commit renaming icl_tc_phy_is_in_safe_mode() to icl_tc_phy_take_ownership() didn't flip the function's return value accordingly, fix this up. This didn't cause an actual problem besides state check errors, since the function is only used during HW readout. Cc: José Roberto de Souza <[email protected]> Fixes: f53979d68a77 ("drm/i915/display/tc: Rename safe_mode functions ownership") Reviewed-by: José Roberto de Souza <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f2c7959dda614d9b7c6a41510492de39d31705ec) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Disable DC states for all commitsVille Syrjälä1-3/+25
Keeping DC states enabled is incompatible with the _noarm()/_arm() split we use for writing pipe/plane registers. When DC5 and PSR are enabled, all pipe/plane registers effectively become self-arming on account of DC5 exit arming the update, and PSR exit latching it. What probably saves us most of the time is that (with PIPE_MISC[21]=0) all pipe register writes themselves trigger PSR exit, and then we don't re-enter PSR until the idle frame count has elapsed. So it may be that the PSR exit happens already before we've updated the state too much. Also the PSR1 panel (at least on this KBL) seems to discard the first frame we trasmit, presumably still scanning out from its internal framebuffer at that point. So only the second frame we transmit is actually visible. But I suppose that could also be panel specific behaviour. I haven't checked out how other PSR panels behave, nor did I bother to check what the eDP spec has to say about this. And since this really is all about DC states, let's switch from the MODESET domain to the DC_OFF domain. Functionally they are 100% identical. We should probably remove the MODESET domain... And for good measure let's toss in an assert to the place where we do the _noarm() register writes to make sure DC states are in fact off. v2: Just use intel_display_power_is_enabled() (Imre) Cc: <[email protected]> #v5.17+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Jouni Högander <[email protected]> Reviewed-by: Imre Deak <[email protected]> Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Fixes: f8a005eb8972 ("drm/i915: Optimize icl+ universal plane programming") Fixes: 890b6ec4a522 ("drm/i915: Split skl+ plane update into noarm+arm pair") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 41b4c7fe72b6105a4b49395eea9aa40cef94288d) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Workaround ICL CSC_MODE sticky armingVille Syrjälä1-1/+43
Unlike SKL/GLK the ICL CSC unit suffers from a new issue where CSC_MODE arming is sticky. That is, once armed it remains armed causing the CSC coeff/offset registers to become effectively self-arming. CSC coeff/offset registers writes no longer disarm the CSC, but fortunately register read still do. So we can use that to disarm the CSC unit once the registers for the current frame have been latched. This avoid s the self-arming behaviour from persisting into the next frame's .color_commit_noarm() call. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 92736f1b452bbb8a66bdb5b1d263ad00e04dd3b8) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Add a .color_post_update() hookVille Syrjälä3-0/+17
We're going to need stuff after the color management register latching has happened. Add a corresponding hook. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 3962ca4e080a525fc9eae87aa6b2286f1fae351d) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Move CSC load back into .color_commit_arm() when PSR is enabled on ↵Ville Syrjälä1-2/+21
skl/glk SKL/GLK CSC unit suffers from a nasty issue where a CSC coeff/offset register read or write between DC5 exit and PSR exit will undo the CSC arming performed by DMC, and then during PSR exit the hardware will latch zeroes into the active CSC registers. This causes any plane going through the CSC to output all black. We can sidestep the issue by making sure the PSR exit has already actually happened before we touch the CSC coeff/offset registers. Easiest way to guarantee that is to just move the CSC programming back into the .color_commir_arm() as we force a PSR exit (and crucially wait for it to actually happen) prior to touching the arming registers. When PSR (and thus also DC states) are disabled we don't have anything to worry about, so we can keep using the more optional _noarm() hook for writing the CSC registers. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8283 Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 80a892a4c2428b65366721599fc5fe50eaed35fd) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Split icl_color_commit_noarm() from skl_color_commit_noarm()Ville Syrjälä1-1/+20
We're going to want different behavior for skl/glk vs. icl in .color_commit_noarm(), so split the hook into two. Arguably we already had slightly different behaviour since csc_enable/gamma_enable are never set on icl+, so the old code was perhaps a bit confusing as well. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit f161eb01f50ab31f2084975b43bce54b7b671e17) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/pmu: Use functions common with sysfs to read actual freqAshutosh Dixit3-26/+26
Expose intel_rps_read_actual_frequency_fw to read the actual freq without taking forcewake for use by PMU. The code is refactored to use a common set of functions across sysfs and PMU. Using common functions with sysfs in PMU solves the issues of missing support for MTL and missing support for older generations (prior to Gen6). It also future proofs the PMU where sometimes code has been updated for sysfs and PMU has been missed. v2: Remove runtime_pm_if_in_use from read_actual_frequency_fw (Tvrtko) v3: (Tvrtko) - Remove goto in __read_cagf - Unexport intel_rps_get_cagf and intel_rps_read_punit_req Fixes: 22009b6dad66 ("drm/i915/mtl: Modify CAGF functions for MTL") Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8280 Signed-off-by: Ashutosh Dixit <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 44df42e66139b5fac8db49ee354be279210f9816) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27net: stmmac: don't reject VLANs when IFF_PROMISC is setVladimir Oltean2-59/+3
The blamed commit has introduced the following tests to dwmac4_add_hw_vlan_rx_fltr(), called from stmmac_vlan_rx_add_vid(): if (hw->promisc) { netdev_err(dev, "Adding VLAN in promisc mode not supported\n"); return -EPERM; } "VLAN promiscuous" mode is keyed in this driver to IFF_PROMISC, and so, vlan_vid_add() and vlan_vid_del() calls cannot take place in IFF_PROMISC mode. I have the following 2 arguments that this restriction is.... hm, how shall I put it nicely... unproductive :) First, take the case of a Linux bridge. If the kernel is compiled with CONFIG_BRIDGE_VLAN_FILTERING=y, then this bridge shall have a VLAN database. The bridge shall try to call vlan_add_vid() on its bridge ports for each VLAN in the VLAN table. It will do this irrespectively of whether that port is *currently* VLAN-aware or not. So it will do this even when the bridge was created with vlan_filtering 0. But the Linux bridge, in VLAN-unaware mode, configures its ports in promiscuous (IFF_PROMISC) mode, so that they accept packets with any MAC DA (a switch must do this in order to forward those packets which are not directly targeted to its MAC address). As a result, the stmmac driver does not work as a bridge port, when the kernel is compiled with CONFIG_BRIDGE_VLAN_FILTERING=y. $ ip link add br0 type bridge && ip link set br0 up $ ip link set eth0 master br0 && ip link set eth0 up [ 2333.943296] br0: port 1(eth0) entered blocking state [ 2333.943381] br0: port 1(eth0) entered disabled state [ 2333.943782] device eth0 entered promiscuous mode [ 2333.944080] 4033c000.ethernet eth0: Adding VLAN in promisc mode not supported [ 2333.976509] 4033c000.ethernet eth0: failed to initialize vlan filtering on this port RTNETLINK answers: Operation not permitted Secondly, take the case of stmmac as DSA master. Some switch tagging protocols are based on 802.1Q VLANs (tag_sja1105.c), and as such, tag_8021q.c uses vlan_vid_add() to work with VLAN-filtering DSA masters. But also, when a DSA port becomes promiscuous (for example when it joins a bridge), the DSA framework also makes the DSA master promiscuous. Moreover, for every VLAN that a DSA switch sends to the CPU, DSA also programs a VLAN filter on the DSA master, because if the the DSA switch uses a tail tag, then the hardware frame parser of the DSA master will see VLAN as VLAN, and might filter them out, for being unknown. Due to the above 2 reasons, my belief is that the stmmac driver does not get to choose to not accept vlan_vid_add() calls while IFF_PROMISC is enabled, because the 2 are completely independent and there are code paths in the network stack which directly lead to this situation occurring, without the user's direct input. In fact, my belief is that "VLAN promiscuous" mode should have never been keyed on IFF_PROMISC in the first place, but rather, on the NETIF_F_HW_VLAN_CTAG_FILTER feature flag which can be toggled by the user through ethtool -k, when present in netdev->hw_features. In the stmmac driver, NETIF_F_HW_VLAN_CTAG_FILTER is only present in "features", making this feature "on [fixed]". I have this belief because I am unaware of any definition of promiscuity which implies having an effect on anything other than MAC DA (therefore not VLAN). However, I seem to be rather alone in having this opinion, looking back at the disagreements from this discussion: https://lore.kernel.org/netdev/[email protected]/ In any case, to remove the vlan_vid_add() dependency on !IFF_PROMISC, one would need to remove the check and see what fails. I guess the test was there because of the way in which dwmac4_vlan_promisc_enable() is implemented. For context, the dwmac4 supports Perfect Filtering for a limited number of VLANs - dwmac4_get_num_vlan(), priv->hw->num_vlan, with a fallback on Hash Filtering - priv->dma_cap.vlhash - see stmmac_vlan_update(), also visible in cat /sys/kernel/debug/stmmaceth/eth0/dma_cap | grep 'VLAN Hash Filtering'. The perfect filtering is based on MAC_VLAN_Tag_Filter/MAC_VLAN_Tag_Data registers, accessed in the driver through dwmac4_write_vlan_filter(). The hash filtering is based on the MAC_VLAN_Hash_Table register, named GMAC_VLAN_HASH_TABLE in the driver and accessed by dwmac4_update_vlan_hash(). The control bit for enabling hash filtering is GMAC_VLAN_VTHM (MAC_VLAN_Tag_Ctrl bit VTHM: VLAN Tag Hash Table Match Enable). Now, the description of dwmac4_vlan_promisc_enable() is that it iterates through the driver's cache of perfect filter entries (hw->vlan_filter[i], added by dwmac4_add_hw_vlan_rx_fltr()), and evicts them from hardware by unsetting their GMAC_VLAN_TAG_DATA_VEN (MAC_VLAN_Tag_Data bit VEN - VLAN Tag Enable) bit. Then it unsets the GMAC_VLAN_VTHM bit, which disables hash matching. This leaves the MAC, according to table "VLAN Match Status" from the documentation, to always enter these data paths: VID |VLAN Perfect Filter |VTHM Bit |VLAN Hash Filter |Final VLAN Match |Match Result | |Match Result |Status -------|--------------------|---------|-----------------|---------------- VID!=0 |Fail |0 |don't care |Pass So, dwmac4_vlan_promisc_enable() does its job, but by unsetting GMAC_VLAN_VTHM, it conflicts with the other code path which controls this bit: dwmac4_update_vlan_hash(), called through stmmac_update_vlan_hash() from stmmac_vlan_rx_add_vid() and from stmmac_vlan_rx_kill_vid(). This is, I guess, why dwmac4_add_hw_vlan_rx_fltr() is not allowed to run after dwmac4_vlan_promisc_enable() has unset GMAC_VLAN_VTHM: because if it did, then dwmac4_update_vlan_hash() would set GMAC_VLAN_VTHM again, breaking the "VLAN promiscuity". It turns out that dwmac4_vlan_promisc_enable() is way too complicated for what needs to be done. The MAC_Packet_Filter register also has the VTFE bit (VLAN Tag Filter Enable), which simply controls whether VLAN tagged packets which don't match the filtering tables (either perfect or hash) are dropped or not. At the moment, this driver unconditionally sets GMAC_PACKET_FILTER_VTFE if NETIF_F_HW_VLAN_CTAG_FILTER was detected through the priv->dma_cap.vlhash capability bits of the device, in stmmac_dvr_probe(). I would suggest deleting the unnecessarily complex logic from dwmac4_vlan_promisc_enable(), and simply unsetting GMAC_PACKET_FILTER_VTFE when becoming IFF_PROMISC, which has the same effect of allowing packets with any VLAN tags, but has the additional benefit of being able to run concurrently with stmmac_vlan_rx_add_vid() and stmmac_vlan_rx_kill_vid(). As much as I believe that the VTFE bit should have been exclusively controlled by NETIF_F_HW_VLAN_CTAG_FILTER through ethtool, and not by IFF_PROMISC, changing that is not a punctual fix to the problem, and it would probably break the VFFQ feature added by the later commit e0f9956a3862 ("net: stmmac: Add option for VLAN filter fail queue enable"). From the commit description, VFFQ needs IFF_PROMISC=on and VTFE=off in order to work (and this change respects that). But if VTFE was changed to be controlled through ethtool -k, then a user-visible change would have been introduced in Intel's scripts (a need to run "ethtool -k eth0 rx-vlan-filter off" which did not exist before). The patch was tested with this set of commands: ip link set eth0 up ip link add link eth0 name eth0.100 type vlan id 100 ip addr add 192.168.100.2/24 dev eth0.100 && ip link set eth0.100 up ip link set eth0 promisc on ip link add link eth0 name eth0.101 type vlan id 101 ip addr add 192.168.101.2/24 dev eth0.101 && ip link set eth0.101 up ip link set eth0 promisc off ping -c 5 192.168.100.1 ping -c 5 192.168.101.1 ip link set eth0 promisc on ping -c 5 192.168.100.1 ping -c 5 192.168.101.1 ip link del eth0.100 ip link del eth0.101 # Wait for VLAN-tagged pings from the other end... # Check with "tcpdump -i eth0 -e -n -p" and we should see them ip link set eth0 promisc off # Wait for VLAN-tagged pings from the other end... # Check with "tcpdump -i eth0 -e -n -p" and we shouldn't see them # anymore, but remove the "-p" argument from tcpdump and they're there. Fixes: c89f44ff10fd ("net: stmmac: Add support for VLAN promiscuous mode") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27can: j1939: prevent deadlock by moving j1939_sk_errqueue()Oleksij Rempel1-2/+6
This commit addresses a deadlock situation that can occur in certain scenarios, such as when running data TP/ETP transfer and subscribing to the error queue while receiving a net down event. The deadlock involves locks in the following order: 3 j1939_session_list_lock -> active_session_list_lock j1939_session_activate ... j1939_sk_queue_activate_next -> sk_session_queue_lock ... j1939_xtp_rx_eoma_one 2 j1939_sk_queue_drop_all -> sk_session_queue_lock ... j1939_sk_netdev_event_netdown -> j1939_socks_lock j1939_netdev_notify 1 j1939_sk_errqueue -> j1939_socks_lock __j1939_session_cancel -> active_session_list_lock j1939_tp_rxtimer CPU0 CPU1 ---- ---- lock(&priv->active_session_list_lock); lock(&jsk->sk_session_queue_lock); lock(&priv->active_session_list_lock); lock(&priv->j1939_socks_lock); The solution implemented in this commit is to move the j1939_sk_errqueue() call out of the active_session_list_lock context, thus preventing the deadlock situation. Reported-by: [email protected] Fixes: 5b9272e93f2e ("can: j1939: extend UAPI to notify about RX status") Co-developed-by: Hillf Danton <[email protected]> Signed-off-by: Hillf Danton <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-03-27net: dsa: b53: mmap: add phy opsÁlvaro Fernández Rojas1-0/+14
Implement phy_read16() and phy_write16() ops for B53 MMAP to avoid accessing B53_PORT_MII_PAGE registers which hangs the device. This access should be done through the MDIO Mux bus controller. Signed-off-by: Álvaro Fernández Rojas <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27net: phy: micrel: correct KSZ9131RNX EEE capabilities and advertisementOleksij Rempel1-0/+1
The KSZ9131RNX incorrectly shows EEE capabilities in its registers. Although the "EEE control and capability 1" (Register 3.20) is set to 0, indicating no EEE support, the "EEE advertisement 1" (Register 7.60) is set to 0x6, advertising EEE support for 1000BaseT/Full and 100BaseT/Full. This inconsistency causes PHYlib to assume there is no EEE support, preventing control over EEE advertisement, which is enabled by default. This patch resolves the issue by utilizing the ksz9477_get_features() function to correctly set the EEE capabilities for the KSZ9131RNX. This adjustment allows proper control over EEE advertisement and ensures accurate representation of the device's capabilities. Fixes: 8b68710a3121 ("net: phy: start using genphy_c45_ethtool_get/set_eee()") Reported-by: Marek Vasut <[email protected]> Tested-by: Marek Vasut <[email protected]> Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27vsock/loopback: use only sk_buff_head.lock to protect the packet queueStefano Garzarella1-8/+2
pkt_list_lock was used before commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") to protect the packet queue. After that commit we switched to sk_buff and we are using sk_buff_head.lock in almost every place to protect the packet queue except in vsock_loopback_work() when we call skb_queue_splice_init(). As reported by syzbot, this caused unlocked concurrent access to the packet queue between vsock_loopback_work() and vsock_loopback_cancel_pkt() since it is not holding pkt_list_lock. With the introduction of sk_buff_head, pkt_list_lock is redundant and can cause confusion, so let's remove it and use sk_buff_head.lock everywhere to protect the packet queue access. Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Cc: [email protected] Reported-and-tested-by: [email protected] Signed-off-by: Stefano Garzarella <[email protected]> Reviewed-by: Bobby Eshleman <[email protected]> Reviewed-by: Arseniy Krasnov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27Merge branch 'constify-sfp-phy-nodes'David S. Miller4-7/+8
Russell King says: ==================== Constify a few sfp/phy fwnodes This series constifies a bunch of fwnode_handle pointers that are only used to refer to but not modify the contents of the fwnode structures. ==================== Signed-off-by: David S. Miller <[email protected]>
2023-03-27net: phy: constify fwnode_get_phy_node() fwnode argumentRussell King (Oracle)2-2/+2
fwnode_get_phy_node() does not motify the fwnode structure, so make the argument const, Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27net: sfp: constify sfp-bus internal fwnode usesRussell King (Oracle)1-2/+2
Constify sfp-bus internal fwnode uses, since we do not modify the fwnode structures. Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27net: sfp: make sfp_bus_find_fwnode() take a const fwnodeRussell King (Oracle)2-3/+4
sfp_bus_find_fwnode() does not write to the fwnode, so let's make it const. Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27net/net_failover: fix txq exceeding warningFaicker Mo1-6/+2
The failover txq is inited as 16 queues. when a packet is transmitted from the failover device firstly, the failover device will select the queue which is returned from the primary device if the primary device is UP and running. If the primary device txq is bigger than the default 16, it can lead to the following warning: eth0 selects TX queue 18, but real number of TX queues is 16 The warning backtrace is: [ 32.146376] CPU: 18 PID: 9134 Comm: chronyd Tainted: G E 6.2.8-1.el7.centos.x86_64 #1 [ 32.147175] Hardware name: Red Hat KVM, BIOS 1.10.2-3.el7_4.1 04/01/2014 [ 32.147730] Call Trace: [ 32.147971] <TASK> [ 32.148183] dump_stack_lvl+0x48/0x70 [ 32.148514] dump_stack+0x10/0x20 [ 32.148820] netdev_core_pick_tx+0xb1/0xe0 [ 32.149180] __dev_queue_xmit+0x529/0xcf0 [ 32.149533] ? __check_object_size.part.0+0x21c/0x2c0 [ 32.149967] ip_finish_output2+0x278/0x560 [ 32.150327] __ip_finish_output+0x1fe/0x2f0 [ 32.150690] ip_finish_output+0x2a/0xd0 [ 32.151032] ip_output+0x7a/0x110 [ 32.151337] ? __pfx_ip_finish_output+0x10/0x10 [ 32.151733] ip_local_out+0x5e/0x70 [ 32.152054] ip_send_skb+0x19/0x50 [ 32.152366] udp_send_skb.isra.0+0x163/0x3a0 [ 32.152736] udp_sendmsg+0xba8/0xec0 [ 32.153060] ? __folio_memcg_unlock+0x25/0x60 [ 32.153445] ? __pfx_ip_generic_getfrag+0x10/0x10 [ 32.153854] ? sock_has_perm+0x85/0xa0 [ 32.154190] inet_sendmsg+0x6d/0x80 [ 32.154508] ? inet_sendmsg+0x6d/0x80 [ 32.154838] sock_sendmsg+0x62/0x70 [ 32.155152] ____sys_sendmsg+0x134/0x290 [ 32.155499] ___sys_sendmsg+0x81/0xc0 [ 32.155828] ? _get_random_bytes.part.0+0x79/0x1a0 [ 32.156240] ? ip4_datagram_release_cb+0x5f/0x1e0 [ 32.156649] ? get_random_u16+0x69/0xf0 [ 32.156989] ? __fget_light+0xcf/0x110 [ 32.157326] __sys_sendmmsg+0xc4/0x210 [ 32.157657] ? __sys_connect+0xb7/0xe0 [ 32.157995] ? __audit_syscall_entry+0xce/0x140 [ 32.158388] ? syscall_trace_enter.isra.0+0x12c/0x1a0 [ 32.158820] __x64_sys_sendmmsg+0x24/0x30 [ 32.159171] do_syscall_64+0x38/0x90 [ 32.159493] entry_SYSCALL_64_after_hwframe+0x72/0xdc Fix that by reducing txq number as the non-existent primary-dev does. Fixes: cfc80d9a1163 ("net: Introduce net_failover driver") Signed-off-by: Faicker Mo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-27regulator: Handle deferred clkChristophe JAILLET1-1/+1
devm_clk_get() can return -EPROBE_DEFER. So it is better to return the error code from devm_clk_get(), instead of a hard coded -ENOENT. This gives more opportunities to successfully probe the driver. Fixes: 8959e5324485 ("regulator: fixed: add possibility to enable by clock") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/18459fae3d017a66313699c7c8456b28158b2dd0.1679819354.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <[email protected]>
2023-03-26Linux 6.3-rc4Linus Torvalds1-1/+1
2023-03-26Merge tag 'usb-6.3-rc4' of ↵Linus Torvalds31-130/+625
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt driver fixes from Greg KH: "Here are a small set of USB and Thunderbolt driver fixes for reported problems and a documentation update, for 6.3-rc4. Included in here are: - documentation update for uvc gadget driver - small thunderbolt driver fixes - cdns3 driver fixes - dwc3 driver fixes - dwc2 driver fixes - chipidea driver fixes - typec driver fixes - onboard_usb_hub device id updates - quirk updates All of these have been in linux-next with no reported problems" * tag 'usb-6.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (30 commits) usb: dwc2: fix a race, don't power off/on phy for dual-role mode usb: dwc2: fix a devres leak in hw_enable upon suspend resume usb: chipidea: core: fix possible concurrent when switch role usb: chipdea: core: fix return -EINVAL if request role is the same with current role thunderbolt: Rename shadowed variables bit to interrupt_bit and auto_clear_bit thunderbolt: Disable interrupt auto clear for rings thunderbolt: Use const qualifier for `ring_interrupt_index` usb: gadget: Use correct endianness of the wLength field for WebUSB uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2 usb: cdnsp: changes PCI Device ID to fix conflict with CNDS3 driver usb: cdns3: Fix issue with using incorrect PCI device function usb: cdnsp: Fixes issue with redundant Status Stage MAINTAINERS: make me a reviewer of USB/IP thunderbolt: Use scale field when allocating USB3 bandwidth thunderbolt: Limit USB3 bandwidth of certain Intel USB4 host routers thunderbolt: Call tb_check_quirks() after initializing adapters thunderbolt: Add missing UNSET_INBOUND_SBTX for retimer access thunderbolt: Fix memory leak in margining usb: dwc2: drd: fix inconsistent mode if role-switch-default-mode="host" docs: usb: Add documentation for the UVC Gadget ...
2023-03-26Merge tag 'sched_urgent_for_v6.3_rc4' of ↵Linus Torvalds2-11/+47
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Borislav Petkov: - Fix a corner case where vruntime of a task is not being sanitized * tag 'sched_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Sanitize vruntime of entity being migrated
2023-03-26Merge tag 'perf_urgent_for_v6.3_rc4' of ↵Linus Torvalds1-2/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fix from Borislav Petkov: - Properly clear perf event status tracking in the AMD perf event overflow handler * tag 'perf_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/amd/core: Always clear status for idx
2023-03-26Merge tag 'core_urgent_for_v6.3_rc4' of ↵Linus Torvalds3-2/+6
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull core fixes from Borislav Petkov: - Do the delayed RCU wakeup for kthreads in the proper order so that former doesn't get ignored - A noinstr warning fix * tag 'core_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry/rcu: Check TIF_RESCHED _after_ delayed RCU wake-up entry: Fix noinstr warning in __enter_from_user_mode()
2023-03-26Merge tag 'x86_urgent_for_v6.3_rc4' of ↵Linus Torvalds3-19/+126
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Add a AMX ptrace self test - Prevent a false-positive warning when retrieving the (invalid) address of dynamic FPU features in their init state which are not saved in init_fpstate at all - Randomize per-CPU entry areas only when KASLR is enabled * tag 'x86_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: selftests/x86/amx: Add a ptrace test x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf() x86/mm: Do not shuffle CPU entry areas without KASLR
2023-03-26Merge tag 'smb3-client-fixes-6.3-rc3' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds15-92/+221
Pull cifs client fixes from Steve French: "Twelve cifs/smb3 client fixes (most also for stable) - forced umount fix - fix for two perf regressions - reconnect fixes - small debugging improvements - multichannel fixes" * tag 'smb3-client-fixes-6.3-rc3' of git://git.samba.org/sfrench/cifs-2.6: smb3: fix unusable share after force unmount failure cifs: fix dentry lookups in directory handle cache smb3: lower default deferred close timeout to address perf regression cifs: fix missing unload_nls() in smb2_reconnect() cifs: avoid race conditions with parallel reconnects cifs: append path to open_enter trace event cifs: print session id while listing open files cifs: dump pending mids for all channels in DebugData cifs: empty interface list when server doesn't support query interfaces cifs: do not poll server interfaces too regularly cifs: lock chan_lock outside match_session cifs: check only tcon status on tcon related functions
2023-03-25Merge tag 'nfsd-6.3-4' of ↵Linus Torvalds1-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd fix from Chuck Lever: - Fix a crash when using NFS with krb5p * tag 'nfsd-6.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: SUNRPC: Fix a crash in gss_krb5_checksum()
2023-03-25Merge tag 'xfs-6.3-fixes-7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds2-5/+10
Pull yet more xfs bug fixes from Darrick Wong: "The first bugfix addresses a longstanding problem where we use the wrong file mapping cursors when trying to compute the speculative preallocation quantity. This has been causing sporadic crashes when alwayscow mode is engaged. The other two fixes correct minor problems in more recent changes. - Fix the new allocator tracepoints because git am mismerged the changes such that the trace_XXX got rebased to be in function YYY instead of XXX - Ensure that the perag AGFL_RESET state is consistent with whatever we've just read off the disk - Fix a bug where we used the wrong iext cursor during a write begin" * tag 'xfs-6.3-fixes-7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: fix mismerged tracepoints xfs: clear incore AGFL_RESET state if it's not needed xfs: pass the correct cursor to xfs_iomap_prealloc_size
2023-03-25Merge tag 'xfs-6.3-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds6-34/+77
Pull xfs percpu counter fixes from Darrick Wong: "We discovered a filesystem summary counter corruption problem that was traced to cpu hot-remove racing with the call to percpu_counter_sum that sets the free block count in the superblock when writing it to disk. The root cause is that percpu_counter_sum doesn't cull from dying cpus and hence misses those counter values if the cpu shutdown hooks have not yet run to merge the values. I'm hoping this is a fairly painless fix to the problem, since the dying cpu mask should generally be empty. It's been in for-next for a week without any complaints from the bots. - Fix a race in the percpu counters summation code where the summation failed to add in the values for any CPUs that were dying but not yet dead. This fixes some minor discrepancies and incorrect assertions when running generic/650" * tag 'xfs-6.3-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: pcpcntr: remove percpu_counter_sum_all() fork: remove use of percpu_counter_sum_all pcpcntrs: fix dying cpu summation race cpumask: introduce for_each_cpu_or
2023-03-25Merge tag 'xfs-6.3-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds6-1/+722
Pull xfs fixes from Darrick Wong: "This batch started with some debugging enhancements to the new allocator refactoring that we put in 6.3-rc1 to assist developers in rebasing their dev branches. As for more serious code changes -- there's a bug fix to make the lockless allocator scan the whole filesystem before resorting to the locking allocator. We're also adding a selftest for the venerable directory/xattr hash function to make sure that it produces consistent results so that we can address any fallout as soon as possible. - Add a few debugging assertions so that people (me) trying to port code to the new allocator functions don't mess up the caller requirements - Relax some overly cautious lock ordering enforcement in the new allocator code, which means that file allocations will locklessly scan for the best space they can get before backing off to the traditional lock-and-really-get-it behavior - Add tracepoints to make it easier to trace the xfs allocator behavior - Actually test the dir/xattr hash algorithm to make sure it produces consistent results across all the platforms XFS supports" * tag 'xfs-6.3-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: test dir/attr hash when loading module xfs: add tracepoints for each of the externally visible allocators xfs: walk all AGs if TRYLOCK passed to xfs_alloc_vextent_iterate_ags xfs: try to idiot-proof the allocators
2023-03-25Merge tag 'hwmon-for-v6.3-rc4' of ↵Linus Torvalds4-11/+22
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - it87: Fix voltage scaling for chips with 10.9mV ADCs - xgene: Fix ioremap and memremap leak - peci/cputemp: Fix miscalculated DTS temperature for SKX - hwmon core: fix potential sensor registration failure with thermal subsystem if of_node is missing * tag 'hwmon-for-v6.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon (it87): Fix voltage scaling for chips with 10.9mV ADCs hwmon: (xgene) Fix ioremap and memremap leak hwmon: fix potential sensor registration fail if of_node is missing hwmon: (peci/cputemp) Fix miscalculated DTS for SKX
2023-03-25r8169: fix RTL8168H and RTL8107E rx crc errorChunHao Lin1-0/+3
When link speed is 10 Mbps and temperature is under -20°C, RTL8168H and RTL8107E may have rx crc error. Disable phy 10 Mbps pll off to fix this issue. Fixes: 6e1d0b898818 ("r8169:add support for RTL8168H and RTL8107E") Signed-off-by: ChunHao Lin <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-25Merge branch 'ksz-fixes'David S. Miller3-21/+11
Oleksij Rempel says: ==================== net: dsa: microchip: ksz8: fixes for stable changes v2: - use proper Fixes tag - add Acked-by: Arun Ramadoss <[email protected]> on all reviewed patches except the ksz8863_smi patch. These fixes address issues such as incomplete FDB extraction, incorrect FID extraction and configuration, incorrect timestamp extraction, and ghost entry extraction from an empty dynamic MAC table. These updates ensure proper functioning of the FDB/MDB functionality for the ksz8863/ksz8873 series of chips. ==================== Signed-off-by: David S. Miller <[email protected]>
2023-03-25net: dsa: microchip: ksz8: fix MDB configuration with non-zero VIDOleksij Rempel1-1/+1
FID is directly mapped to VID. However, configuring a MAC address with a VID != 0 resulted in incorrect configuration due to an incorrect bit mask. This kernel commit fixed the issue by correcting the bit mask and ensuring proper configuration of MAC addresses with non-zero VID. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Oleksij Rempel <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-25net: dsa: microchip: ksz8863_smi: fix bulk accessOleksij Rempel1-9/+0
Current regmap bulk access is broken, resulting to wrong reads/writes if ksz_read64/ksz_write64 functions are used. Mostly this issue was visible by using ksz8_fdb_dump(), which returned corrupt MAC address. The reason is that regmap was configured to have max_raw_read/write, even if ksz8863_mdio_read/write functions are able to handle unlimited read/write accesses. On ksz_read64 function we are using multiple 32bit accesses by incrementing each access by 1 instead of 4. Resulting buffer had 01234567.12345678 instead of 01234567.89abcdef. We have multiple ways to fix it: - enable 4 byte alignment for 32bit accesses. Since the HW do not have this requirement. It will break driver. - disable max_raw_* limit. This patch is removing max_raw_* limit for regmap accesses in ksz8863_smi. Fixes: 60a364760002 ("net: dsa: microchip: Add Microchip KSZ8863 SMI based driver support") Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-25net: dsa: microchip: ksz8: ksz8_fdb_dump: avoid extracting ghost entry from ↵Oleksij Rempel1-1/+1
empty dynamic MAC table. If the dynamic MAC table is empty, we will still extract one outdated entry. Fix it by using correct bit offset. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Oleksij Rempel <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-25net: dsa: microchip: ksz8: fix offset for the timestamp filedOleksij Rempel1-1/+1
We are using wrong offset, so we will get not a timestamp. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Oleksij Rempel <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-25net: dsa: microchip: ksz8: fix ksz8_fdb_dump() to extract all 1024 entriesOleksij Rempel1-3/+3
Current ksz8_fdb_dump() is able to extract only max 249 entries on the ksz8863/ksz8873 series of switches. This happened due to wrong bit mask and offset calculation. This commit corrects the issue and allows for the complete extraction of all 1024 entries. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Oleksij Rempel <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-25net: dsa: microchip: ksz8: fix ksz8_fdb_dump()Oleksij Rempel1-6/+5
Before this patch, the ksz8_fdb_dump() function had several issues, such as uninitialized variables and incorrect usage of source port as a bit mask. These problems caused inaccurate reporting of vid information and port assignment in the bridge fdb. Fixes: e587be759e6e ("net: dsa: microchip: update fdb add/del/dump in ksz_common") Signed-off-by: Oleksij Rempel <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-24ptp_qoriq: fix memory leak in probe()SongJingyi1-1/+1
Smatch complains that: drivers/ptp/ptp_qoriq.c ptp_qoriq_probe() warn: 'base' from ioremap() not released. Fix this by revising the parameter from 'ptp_qoriq->base' to 'base'. This is only a bug if ptp_qoriq_init() returns on the first -ENODEV error path. For other error paths ptp_qoriq->base and base are the same. And this change makes the code more readable. Fixes: 7f4399ba405b ("ptp_qoriq: fix NULL access if ptp dt node missing") Signed-off-by: SongJingyi <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Reviewed-by: Dongliang Mu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.