aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-05-08scsi: mpi3mr: Sanitise num_physTomas Henzl1-0/+10
Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed. Signed-off-by: Tomas Henzl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Sathya Prakash Veerichetty <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-05-08bcache: fix variable length array abuse in btree_iterMatthew Mirvish6-59/+70
btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array. Cc: [email protected] Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039368 Signed-off-by: Matthew Mirvish <[email protected]> Signed-off-by: Coly Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-08bcache: Remove usage of the deprecated ida_simple_xx() APIChristophe JAILLET1-5/+5
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). Note that the upper limit of ida_simple_get() is exclusive, but the one of ida_alloc_max() is inclusive. So a -1 has been added when needed. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Coly Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-08PCI: Make pcie_bandwidth_capable() staticIlpo Järvinen2-4/+3
pcie_bandwidth_capable() is only used within pci.c, make it static. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2024-05-09firewire: obsolete usage of *-objs in Makefile for KUnit testTakashi Sakamoto1-5/+2
Nowadays *-objs list is just for user space programs. This commit obsolete the usage, and simplify Makefile for firewire KUnit tests since the tests are not composite objects. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]>
2024-05-08PCI/EDR: Align EDR_PORT_LOCATE_DSM with PCI Firmware r3.3Kuppuswamy Sathyanarayanan1-2/+13
The "Downstream Port Containment related Enhancements" ECN of Jan 28, 2019 (document 12888 below), defined the EDR_PORT_LOCATE_DSM function with Revision ID 5 with a return value encoding (Bits 2:0 = Function, Bits 7:3 = Device, Bits 15:8 = Bus). When the ECN was integrated into PCI Firmware r3.3, sec 4.6.13, Bit 31 was added to indicate success or failure. Check Bit 31 for failure in acpi_dpc_port_get(). Link: https://lore.kernel.org/r/20240501022543.1626025-1-sathyanarayanan.kuppuswamy@linux.intel.com Link: https://members.pcisig.com/wg/PCI-SIG/document/12888 Fixes: ac1c8e35a326 ("PCI/DPC: Add Error Disconnect Recover (EDR) support") Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> [bhelgaas: split into two patches, update commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Satish Thatchanamurthy <[email protected]> # one platform
2024-05-08Revert "drm/amdkfd: Add partition id field to location_id"Lijo Lazar1-3/+2
This reverts commit c37ce764cd492f044dcdbb39616298f02b0dbc7f. RCCL library is currently not treating spatial partitions differently, hence this change is causing issues. Revert temporarily till RCCL implementation is ready for spatial partitions. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Jonathan Kim <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-08dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 usersMario Limonciello1-1/+1
Limit the workaround introduced by commit 31729e8c21ec ("drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11") to only run in the s4 path. Cc: Tim Huang <[email protected]> Fixes: 31729e8c21ec ("drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3351 Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-08drm/amd/display: MST DSC check for older devicesAgustin Gutierrez1-6/+8
[Why] Some older MST hubs do not report DPCD registers according to specification. [How] This change re-applies commit c53655545141 ("drm/amd/display: dsc mst re-compute pbn for changes on hub"). With an additional check for these older MST devices. Reviewed-by: Swapnil Patel <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Agustin Gutierrez <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-08drm/amd/display: Fix idle optimization checks for multi-display and dual eDPNicholas Kazlauskas1-6/+27
[Why] Idle optimizations are blocked if there's more than one eDP connector on the board - blocking S0i3 and IPS2 for static screen. [How] Fix the checks to correctly detect number of active eDP. Also restrict the eDP support to panels that have correct feature support. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Reviewed-by: Charlene Liu <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-08drm/amd/display: Fix DSC-re-computingAgustin Gutierrez1-5/+13
[Why] This fixes a bug introduced by commit c53655545141 ("drm/amd/display: dsc mst re-compute pbn for changes on hub"). The change caused light-up issues with a second display that required DSC on some MST docks. [How] Use Virtual DPCD for DSC caps in MST case. [Limitations] This change only affects MST DSC devices that follow specifications additional changes are required to check for old MST DSC devices such as ones which do not check for Virtual DPCD registers. Reviewed-by: Swapnil Patel <[email protected]> Reviewed-by: Hersen Wu <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Agustin Gutierrez <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-08drm/amd/display: Enable urgent latency adjustments for DCN35Nicholas Susanto1-2/+2
[Why] Underflow occurs when running Netflix in a 4k144 eDP + 4k60 HDMI FRL setup. It is caused by latency varying based on the DCFCLK/FCLK state. [How] Enable urgent latency adjustment and match the reference to existing ASIC that also see increased latency at low FCLK. Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Nicholas Susanto <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-08PCI/EDR: Align EDR_PORT_DPC_ENABLE_DSM with PCI Firmware r3.3Kuppuswamy Sathyanarayanan1-9/+4
The "Downstream Port Containment related Enhancements" ECN of Jan 28, 2019 (document 12888 below), defined the EDR_PORT_DPC_ENABLE_DSM function with Revision ID 5 with Arg3 being an integer. But when the ECN was integrated into PCI Firmware r3.3, sec 4.6.12, it was defined as Revision ID 6 with Arg3 being a package containing an integer. The implementation in acpi_enable_dpc() supplies a package as Arg3 (arg4 in the code), but it previously specified Revision ID 5. Align this with PCI Firmware r3.3 by using Revision ID 6. If firmware implemented per the ECN, its Revision 5 function would receive a package as Arg3 when it expects an integer, so acpi_enable_dpc() would likely fail. If such firmware exists and lacks a Revision 6 function that expects a package, we may have to add support for Revision 5. Link: https://lore.kernel.org/r/20240501022543.1626025-1-sathyanarayanan.kuppuswamy@linux.intel.com Link: https://members.pcisig.com/wg/PCI-SIG/document/12888 Fixes: ac1c8e35a326 ("PCI/DPC: Add Error Disconnect Recover (EDR) support") Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> [bhelgaas: split into two patches, update commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Satish Thatchanamurthy <[email protected]> # one platform
2024-05-08cxl: Add post-reset warning if reset results in loss of previously committed ↵Dave Jiang3-0/+53
HDM decoders Secondary Bus Reset (SBR) is equivalent to a device being hot removed and inserted again. Doing a SBR on a CXL type 3 device is problematic if the exported device memory is part of system memory that cannot be offlined. The event is equivalent to violently ripping out that range of memory from the kernel. While the hardware requires the "Unmask SBR" bit set in the Port Control Extensions register and the kernel currently does not unmask it, user can unmask this bit via setpci or similar tool. The driver does not have a way to detect whether a reset coming from the PCI subsystem is a Function Level Reset (FLR) or SBR. The only way to detect is to note if a decoder is marked as enabled in software but the decoder control register indicates it's not committed. Add a helper function to find discrepancy between the decoder software state versus the hardware register state. Suggested-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Dan Williams <[email protected]>
2024-05-08PCI/CXL: Add 'cxl_bus' reset method for devices below CXL PortsDave Jiang1-0/+39
By default Secondary Bus Reset (SBR) is masked for CXL Ports (see CXL r3.1, sec 8.1.5.2). Add cxl_reset_bus_function() (method "cxl_bus") to set the "Unmask SBR" bit in the upstream CXL Port before performing the bus reset and restore the original value afterwards. This method allows the user to perform a bus reset on a CXL device without needing to set the "Unmask SBR" bit via a user tool. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dave Jiang <[email protected]> [bhelgaas: simplify commit log, invert condition to avoid negation] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Dan Williams <[email protected]>
2024-05-08PCI/CXL: Fail bus reset if upstream CXL Port has SBR maskedDave Jiang1-0/+42
Per CXL spec r3.1, sec 8.1.5.2, the Secondary Bus Reset (SBR) bit in the Bridge Control register of a CXL port has no effect unless the "Unmask SBR" bit is set. Return -ENOTTY if we attempt a bus reset on a device below a CXL Port where "Unmask SBR" is 0. Otherwise, the bus reset would appear to have succeeded even though setting the bridge SBR bit had no effect. Link: https://lore.kernel.org/linux-cxl/20240220203956.GA1502351@bhelgaas/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dave Jiang <[email protected]> [bhelgaas: simplify commit log and comments] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Dan Williams <[email protected]>
2024-05-08PCI: Lock upstream bridge for pci_reset_function()Dave Jiang3-0/+20
Fix a long-standing locking gap for missing pci_cfg_access_lock() while manipulating bridge reset registers and configuration during pci_reset_bus_function(). If there is an upstream bridge, lock it before locking the device itself. pci_dev_lock() calls pci_cfg_access_lock(), which blocks the writing of PCI config space by user space. Add lockdep assertion via pci_dev->cfg_access_lock to verify pci_dev->block_cfg_access is set. Co-developed-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Dave Jiang <[email protected]> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <[email protected]>
2024-05-08PCI/CXL: Move CXL Vendor ID to pci_ids.hDave Jiang5-7/+6
Move PCI_DVSEC_VENDOR_ID_CXL in CXL private code to PCI_VENDOR_ID_CXL in pci_ids.h in order to be utilized in PCI subsystem. While the CXL Vendor ID (0x1e98) is not listed in the PCI SIG "Member Companies" database at https://pcisig.com/membership/member-companies, the SIG has confirmed that it is reserved by CXL. Link: https://lore.kernel.org/r/[email protected] Suggested-by: Bjorn Helgaas <[email protected]> Link: https://lore.kernel.org/linux-cxl/20240402172323.GA1818777@bhelgaas/ Signed-off-by: Dave Jiang <[email protected]> [bhelgaas: update commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Reviewed-by: Dan Williams <[email protected]>
2024-05-08media: media: intel/ipu6: Fix spelling mistake "remappinp" -> "remapping"Colin Ian King1-1/+1
There is a spelling mistake in a dev_err_probe message. Fix it. Link: https://lore.kernel.org/linux-media/[email protected] Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2024-05-08media: intel/ipu6: explicitly include vmalloc.hStephen Rothwell1-0/+1
linux/vmalloc.h needs to be included explicitly nowadays. Do it. Link: https://lore.kernel.org/linux-media/[email protected] Fixes: 9163d83573e4 ("media: intel/ipu6: add IPU6 DMA mapping API and MMU table") Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2024-05-08Merge tag 'soc-fixes-6.9-3' of ↵Linus Torvalds2-4/+6
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "These are a couple of last minute fixes that came in over the previous week, addressing: - A pin configuration bug on a qualcomm board that caused issues with ethernet and mmc - Two minor code fixes for misleading console output in the microchip firmware driver - A build warning in the sifive cache driver" * tag 'soc-fixes-6.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: firmware: microchip: clarify that sizes and addresses are in hex firmware: microchip: don't unconditionally print validation success arm64: dts: qcom: sa8155p-adp: fix SDHC2 CD pin configuration cache: sifive_ccache: Silence unused variable warning
2024-05-08of: module: add buffer overflow check in of_modalias()Sergey Shtylyov1-3/+4
In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char). Fixes: bc575064d688 ("of/device: use of_property_for_each_string to parse compatible strings") Signed-off-by: Sergey Shtylyov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2024-05-08Merge tag 'pci-v6.9-fixes-2' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fixes from Bjorn Helgaas: - Update kernel-parameters doc to describe "pcie_aspm=off" more accurately (Bjorn Helgaas) - Restore the parent's (not the child's) ASPM state to the parent during resume, which fixes a reboot during resume (Kai-Heng Feng) * tag 'pci-v6.9-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/ASPM: Restore parent state to parent, child state to child PCI/ASPM: Clarify that pcie_aspm=off means leave ASPM untouched
2024-05-08net: e1000e & ixgbe: Remove PCI_HEADER_TYPE_MFD duplicatesIlpo Järvinen2-3/+0
PCI_HEADER_TYPE_MULTIFUNC is define by e1000e and ixgbe and both are unused. There is already PCI_HEADER_TYPE_MFD in pci_regs.h anyway which should be used instead so remove the duplicated defines of it. Signed-off-by: Ilpo Järvinen <[email protected]> Reviewed-by: Hariprasad Kelam <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Acked-by: Sasha Neftin <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-05-08igc: fix a log entry using uninitialized netdevCorinna Vinschen1-2/+3
During successful probe, igc logs this: [ 5.133667] igc 0000:01:00.0 (unnamed net_device) (uninitialized): PHC added ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The reason is that igc_ptp_init() is called very early, even before register_netdev() has been called. So the netdev_info() call works on a partially uninitialized netdev. Fix this by calling igc_ptp_init() after register_netdev(), right after the media autosense check, just as in igb. Add a comment, just as in igb. Now the log message is fine: [ 5.200987] igc 0000:01:00.0 eth0: PHC added Signed-off-by: Corinna Vinschen <[email protected]> Reviewed-by: Hariprasad Kelam <[email protected]> Acked-by: Vinicius Costa Gomes <[email protected]> Tested-by: Naama Meir <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-05-08ice: remove correct filters during eswitch releaseMichal Swiatkowski1-1/+4
ice_clear_dflt_vsi() is only removing default rule. Both default RX and TX rule should be removed during release. If it isn't switching to switchdev, second time results in error, because TX filter is already there. Fix it by removing the correct set of rules. Fixes: 50d62022f455 ("ice: default Tx rule instead of to queue") Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: Michal Swiatkowski <[email protected]> Signed-off-by: Marcin Szycik <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Sujai Buvaneswaran <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-05-08igb: flower: validate control flagsAsbjørn Sloth Tønnesen1-0/+3
This driver currently doesn't support any control flags. Use flow_rule_match_has_control_flags() to check for control flags, such as can be set through `tc flower ... ip_flags frag`. In case any control flags are masked, flow_rule_match_has_control_flags() sets a NL extended error message, and we return -EOPNOTSUPP. Only compile-tested. Signed-off-by: Asbjørn Sloth Tønnesen <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2024-05-08ice: flower: validate control flagsAsbjørn Sloth Tønnesen1-0/+4
This driver currently doesn't support any control flags. Use flow_rule_has_control_flags() to check for control flags, such as can be set through `tc flower ... ip_flags frag`. In case any control flags are masked, flow_rule_has_control_flags() sets a NL extended error message, and we return -EOPNOTSUPP. Only compile-tested. Signed-off-by: Asbjørn Sloth Tønnesen <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Sujai Buvaneswaran <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-05-08iavf: flower: validate control flagsAsbjørn Sloth Tønnesen1-0/+4
This driver currently doesn't support any control flags. Use flow_rule_has_control_flags() to check for control flags, such as can be set through `tc flower ... ip_flags frag`. In case any control flags are masked, flow_rule_has_control_flags() sets a NL extended error message, and we return -EOPNOTSUPP. Only compile-tested. Signed-off-by: Asbjørn Sloth Tønnesen <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Sujai Buvaneswaran <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-05-08i40e: flower: validate control flagsAsbjørn Sloth Tønnesen1-0/+4
This driver currently doesn't support any control flags. Use flow_rule_has_control_flags() to check for control flags, such as can be set through `tc flower ... ip_flags frag`. In case any control flags are masked, flow_rule_has_control_flags() sets a NL extended error message, and we return -EOPNOTSUPP. Only compile-tested. Signed-off-by: Asbjørn Sloth Tønnesen <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Sujai Buvaneswaran <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2024-05-08media: stih-cec: add missing io.hAndy Shevchenko1-0/+1
In the driver the io.h is implied by others. This is not good as it prevents from cleanups done in other headers. Add missing include. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Cc: Alain Volmat <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Hans Verkuil <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Patrice Chotard <[email protected]> Cc: Rob Herring <[email protected]> Cc: Samuel Holland <[email protected]> Cc: Sean Wang <[email protected]> Cc: Sean Young <[email protected]> Cc: Stefani Seibold <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-08media: rc: add missing io.hAndy Shevchenko4-0/+4
Patch series "kfifo: Clean up kfifo.h", v2. To reduce dependency hell a degree, clean up kfifo.h (mainly getting rid of kernel.h in the global header). This patch (of 3): In many remote control drivers the io.h is implied by others. This is not good as it prevents from cleanups done in other headers. Add missing include. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Cc: Alain Volmat <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Hans Verkuil <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Patrice Chotard <[email protected]> Cc: Rob Herring <[email protected]> Cc: Samuel Holland <[email protected]> Cc: Sean Wang <[email protected]> Cc: Sean Young <[email protected]> Cc: Stefani Seibold <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-09PM / devfreq: exynos: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsAnand Moon1-6/+3
This macro has the advantage over SET_SYSTEM_SLEEP_PM_OPS that we don't have to care about when the functions are actually used. Also make use of pm_sleep_ptr() to discard all PM_SLEEP related stuff if CONFIG_PM_SLEEP isn't enabled. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Anand Moon <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-05-08clkdev: report over-sized strings when creating clkdev entriesRussell King (Oracle)1-2/+33
Report an error when an attempt to register a clkdev entry results in a truncated string so the problem can be easily spotted. Reported by: Duanqiang Wen <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2024-05-08PM / devfreq: rk3399_dmc: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-05-08PM / devfreq: sun8i-a33-mbus: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-05-08PM / devfreq: mtk-cci: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-05-08PM / devfreq: exynos-ppmu: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-05-08PM / devfreq: exynos-nocp: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
2024-05-08nvmet-rdma: fix possible bad dereference when freeing rspsSagi Grimberg1-12/+4
It is possible that the host connected and saw a cm established event and started sending nvme capsules on the qp, however the ctrl did not yet see an established event. This is why the rsp_wait_list exists (for async handling of these cmds, we move them to a pending list). Furthermore, it is possible that the ctrl cm times out, resulting in a connect-error cm event. in this case we hit a bad deref [1] because in nvmet_rdma_free_rsps we assume that all the responses are in the free list. We are freeing the cmds array anyways, so don't even bother to remove the rsp from the free_list. It is also guaranteed that we are not racing anything when we are releasing the queue so no other context accessing this array should be running. [1]: -- Workqueue: nvmet-free-wq nvmet_rdma_free_queue_work [nvmet_rdma] [...] pc : nvmet_rdma_free_rsps+0x78/0xb8 [nvmet_rdma] lr : nvmet_rdma_free_queue_work+0x88/0x120 [nvmet_rdma] Call trace: nvmet_rdma_free_rsps+0x78/0xb8 [nvmet_rdma] nvmet_rdma_free_queue_work+0x88/0x120 [nvmet_rdma] process_one_work+0x1ec/0x4a0 worker_thread+0x48/0x490 kthread+0x158/0x160 ret_from_fork+0x10/0x18 -- Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2024-05-08nvmet: prevent sprintf() overflow in nvmet_subsys_nsid_exists()Dan Carpenter1-3/+2
The nsid value is a u32 that comes from nvmet_req_find_ns(). It's endian data and we're on an error path and both of those raise red flags. So let's make this safer. 1) Make the buffer large enough for any u32. 2) Remove the unnecessary initialization. 3) Use snprintf() instead of sprintf() for even more safety. 4) The sprintf() function returns the number of bytes printed, not counting the NUL terminator. It is impossible for the return value to be <= 0 so delete that. Fixes: 505363957fad ("nvmet: fix nvme status code when namespace is disabled") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2024-05-08thermal: intel: hfi: Increase the number of CPU capabilities per netlink eventRicardo Neri1-1/+1
The number of updated CPU capabilities per netlink event is hard-coded to 16. On systems with more than 16 CPUs (a common case), it takes more than one thermal netlink event to relay all the new capabilities after an HFI interrupt. This adds unnecessary overhead to both the kernel and user space entities. Increase the number of CPU capabilities updated per event to 64. Any system with 64 CPUs or less can now update all the capabilities in a single thermal netlink event. Signed-off-by: Ricardo Neri <[email protected]> Acked-by: Zhang Rui <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-05-08thermal: intel: hfi: Rename HFI_MAX_THERM_NOTIFY_COUNTRicardo Neri1-6/+6
When processing a hardware update, HFI generates as many thermal netlink events as needed to relay all the updated CPU capabilities to user space. The constant HFI_MAX_THERM_NOTIFY_COUNT is the number of CPU capabilities updated per each of those events. Give this constant a more descriptive name. Signed-off-by: Ricardo Neri <[email protected]> Acked-by: Zhang Rui <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-05-08thermal: intel: hfi: Shorten the thermal netlink event delay to 100msRicardo Neri1-2/+2
The delay between an HFI interrupt and its corresponding thermal netlink event has so far been hard-coded to CONFIG_HZ jiffies (1 second). This delay is too long for hardware that generates updates every tens of milliseconds. The HFI driver uses a delayed workqueue to send thermal netlink events. No subsequent events will be sent if there is pending work. As a result, much of the information of consecutive hardware updates will be lost if the workqueue delay is too long. User space entities may act on obsolete data. If the delay is too short, multiple events may overwhelm listeners. Set the delay to 100ms to strike a balance between too many and too few events. Use milliseconds instead of jiffies to improve readability. Signed-off-by: Ricardo Neri <[email protected]> Acked-by: Zhang Rui <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-05-08thermal: intel: hfi: Rename HFI_UPDATE_INTERVALRicardo Neri1-2/+2
The name of the constant HFI_UPDATE_INTERVAL is misleading. It is not a periodic interval at which HFI updates are processed. It is the delay in the processing of an HFI update after the arrival of an HFI interrupt. Acked-by: Zhang Rui <[email protected]> Signed-off-by: Ricardo Neri <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-05-08cpufreq: amd-pstate: fix the highest frequency issue which limits performancePerry Yuan1-3/+19
To address the performance drop issue, an optimization has been implemented. The incorrect highest performance value previously set by the low-level power firmware for AMD CPUs with Family ID 0x19 and Model ID ranging from 0x70 to 0x7F series has been identified as the cause. To resolve this, a check has been implemented to accurately determine the CPU family and model ID. The correct highest performance value is now set and the performance drop caused by the incorrect highest performance value are eliminated. Before the fix, the highest frequency was set to 4200MHz, now it is set to 4971MHz which is correct. CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ 0 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 1 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 2 0 0 1 1:1:1:0 yes 4971.0000 400.0000 4865.8140 3 0 0 1 1:1:1:0 yes 4971.0000 400.0000 400.0000 Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759 Signed-off-by: Perry Yuan <[email protected]> Co-developed-by: Mario Limonciello <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Tested-by: Gaha Bana <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-05-08net: stmmac: dwmac-ipq806x: account for rgmii-txid/rxid/id phy-modeChristian Marangi1-0/+12
Currently the ipq806x dwmac driver is almost always used attached to the CPU port of a switch and phy-mode was always set to "rgmii" or "sgmii". Some device came up with a special configuration where the PHY is directly attached to the GMAC port and in those case phy-mode needs to be set to "rgmii-id" to make the PHY correctly work and receive packets. Since the driver supports only "rgmii" and "sgmii" mode, when "rgmii-id" (or variants) mode is set, the mode is rejected and probe fails. Add support also for these phy-modes to correctly setup PHYs that requires delay applied to tx/rx. Signed-off-by: Christian Marangi <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-08net: phy: marvell-88q2xxx: add support for Rev B1 and B2Gregor Herburger1-16/+103
Different revisions of the Marvell 88q2xxx phy needs different init sequences. Add init sequence for Rev B1 and Rev B2. Rev B2 init sequence skips one register write. Tested-by: Dimitri Fedrau <[email protected]> Signed-off-by: Gregor Herburger <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-08net: dsa: microchip: add support DSCP priority mappingOleksij Rempel3-15/+50
Microchip KSZ and LAN variants do not have per port DSCP priority configuration. Instead there is a global DSCP mapping table. This patch provides write access to this global DSCP map. In case entry is "deleted", we map corresponding DSCP entry to a best effort prio, which is expected to be the default priority for all untagged traffic. Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-08net: dsa: microchip: let DCB code do PCP and DSCP policy configurationOleksij Rempel2-12/+0
802.1P (PCP) and DiffServ (DSCP) are handled now by DCB code. Let it do all needed initial configuration. Signed-off-by: Oleksij Rempel <[email protected]> Acked-by: Arun Ramadoss <[email protected]> Signed-off-by: David S. Miller <[email protected]>