summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-05-01platform/x86: ISST: Support SST-BF and SST-TF per levelSrinivas Pandruvada
SST SST-BF and SST-TF can be enabled/disabled per SST-PP level. So return a mask of all levels, where the feature is supported, instead of just for level 0. Since the return value returns all levels mask, not just level 0, update API version. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com> Link: https://lore.kernel.org/r/20240430221052.15825-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-05-01iio: invensense: fix interrupt timestamp alignmentJean-Baptiste Maneyrol
Restrict interrupt timestamp alignment for not overflowing max/min period thresholds. Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20240426135814.141837-1-inv.git-commit@tdk.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-05-01usb: xhci: compact 'trb_in_td()' argumentsNiklas Neronin
Pass pointer to the TD (struct xhci_td *) directly, instead of its components separately. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-19-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: remove duplicate TRB_TO_SLOT_ID() callsNiklas Neronin
Remove unnecessary repeated calls to TRB_TO_SLOT_ID(). The slot ID is stored in the 'slot_id' variable at the function's start. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01xhci: pci: Use PCI_VENDOR_ID_RENESASAndy Shevchenko
Instead of plain hexadecimal, use already defined PCI_VENDOR_ID_RENESAS. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01xhci: pci: Group out Thunderbolt xHCI IDsAndy Shevchenko
It's better to keep track on Thunderbolt xHCI IDs in a separate group. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01xhci: pci: Use full names in PCI IDs for Intel platformsAndy Shevchenko
There are three out of many Intel platforms that are using TLAs instead of the full names in the PCI IDs. Modify them accordingly. This also fixes the logic of grouping as seemed to be by an LSB byte of the ID. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: remove goto 'cleanup' in handle_tx_event()Niklas Neronin
By removing the goto 'cleanup' statement, and replacing it with 'continue', 'break' and 'return', helps simplify the code and further showcase in which case the while loop iterates. This change prepares for the comprehensive handle_tx_event() rework. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: replace goto with return when possible in handle_tx_event()Niklas Neronin
Simplifying the handle_tx_event() function by addressing the complexity of its while loop. Replaces specific 'goto cleanup' statements with 'return' statements, applicable only where 'ep->skip' is set to 'false', ensuring loop termination. The original while loop, combined with 'goto cleanup', adds unnecessary complexity. This change aims to untangle the loop's logic, facilitating a more straightforward review of the upcoming comprehensive rework. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: remove 'handling_skipped_tds' from handle_tx_event()Niklas Neronin
When handle_tx_event() encounters a COMP_MISSED_SERVICE_ERROR or COMP_NO_PING_RESPONSE_ERROR event, it moves to 'goto cleanup'. Here, it sets a flag, 'handling_skipped_tds', based on conditions that exclude these two error events. Subsequently, the process evaluates the loop that persists as long as 'handling_skipped_tds' remains true. However, since 'trb_comp_code' does not change after its assignment, if it indicates either of the two error conditions, the loop terminates immediately. To simplify this process and enhance clarity, the modification involves returning immediately upon detecting COMP_MISSED_SERVICE_ERROR or COMP_NO_PING_RESPONSE_ERROR. This adjustment allows for the direct use of 'ep->skip', removing the necessity for the 'handling_skipped_tds' flag. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: prevent potential failure in handle_tx_event() for Transfer ↵Niklas Neronin
events without TRB Some transfer events don't always point to a TRB, and consequently don't have a endpoint ring. In these cases, function handle_tx_event() should not proceed, because if 'ep->skip' is set, the pointer to the endpoint ring is used. To prevent a potential failure and make the code logical, return after checking the completion code for a Transfer event without TRBs. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01xhci: remove XHCI_TRUST_TX_LENGTH quirkMathias Nyman
If this quirk was set then driver would treat transfer events with 'Success' completion code as 'Short packet' if there were untransferred bytes left. This is so common that turn it into default behavior. xhci_warn_ratelimited() is no longer used after this, so remove it. A success event with untransferred bytes left doesn't always mean a misbehaving controller. If there was an error mid a multi-TRB TD it's allowed to issue a success event for the last TRB in that TD. See xhci 1.2 spec 4.9.1 Transfer Descriptors "Note: If an error is detected while processing a multi-TRB TD, the xHC shall generate a Transfer Event for the TRB that the error was detected on with the appropriate error Condition Code, then may advance to the next TD. If in the process of advancing to the next TD, a Transfer TRB is encountered with its IOC flag set, then the Condition Code of the Transfer Event generated for that Transfer TRB should be Success, because there was no error actually associated with the TRB that generated the Event. However, an xHC implementation may redundantly assert the original error Condition Code." Co-developed-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01xhci: improve PORTSC register debugging outputMathias Nyman
Print the full hex value of PORTSC register in addition to the human readable decoded string while debugging PORTSC value. If PORTSC value is 0xffffffff then don't decode it. This lets us inspect Rsvd bits of PORTSC. Same is done for USBSTS register values. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: use array_size() when allocating and freeing memoryNiklas Neronin
Replace size_mul() with array_size() in memory allocation and freeing processes, it fits better semantically. Macro array_size() is identical to size_mult(), which clamps the max size, so it's imperative that array_size() is used when freeing said memory. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: remove redundant variable 'erst_size'Niklas Neronin
'erst_size' represents the maximum capacity of entries that ERST can hold, while 'num_entries' indicates the actual number of entries currently held in the ERST. These two values are identical because the xhci driver does not support ERST expansion. Thus, 'erst_size' is removed. Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: address off-by-one in xhci_num_trbs_free()Niklas Neronin
Reduce the number of do-while loops by 1. The number of loops should be number of segment + 1, the +1 is in case deq and enq are on the same segment. But due to the use of a do-while loop, the expression is evaluated after executing the loop, thus the loop is executed 1 extra time. Changing the do-while loop expression from "<=" to "<", reduces the loop amount by 1. The expression "<=" would also work if it was a while loop instead of a do-while loop. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: improve debug message in xhci_ring_expansion_needed()Niklas Neronin
Address debug message inaccuracies in xhci_ring_expansion_needed(). Specifically, remove the portion of the debug message that indicates the number of enqueue TRBs to be added to the dequeue segment. This part of the message may mislead and the calculated value is incorrect. Given that this value is not of significant importance and the statement is not consistently accurate, it has been omitted. The specific issues with the debug message that this commit resolves: - The calculation of the number of TRBs is incorrect. The current calculation erroneously includes the link TRB, which is reserved. Furthermore, the calculated number of TRBs can exceed the dequeue segment, resulting in a misleading debug message. - The current phrasing suggests that "ring expansion by X is needed, adding X TRBs moves enqueue Y TRBs into the dequeue segment". The intended message, however, is "IF the ring is NOT expanded by X, THEN adding X TRBs moves enqueue Y TRBs into the dequeue segment". Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01usb: xhci: check if 'requested segments' exceeds ERST capacityNiklas Neronin
Check if requested segments ('segs' or 'ERST_DEFAULT_SEGS') exceeds the maximum amount ERST supports. When 'segs' is '0', 'ERST_DEFAULT_SEGS' is used instead. But both values may not exceed ERST max. Macro 'ERST_MAX_SEGS' is renamed to 'ERST_DEFAULT_SEGS'. The new name better represents the macros, which is the number of Event Ring segments to allocate, when the amount is not specified. Additionally, rename and change xhci_create_secondary_interrupter()'s argument 'int num_segs' to 'unsigned int segs'. This makes it the same as its counter part in xhci_alloc_interrupter(). Fixes: c99b38c41234 ("xhci: add support to allocate several interrupters") Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01xhci: remove xhci_check_usb2_port_capability helperMathias Nyman
This helper was only called from one function. Removing it both reduces lines of code and made it more readable. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01xhci: stored cached port capability values in one placeMathias Nyman
Port capability flags for USB2 ports have been cached in an u32 xhci->ext_caps[] array long before the driver had struct xhci_port and struct xhci_port_cap structures. Move these cached USB2 port capability values together with the other port capability values into struct xhci_port_cap cability structure. This also gets rid of the cumbersome way of mapping port to USB2 capability based on portnum as each port has a pointer to its capability structure. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240429140245.3955523-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-01Merge tag 'mhi-for-6.10' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi into char-misc-next Manivannan writes: MHI Host ======== - Added a new API mhi_power_down_keep_dev() to not destroy the struct dev associated with the MHI channels during MHI power down. This is useful in scenarios such as system suspend/hibernation where the probability of channels coming back is very high. So the PM maintainer suggested not to destroy the struct dev in those cases. This API is introduced for fixing the failure reported in the ath11k driver during resume from system suspend. NOTE: Due to the API dependency, the patch adding the API is pushed to an immutable branch (mhi-immutable) and merged into both mhi and ath trees. But the merge commit is not visible in mhi tree due to git being smart with 'fast-forward'. - Added an optional sysfs entry to force the MHI devices to enter the Emergency Download (EDL) mode to download the firmware from host. - Added EDL mode support for Qcom SDX75/65/55 modems as per the MHI spec v1.2, Chapter 13.2. This involves writing a cookie to the EDL doorbell registers and then triggering the device reset from host. * tag 'mhi-for-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi: bus: mhi: host: pci_generic: Add generic edl_trigger to allow devices to enter EDL mode bus: mhi: host: Add a new API for getting channel doorbell offset bus: mhi: host: Add sysfs entry to force device to enter EDL bus: mhi: host: Add mhi_power_down_keep_dev() API to support system suspend/hibernation
2024-05-01spi: fix null pointer dereference within spi_syncMans Rullgard
If spi_sync() is called with the non-empty queue and the same spi_message is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spi_finalize_current_message(). With function inlining disabled, the call stack might look like this: _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474 spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue from __spi_sync+0x204/0x248 __spi_sync from spi_sync+0x24/0x3c spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd] mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154 _regmap_raw_read from _regmap_bus_read+0x44/0x70 _regmap_bus_read from _regmap_read+0x60/0xd8 _regmap_read from regmap_read+0x3c/0x5c regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x118/0x1f4 irq_thread from kthread+0xd8/0xf4 kthread from ret_from_fork+0x14/0x28 Fix this by also setting message->complete to NULL when the transfer is complete. Fixes: ae7d2346dc89 ("spi: Don't use the message queue if possible in spi_sync") Signed-off-by: Mans Rullgard <mans@mansr.com> Link: https://lore.kernel.org/r/20240430182705.13019-1-mans@mansr.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-30net: loopback: Do not allocate lstats explicitlyBreno Leitao
With commit 34d21de99cea9 ("net: Move {l,t,d}stats allocation to core and convert veth & vrf"), stats allocation could be done on net core instead of in this driver. With this new approach, the driver doesn't have to bother with error handling (allocation failure checking, making sure free happens in the right spot, etc). This is core responsibility now. Remove the allocation in the loopback driver and leverage the network core allocation instead. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/20240429085559.2841918-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-05-01spi: use spi_valid_{tx,rx}buf() in stats functionDavid Lechner
There are macros spi_valid_txbuf() and spi_valid_rxbuf() for determining if an xfer actually intended to send or receive data. These checks were hard-coded in spi_statistics_add_transfer_stats(). We can make use of the macros instead to make the code more readable and more robust against potential future changes in case the definition of what valid means changes. The macro takes the spi_message as an argument, so we need to change spi_statistics_add_transfer_stats() to take the spi_message as an argument instead of the controller. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240430201530.2138095-3-dlechner@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-30drm/amdgpu: fix doorbell regressionShashank Sharma
This patch adds a missed handling of PL domain doorbell while handling VRAM faults. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Fixes: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults") Reviewed-by: Christian Koenig <christian.koenig@amd.com> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Arvind Yadav <arvind.yadav@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amdkfd: Flush the process wq before creating a kfd_processLancelot SIX
There is a race condition when re-creating a kfd_process for a process. This has been observed when a process under the debugger executes exec(3). In this scenario: - The process executes exec. - This will eventually release the process's mm, which will cause the kfd_process object associated with the process to be freed (kfd_process_free_notifier decrements the reference count to the kfd_process to 0). This causes kfd_process_ref_release to enqueue kfd_process_wq_release to the kfd_process_wq. - The debugger receives the PTRACE_EVENT_EXEC notification, and tries to re-enable AMDGPU traps (KFD_IOC_DBG_TRAP_ENABLE). - When handling this request, KFD tries to re-create a kfd_process. This eventually calls kfd_create_process and kobject_init_and_add. At this point the call to kobject_init_and_add can fail because the old kfd_process.kobj has not been freed yet by kfd_process_wq_release. This patch proposes to avoid this race by making sure to drain kfd_process_wq before creating a new kfd_process object. This way, we know that any cleanup task is done executing when we reach kobject_init_and_add. Signed-off-by: Lancelot SIX <lancelot.six@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Disable seamless boot on 128b/132b encodingSung Joon Kim
[why] preOS will not support display mode programming and link training for UHBR rates. [how] If we detect a sink that's UHBR capable, disable seamless boot Reviewed-by: Anthony Koo <anthony.koo@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Sung Joon Kim <sungjoon.kim@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Fix DC mode screen flickering on DCN321Leo Ma
[Why && How] Screen flickering saw on 4K@60 eDP with high refresh rate external monitor when booting up in DC mode. DC Mode Capping is disabled which caused wrong UCLK being used. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Leo Ma <hanghong.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Add VCO speed parameter for DCN31 FPURodrigo Siqueira
Add VCO speed parameters in the bounding box array. Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30e1000e: change usleep_range to udelay in PHY mdic accessVitaly Lifshits
This is a partial revert of commit 6dbdd4de0362 ("e1000e: Workaround for sporadic MDI error on Meteor Lake systems"). The referenced commit used usleep_range inside the PHY access routines, which are sometimes called from an atomic context. This can lead to a kernel panic in some scenarios, such as cable disconnection and reconnection on vPro systems. Solve this by changing the usleep_range calls back to udelay. Fixes: 6dbdd4de0362 ("e1000e: Workaround for sporadic MDI error on Meteor Lake systems") Cc: stable@vger.kernel.org Reported-by: Jérôme Carretero <cJ@zougloub.eu> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218740 Closes: https://lore.kernel.org/lkml/a7eb665c74b5efb5140e6979759ed243072cb24a.camel@zougloub.eu/ Co-developed-by: Sasha Neftin <sasha.neftin@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Signed-off-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Tested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240429171040.1152516-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-30drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2Christian König
This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap. The basic problem here is that after the move the old location is simply not available any more. Some fixes were suggested, but essentially we should call the move notification before actually moving things because only this way we have the correct order for DMA-buf and VM move notifications as well. Also rework the statistic handling so that we don't update the eviction counter before the move. v2: add missing NULL check Signed-off-by: Christian König <christian.koenig@amd.com> Fixes: 94aeb4117343 ("drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3171 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> CC: stable@vger.kernel.org
2024-04-30drm/amd/display: Allocate zero bw after bw alloc enableMeenakshikumar Somasundaram
[Why] During DP tunnel creation, CM preallocates BW and reduces estimated BW of other DPIA. CM release preallocation only when allocation is complete. Display mode validation logic validates timings based on bw available per host router. In multi display setup, this causes bw allocation failure when allocation greater than estimated bw. [How] Do zero alloc to make the CM to release preallocation and update estimated BW correctly for all DPIAs per host router. Reviewed-by: PeiChen Huang <peichen.huang@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Fix incorrect DSC instance for MSTHersen Wu
[Why] DSC debugfs, such as dp_dsc_clock_en_read, use aconnector->dc_link to find pipe_ctx for display. Displays connected to MST hub share the same dc_link. DSC instance is from pipe_ctx. This causes incorrect DSC instance for display connected to MST hub. [How] Add aconnector->sink check to find pipe_ctx. CC: stable@vger.kernel.org Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Atom Integrated System Info v2_2 for DCN35Gabe Teeger
New request from KMD/VBIOS in order to support new UMA carveout model. This fixes a null dereference from accessing Ctx->dc_bios->integrated_info while it was NULL. DAL parses through the BIOS and extracts the necessary integrated_info but was missing a case for the new BIOS version 2.3. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Gabe Teeger <gabe.teeger@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30net: dsa: mv88e6xxx: Fix number of databases for 88E6141 / 88E6341Marek Behún
The Topaz family (88E6141 and 88E6341) only support 256 Forwarding Information Tables. Fixes: a75961d0ebfd ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341") Fixes: 1558727a1c1b ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240429133832.9547-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-30inet: introduce dst_rtable() helperEric Dumazet
I added dst_rt6_info() in commit e8dfd42c17fa ("ipv6: introduce dst_rt6_info() helper") This patch does a similar change for IPv4. Instead of (struct rtable *)dst casts, we can use : #define dst_rtable(_ptr) \ container_of_const(_ptr, struct rtable, dst) Patch is smaller than IPv6 one, because IPv4 has skb_rtable() helper. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/20240429133009.1227754-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-30drm/amd/display: Add dtbclk access to dcn315Swapnil Patel
[Why & How] Currently DCN315 clk manager is missing code to enable/disable dtbclk. Because of this, "optimized_required" flag is constantly set and this prevents FreeSync from engaging for certain high bandwidth display Modes which require DTBCLK. Reviewed-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Swapnil Patel <swapnil.patel@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30cxgb4: Properly lock TX queue for the selftest.Sebastian Andrzej Siewior
The selftest for the driver sends a dummy packet and checks if the packet will be received properly as it should be. The regular TX path and the selftest can use the same network queue so locking is required and was missing in the selftest path. This was addressed in the commit cited below. Unfortunately locking the TX queue requires BH to be disabled which is not the case in selftest path which is invoked in process context. Lockdep should be complaining about this. Use __netif_tx_lock_bh() for TX queue locking. Fixes: c650e04898072 ("cxgb4: Fix race between loopback and normal Tx path") Reported-by: "John B. Wyatt IV" <jwyatt@redhat.com> Closes: https://lore.kernel.org/all/Zic0ot5aGgR-V4Ks@thinkpad2021/ Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20240429091147.YWAaal4v@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-30drm/amd/display: Ensure that dmcub support flag is set for DCN20Rodrigo Siqueira
In the DCN20 resource initialization, ensure that DMCUB support starts configured as true. Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amd/display: Handle Y carry-over in VCP X.Y calculationGeorge Shen
Theoretically rare corner case where ceil(Y) results in rounding up to an integer. If this happens, the 1 should be carried over to the X value. CC: stable@vger.kernel.org Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: George Shen <george.shen@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30drm/amdgpu: Fix VRAM memory accountingMukul Joshi
Subtract the VRAM pinned memory when checking for available memory in amdgpu_amdkfd_reserve_mem_limit function since that memory is not available for use. Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-30mailbox: zynqmp: Enable Bufferless IPI usage on Versal-based SOC'sBen Levinsky
On Xilinx-AMD Versal and Versal-NET, there exist both inter-processor-interrupts with corresponding message buffers and without such buffers. Add a routine that, if the corresponding DT compatible string "xlnx,versal-ipi-mailbox" is used then a Versal-based SOC can use a mailbox Device Tree entry where both host and remote can use either of the buffered or bufferless interrupts. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-04-30mailbox: zynqmp: Move buffered IPI setup to of_match selected routineBen Levinsky
Move routine that initializes the mailboxes for send and receive to a function pointer that is set based on compatible string. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-04-30mailbox: zynqmp: Move of_match structure closer to usageBen Levinsky
The of_match structure zynqmp_ipi_of_match is now adjacent to where it used in the zynqmp_ipi_driver structure for readability. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
2024-04-30ublk: remove segment count and size limitsUday Shankar
ublk_drv currently creates block devices with the default max_segments and max_segment_size limits of BLK_MAX_SEGMENTS (128) and BLK_MAX_SEGMENT_SIZE (65536) respectively. These defaults can artificially constrain the I/O size seen by the ublk server - for example, suppose that the ublk server has configured itself to accept I/Os up to 1M and the application is also issuing 1M sized I/Os. If the I/O buffer used by the application is backed by 4K pages, the buffer could consist of up to 1M / 4K = 256 physically discontiguous segments (even if the buffer is virtually contiguous). As such, the I/O could exceed the default max_segments limit and get split. This can cause unnecessary performance issues if the ublk server is optimized to handle 1M I/Os. The block layer's segment count/size limits exist to model hardware constraints which don't exist in ublk_drv's case, so just remove those limits for the block devices created by ublk_drv. Signed-off-by: Uday Shankar <ushankar@purestorage.com> Reviewed-by: Riley Thomasson <riley@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20240430211623.2802036-1-ushankar@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-04-30clk: samsung: Revert "clk: Use device_get_match_data()"Marek Szyprowski
device_get_match_data() function should not be used on the device other than the one matched to the given driver, because it always returns the match_data of the matched driver. In case of exynos-clkout driver, the original code matches the OF IDs on the PARENT device, so replacing it with of_device_get_match_data() broke the driver. This has been already pointed once in commit 2bc5febd05ab ("clk: samsung: Revert "clk: samsung: exynos-clkout: Use of_device_get_match_data()""). To avoid further confusion, add a comment about this special case, which requires direct of_match_device() call to pass custom IDs array. This partially reverts commit 409c39ec92a35e3708f5b5798c78eae78512cd71. Cc: <stable@vger.kernel.org> Fixes: 409c39ec92a3 ("clk: Use device_get_match_data()") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20240425075628.838497-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240430184656.357805-1-krzysztof.kozlowski@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-04-30cxl/region: Fix cxlr_pmem leaksLi Zhijian
Before this error path, cxlr_pmem pointed to a kzalloc() memory, free it to avoid this memory leaking. Fixes: f17b558d6663 ("cxl/pmem: Refactor nvdimm device registration, delete the workqueue") Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240428030748.318985-1-lizhijian@fujitsu.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2024-04-30Input: ff-core - prefer struct_size over open coded arithmeticErick Archer
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "ff" variable is a pointer to "struct ff_device" and this structure ends in a flexible array: struct ff_device { [...] struct file *effect_owners[] __counted_by(max_effects); }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + count * size" in the kzalloc() function. The struct_size() helper returns SIZE_MAX on overflow. So, refactor the comparison to take advantage of this. This way, the code is more readable and safer. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by: Erick Archer <erick.archer@outlook.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/AS8PR02MB72371E646714BAE2E51A6A378B152@AS8PR02MB7237.eurprd02.prod.outlook.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2024-04-30Merge remote-tracking branch 'cxl/for-6.10/dpa-to-hpa' into cxl-for-nextDave Jiang
Support for HPA to DPA translation for CXL events cxl_dram and cxl_general_media.
2024-04-30ACPI: scan: Avoid enumerating devices with clearly invalid _STA valuesRafael J. Wysocki
The return value of _STA with the "present" bit unset and the "enabled" bit set is clearly invalid as per the ACPI specification, Section 6.3.7 "_STA (Device Status)", so make the ACPI device enumeration code disregard devices with such _STA return values. Also, because this implies that status.enabled will only be set if status.present is set too, acpi_device_is_enabled() can be modified to simply return the value of the former. Link: https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#sta-device-status Link: https://lore.kernel.org/linux-acpi/88179311a503493099028c12ca37d430@huawei.com/ Suggested-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
generated by cgit (git 2.34.1) at 2025-09-23 12:03:50 +0000