summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-10-20thermal: trip: Simplify computing trip indicesRafael J. Wysocki
A trip index can be computed right away as a difference between the value of a trip pointer pointing to the given trip object and the start of the trips[] table in the given thermal zone, so change thermal_zone_trip_id() accordingly. No intentional functional impact (except for some speedup). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com>
2023-10-20perf: qcom: use acpi_device_uid() for fetching _UIDRaag Jadav
Convert manual _UID references to use the standard ACPI helper. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-20ACPI: sysfs: use acpi_device_uid() for fetching _UIDRaag Jadav
Convert manual _UID references to use the standard ACPI helper. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-20Merge tag 'drm-fixes-2023-10-20' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "Regular fixes for the week, amdgpu, i915, nouveau, with some other scattered around, nothing major. amdgpu: - Fix possible NULL pointer dereference - Avoid possible BUG_ON in GPUVM updates - Disable AMD_CTX_PRIORITY_UNSET i915: - Fix display issue that was blocking S0ix - Retry gtt fault when out of fence registers bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup mediatek: - Correctly free sg_table in gem prime vmap" * tag 'drm-fixes-2023-10-20' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: Reserve fences for VM update drm/amdgpu: Fix possible null pointer dereference accel/ivpu: Extend address range for MMU mmap Revert "accel/ivpu: Use cached buffers for FW loading" accel/ivpu: Don't enter d0i3 during FLR drm/i915: Retry gtt fault when out of fence registers drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET drm/amdgpu: Unset context priority is now invalid drm/mediatek: Correctly free sg_table in gem prime vmap drm/edid: add 8 bpc quirk to the BenQ GW2765 drm/ttm: Reorder sys manager cleanup step drm/nouveau/disp: fix DP capable DSM connectors drm/nouveau: exec: fix ioctl kernel-doc warning drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device
2023-10-20ACPI: scan: Use the acpi_device_is_present() helper in more placesJames Morse
acpi_device_is_present() checks the present or functional bits from the cached copy of _STA. A few places open-code this check. Use the helper instead to improve readability. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Miguel Luis <miguel.luis@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-20Merge tag 'md-next-20231020' of ↵Jens Axboe
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into for-6.7/block Pull MD changes from Song: "1. Handle timeout in md-cluster, by Denis Plotnikov; 2. Cleanup pers->prepare_suspend, by Yu Kuai." * tag 'md-next-20231020' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md: md: cleanup pers->prepare_suspend() md-cluster: check for timeout while a new disk adding
2023-10-20Merge 3rd batch of EFI fixes into efi/urgentArd Biesheuvel
2023-10-20efi/unaccepted: Fix soft lockups caused by parallel memory acceptanceKirill A. Shutemov
Michael reported soft lockups on a system that has unaccepted memory. This occurs when a user attempts to allocate and accept memory on multiple CPUs simultaneously. The root cause of the issue is that memory acceptance is serialized with a spinlock, allowing only one CPU to accept memory at a time. The other CPUs spin and wait for their turn, leading to starvation and soft lockup reports. To address this, the code has been modified to release the spinlock while accepting memory. This allows for parallel memory acceptance on multiple CPUs. A newly introduced "accepting_list" keeps track of which memory is currently being accepted. This is necessary to prevent parallel acceptance of the same memory block. If a collision occurs, the lock is released and the process is retried. Such collisions should rarely occur. The main path for memory acceptance is the page allocator, which accepts memory in MAX_ORDER chunks. As long as MAX_ORDER is equal to or larger than the unit_size, collisions will never occur because the caller fully owns the memory block being accepted. Aside from the page allocator, only memblock and deferered_free_range() accept memory, but this only happens during boot. The code has been tested with unit_size == 128MiB to trigger collisions and validate the retry codepath. Fixes: 2053bc57f367 ("efi: Add unaccepted memory support") Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Michael Roth <michael.roth@amd.com Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Tested-by: Michael Roth <michael.roth@amd.com> [ardb: drop unnecessary cpu_relax() call] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-10-20Merge branch 'acpi-irq'Rafael J. Wysocki
Merge ACPI IRQ management fix for 6.6-rc7 (Sunil V L). * acpi-irq: ACPI: irq: Fix incorrect return value in acpi_register_gsi()
2023-10-20thunderbolt: Configure asymmetric link if needed and bandwidth allowsGil Fine
USB4 v2 spec defines a Gen 4 link that can operate as an asymmetric 120/40G. When the link is asymmetric, the USB4 port on one side of the link operates with three TX lanes and one RX lane, while the USB4 port on the opposite side of the link operates with three RX lanes and one TX lane. Using asymmetric link we can get much more bandwidth from one direction and that allows us to support the new Ultra High Bit Rate DisplayPort modes (that consume up to 77.37 Gb/s). Add the basic logic for changing Gen 4 links to asymmetric and back following the below rules: 1) The default threshold is 45 Gb/s (tunable by asym_threshold) 2) When DisplayPort tunnel is established, or when there is bandwidth request through bandwidth allocation mode, the links can be transitioned to asymmetric or symmetric (depending on the required bandwidth). 3) Only DisplayPort bandwidth on a link, is taken into account when deciding whether a link is transitioned to asymmetric or symmetric 4) If bandwidth on a link is >= asym_threshold transition the link to asymmetric 5) If bandwidth on a link < asym_threshold transition the link to symmetric (unless the bandwidth request is above currently allocated on a tunnel). 6) If a USB4 v2 device router with symmetric link is connected, transition all the links above it to symmetric if the bandwidth allows. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Add support for asymmetric linkGil Fine
USB4 v2 spec defines a Gen 4 link that can operate as an aggregated symmetric (80/80G) or asymmetric (120/40G). When the link is asymmetric, the USB4 port on one side of the link operates with three TX lanes and one RX lane, while the USB4 port on the opposite side of the link operates with three RX lanes and one TX lane. Add support for the asymmetric link and provide functions that can be used to transition the link to asymmetric and back. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Introduce tb_switch_depth()Mika Westerberg
This is useful helper to find out the depth of a connected router. Convert the existing users to call this helper instead of open-coding. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Introduce tb_for_each_upstream_port_on_path()Mika Westerberg
This is useful when walking over upstream lane adapters over given path. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Introduce tb_port_path_direction_downstream()Gil Fine
Introduce tb_port_path_direction_downstream() to check if path from source adapter to destination adapter is directed towards downstream. Convert existing users to call this helper instead of open-coding. No functional changes. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Set path power management packet support bit for USB4 v2 routersMika Westerberg
USB4 v2 spec allows USB4 links that are part of a pass through tunnel (such as DisplayPort and USB 3.x Gen T) to enter lower CL states, which provide better power management. For this USB4 v2 routers in their path config space of lane 0 adapter include a new bit PMPS (PM packet support) that needs to be set. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Change bandwidth reservations to comply USB4 v2Gil Fine
USB4 v2 Connection Manager guide (section 6.1.2.3) suggests to reserve bandwidth in a sligthly different manner. It suggests to keep minimum of 1500 Mb/s for each path that carry a bulk traffic. Here we change the bandwidth reservations to comply to the above for USB 3.x and PCIe protocols over Gen 4 link, taking weights into account (that's 1500 Mb/s for PCIe and 3000 Mb/s for USB 3.x). For Gen 3 and below we use the existing reservation. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Make is_gen4_link() available to the rest of the driverGil Fine
Rework the function to return the link generation, update the name to tb_port_get_link_generation(), and make available to the rest of the driver. This is needed in the subsequent patches. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Use weight constants in tb_usb3_consumed_bandwidth()Mika Westerberg
Instead of magic numbers use the constants we introduced in the previous commit to make the code more readable. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20thunderbolt: Use constants for path weight and priorityMika Westerberg
Makes it easier to follow and update. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-10-20igb: Fix potential memory leak in igb_add_ethtool_nfc_entryMateusz Palczewski
Add check for return of igb_update_ethtool_nfc_entry so that in case of any potential errors the memory alocated for input will be freed. Fixes: 0e71def25281 ("igb: add support of RX network flow classification") Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20treewide: Spelling fix in commentKunwu Chan
reques -> request Fixes: 09dde54c6a69 ("PS3: gelic: Add wireless support for PS3") Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20powerpc: Remove cpm_dp...() macrosChristophe Leroy
Since commit d3c511ac1d72 ("powerpc/cpm: Remove !CONFIG_PPC_CPM_NEW_BINDING code") cpm_dp...() macros have no added value anymore. Last user of those macros were fixed by commit 5e6cb39a256d ("net: fs_enet: Use cpm_muram_xxx() functions instead of cpm_dpxxx() macros") Remove them. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/3aaa40bf706afeab8fe9a74b8437704a4269a6a2.1697005615.git.christophe.leroy@csgroup.eu
2023-10-20PCI: dwc: Expose dw_pcie_ep_exit() to moduleYoshihiro Shimoda
Since no PCIe controller drivers call this, this change is not required for now. But, Renesas R-Car Gen4 PCIe controller driver will call this and if the controller driver is built as a kernel module, the following build error happens: ERROR: modpost: "dw_pcie_ep_exit" [drivers/pci/controller/dwc/pcie-rcar-gen4-ep-drv.ko] undefined! So, expose dw_pcie_ep_exit() for it. Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-8-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2023-10-20PCI: dwc: Add EDMA_UNROLL capability flagYoshihiro Shimoda
Renesas R-Car Gen4 PCIe controllers have an unexpected register value in the eDMA CTRL register. So, add a new capability flag "EDMA_UNROLL" which would force the unrolled eDMA mapping for the problematic device. Suggested-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-7-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2023-10-20PCI: dwc: endpoint: Add multiple PFs support for dbi2Yoshihiro Shimoda
The commit 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support for DWC") added .func_conf_select() to get the configuration space of different PFs and assumed that the offsets between dbi and dbi2 would be the same. However, Renesas R-Car Gen4 PCIe controllers have different offsets of function 1: dbi (+0x1000) and dbi2 (+0x800). To get the offset for dbi2, add .get_dbi2_offset() and dw_pcie_ep_get_dbi2_offset(). Note: - .func_conf_select() should be renamed later. - dw_pcie_ep_get_dbi2_offset() will call .func_conf_select() if .get_dbi2_offset() doesn't exist for backward compatibility. - dw_pcie_writeX_{dbi/dbi2} APIs accepted the func_no argument, so that these offset calculations are contained in the API definitions itself as it should. Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-6-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2023-10-20PCI: tegra194: Drop PCI_EXP_LNKSTA_NLW settingYoshihiro Shimoda
dw_pcie_setup() is already setting PCI_EXP_LNKCAP_MLW to pcie->num_lanes in the PCI_EXP_LNKCAP register for programming maximum link width. Hence, remove the redundant setting here. Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-5-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com>
2023-10-20PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handlingYoshihiro Shimoda
Update dw_pcie_link_set_max_link_width() to set PCI_EXP_LNKCAP_MLW. In accordance with the DW PCIe RC/EP HW manuals [1,2,3,...] aside with the PORT_LINK_CTRL_OFF.LINK_CAPABLE and GEN2_CTRL_OFF.NUM_OF_LANES[8:0] field there is another one which needs to be updated. It's LINK_CAPABILITIES_REG.PCIE_CAP_MAX_LINK_WIDTH. If it isn't done at the very least the maximum link-width capability CSR won't expose the actual maximum capability. [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, Version 4.60a, March 2015, p.1032 [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, Version 4.70a, March 2016, p.1065 [3] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, Version 4.90a, March 2016, p.1057 ... [X] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint, Version 5.40a, March 2019, p.1396 [X+1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, Version 5.40a, March 2019, p.1266 Suggested-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-4-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2023-10-20PCI: dwc: Add dw_pcie_link_set_max_link_width()Yoshihiro Shimoda
This is a preparation before adding the Max-Link-width capability setup which would in its turn complete the max-link-width setup procedure defined by Synopsys in the HW-manual. Seeing there is a max-link-speed setup method defined in the DW PCIe core driver it would be good to have a similar function for the link width setup. That's why we need to define a dedicated function first from already implemented but incomplete link-width setting up code. Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2023-10-20PCI: Add T_PVPERL macroYoshihiro Shimoda
According to the PCIe CEM r5.0, sec 2.9.2, Power stable to PERST# inactive interval is 100 ms as minimum. Add a macro so that the PCIe controller drivers can make use of it. Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2023-10-20ixgbe: fix end of loop test in ixgbe_set_vf_macvlan()Dan Carpenter
The list iterator in a list_for_each_entry() loop can never be NULL. If the loop exits without hitting a break then the iterator points to an offset off the list head and dereferencing it is an out of bounds access. Before we transitioned to using list_for_each_entry() loops, then it was possible for "entry" to be NULL and the comments mention this. I have updated the comments to match the new code. Fixes: c1fec890458a ("ethernet/intel: Use list_for_each_entry() helper") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20igb: Fix an end of loop testDan Carpenter
When we exit a list_for_each_entry() without hitting a break statement, the list iterator isn't NULL, it just point to an offset off the list_head. In that situation, it wouldn't be too surprising for entry->free to be true and we end up corrupting memory. The way to test for these is to just set a flag. Fixes: c1fec890458a ("ethernet/intel: Use list_for_each_entry() helper") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: cleanup ice_find_netlist_nodeJacob Keller
The ice_find_netlist_node function was introduced in commit 8a3a565ff210 ("ice: add admin commands to access cgu configuration"). Variations of this function were reviewed concurrently on both intel-wired-lan[1][2], and netdev [3][4] [1]: https://lore.kernel.org/intel-wired-lan/20230913204943.1051233-7-vadim.fedorenko@linux.dev/ [2]: https://lore.kernel.org/intel-wired-lan/20230817000058.2433236-5-jacob.e.keller@intel.com/ [3]: https://lore.kernel.org/netdev/20230918212814.435688-1-anthony.l.nguyen@intel.com/ [4]: https://lore.kernel.org/netdev/20230913204943.1051233-7-vadim.fedorenko@linux.dev/ The variant I posted had a few changes due to review feedback which were never incorporated into the DPLL series: * Replace the references to ancient and long removed ICE_SUCCESS and ICE_ERR_DOES_NOT_EXIST status codes in the function comment. * Return -ENOENT instead of -ENOTBLK, as a more common way to indicate that an entry doesn't exist. * Avoid the use of memset() and use simple static initialization for the cmd variable. * Use FIELD_PREP to assign the node_type_ctx. * Remove an unnecessary local variable to keep track of rec_node_handle, just pass the node_handle pointer directly into ice_aq_get_netlist_node. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: make ice_get_pf_c827_idx staticJacob Keller
The ice_get_pf_c827_idx function is only called inside of ice_ptp_hw.c, so there is no reason to export it. Mark it static and remove the declaration from ice_ptp_hw.h Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: manage VFs MSI-X using resource trackingMichal Swiatkowski
Track MSI-X for VFs using bitmap, by setting and clearing bitmap during allocation and freeing. Try to linearize irqs usage for VFs, by freeing them and allocating once again. Do it only for VFs that aren't currently running. Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: set MSI-X vector count on VFMichal Swiatkowski
Implement ops needed to set MSI-X vector count on VF. sriov_get_vf_total_msix() should return total number of MSI-X that can be used by the VFs. Return the value set by devlink resources API (pf->req_msix.vf). sriov_set_msix_vec_count() will set number of MSI-X on particular VF. Disable VF register mapping, rebuild VSI with new MSI-X and queues values and enable new VF register mapping. For best performance set number of queues equal to number of MSI-X. Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: add bitmap to track VF MSI-X usageMichal Swiatkowski
Create a bitamp to track MSI-X usage for VFs. The bitmap has the size of total MSI-X amount on device, because at init time the amount of MSI-X used by VFs isn't known. The bitmap is used in follow up patchset to provide a block of continuous block of MSI-X indexes for each created VF. Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: implement num_msix field per VFMichal Swiatkowski
Store the amount of MSI-X per VF instead of storing it in pf struct. It is used to calculate number of q_vectors (and queues) for VF VSI. This is necessary because with follow up changes the number of MSI-X can be different between VFs. Use it instead of using pf->vf_msix value in all cases. Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: store VF's pci_dev ptr in ice_vfPrzemek Kitszel
Extend struct ice_vf by vfdev. Calculation of vfdev falls more nicely into ice_create_vf_entries(). Caching of vfdev enables simplification of ice_restore_all_vfs_msi_state(). Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Co-developed-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com> Signed-off-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: add drop rule matching on not active lportMichal Swiatkowski
Inactive LAG port should not receive any packets, as it can cause adding invalid FDBs (bridge offload). Add a drop rule matching on inactive lport in LAG. Reviewed-by: Simon Horman <horms@kernel.org> Co-developed-by: Marcin Szycik <marcin.szycik@intel.com> Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20ice: remove unused ice_flow_entry fieldsPrzemek Kitszel
Remove ::entry and ::entry_sz fields of &ice_flow_entry, as they were never set. Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20i40e: Fix I40E_FLAG_VF_VLAN_PRUNING valueIvan Vecera
Commit c87c938f62d8f1 ("i40e: Add VF VLAN pruning") added new PF flag I40E_FLAG_VF_VLAN_PRUNING but its value collides with existing I40E_FLAG_TOTAL_PORT_SHUTDOWN_ENABLED flag. Move the affected flag at the end of the flags and fix its value. Reproducer: [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 link-down-on-close on [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 vf-vlan-pruning on [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 link-down-on-close off [ 6323.142585] i40e 0000:02:00.0: Setting link-down-on-close not supported on this port (because total-port-shutdown is enabled) netlink error: Operation not supported [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 vf-vlan-pruning off [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 link-down-on-close off The link-down-on-close flag cannot be modified after setting vf-vlan-pruning because vf-vlan-pruning shares the same bit with total-port-shutdown flag that prevents any modification of link-down-on-close flag. Fixes: c87c938f62d8 ("i40e: Add VF VLAN pruning") Cc: Mateusz Palczewski <mateusz.palczewski@intel.com> Cc: Simon Horman <horms@kernel.org> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20net: phy: micrel: Fix forced link mode for KSZ886X switchesOleksij Rempel
Address a link speed detection issue in KSZ886X PHY driver when in forced link mode. Previously, link partners like "ASIX AX88772B" with KSZ8873 could fall back to 10Mbit instead of configured 100Mbit. The issue arises as KSZ886X PHY continues sending Fast Link Pulses (FLPs) even with autonegotiation off, misleading link partners in autoneg mode, leading to incorrect link speed detection. Now, when autonegotiation is disabled, the driver sets the link state forcefully using KSZ886X_CTRL_FORCE_LINK bit. This action, beyond just disabling autonegotiation, makes the PHY state more reliably detected by link partners using parallel detection, thus fixing the link speed misconfiguration. With autonegotiation enabled, link state is not forced, allowing proper autonegotiation process participation. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Divya Koppera <divya.koppera@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20net: dsa: microchip: ksz8: Enable MIIM PHY Control reg accessOleksij Rempel
Provide access to MIIM PHY Control register (Reg. 31) through ksz8_r_phy_ctrl() and ksz8_w_phy_ctrl() functions. Necessary for upcoming micrel.c patch to address forced link mode configuration. Closes: https://lore.kernel.org/oe-kbuild-all/202310112224.iYgvjBUy-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20mlxsw: spectrum: Set SW LAG mode on Spectrum>1Petr Machata
On Spectrum-2, Spectrum-3 and Spectrum-4 machines, request SW responsibility for placement of the LAG table. On Spectrum-1, some FW versions claim to support lag_mode field despite quietly ignoring any settings made to that field. Thus refrain from attempting to configure lag_mode on those systems at all. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20mlxsw: spectrum: Allocate LAG table when in SW LAG modePetr Machata
In this patch, if the LAG mode is SW, allocate the LAG table and configure SGCR to indicate where it was allocated. We use the default "DDD" (for dynamic data duplication) layout of the LAG table. In the DDD mode, the membership information for each LAG is copied in 8 PGT entries. This is done for performance reasons. The LAG table then needs to be allocated on an address aligned to 8. Deal with this by moving the LAG init ahead so that the LAG table is allocated at address 0. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20mlxsw: spectrum_pgt: Generalize PGT allocationPetr Machata
PGT blocks are allocated through the function mlxsw_sp_pgt_mid_alloc_range(). The interface assumes that the caller knows which piece of PGT exactly they want to get. That was fine while the FID code was the only client allocating blocks of PGT. However for SW-allocated LAG table, there will be an additional client: mlxsw_sp_lag_init(). The interface should therefore be changed to not require particular coordinates, but to take just the requested size, allocate the block wherever, and give back the PGT address. In this patch, change the interface accordingly. Initialize FID family's pgt_base from the result of the PGT allocation (note that mlxsw makes a copy of the family structure, so what gets initialized is not actually the global structure). Drop the now-unnecessary pgt_base initializations and the corresponding defines. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20mlxsw: spectrum_fid: Allocate PGT for the whole FID family in one goPetr Machata
PGT blocks are allocated through the function mlxsw_sp_pgt_mid_alloc_range(). The interface assumes that the caller knows which piece of PGT exactly they want to get. That was fine while the FID code was the only client allocating blocks of PGT. However for SW-allocated LAG table, there will be an additional client: mlxsw_sp_lag_init(). The interface should therefore be changed to not require particular coordinates, but to take just the requested size, allocate the block wherever, and give back the PGT address. The current FID mode has one place where PGT address can be stored: the FID family's pgt_base. The allocation scheme should therefore be changed from allocating a block per FID flood table, to allocating a block per FID family. Do just that in this patch. The per-family allocation is going to be useful for another related feature as well: the CFF mode. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20mlxsw: pci: Permit toggling LAG modePetr Machata
Add to struct mlxsw_config_profile a field lag_mode_prefer_sw for the driver to indicate that SW LAG mode should be configured if possible. Add to the PCI module code to set lag_mode as appropriate. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20mlxsw: core, pci: Add plumbing related to LAG modePetr Machata
lag_mode describes where the responsibility for LAG table placement lies: SW or FW. The bus module determines whether LAG is supported, can configure it if it is, and knows what (if any) configuration has been applied. Therefore add a bus callback to determine the configured LAG mode. Also add to core an API to query it. The LAG mode is for now kept at the default value of 0 for FW-managed. The code to actually toggle it will be added later. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-20mlxsw: cmd: Add QUERY_FW.lag_mode_supportPetr Machata
Add QUERY_FW.lag_mode_support, which determines whether CONFIG_PROFILE.lag_mode is available. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-22 06:09:32 +0000