summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-04-21firmware: qcom: scm: Remove log reporting memory allocation failureMukesh Ojha
Remove redundant memory allocation failure. WARNING: Possible unnecessary 'out of memory' message + if (!mdata_buf) { + dev_err(__scm->dev, "Allocation of metadata buffer failed.\n"); Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/1711034642-22860-1-git-send-email-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-04-21soc: qcom: pmic_glink: notify clients about the current stateDmitry Baryshkov
In case the client is registered after the pmic-glink recived a response from the Protection Domain mapper, it is going to miss the notification about the state. Notify clients about the current state upon registration. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Tested-by: Xilin Wu <wuxilin123@gmail.com> # on QCS8550 AYN Odin 2 Link: https://lore.kernel.org/r/20240403-pmic-glink-fix-clients-v2-2-aed4e02baacc@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-04-21soc: qcom: pmic_glink: don't traverse clients list without a lockDmitry Baryshkov
Take the client_lock before traversing the clients list at the pmic_glink_state_notify_clients() function. This is required to keep the list traversal safe from concurrent modification. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Tested-by: Xilin Wu <wuxilin123@gmail.com> # on QCS8550 AYN Odin 2 Link: https://lore.kernel.org/r/20240403-pmic-glink-fix-clients-v2-1-aed4e02baacc@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-04-21soc: qcom: mention intentionally broken module autoloadingKrzysztof Kozlowski
Qualcomm PMIC ChargerPD ULOG and RPM Master Statistics drivers are solely for debugging purposes and should not be autoloaded as modules. Add comments to annotate missing MODULE_DEVICE_TABLE. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20240410184522.271889-1-krzk@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-04-21IB/core: Implement a limit on UMAD receive ListMichael Guralnik
The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Reviewed-by: Mark Zhang <markzhang@nvidia.com> Link: https://lore.kernel.org/r/7197cb58a7d9e78399008f25036205ceab07fbd5.1713268818.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-04-20clk: qcom: rpm: Remove an unused field in struct rpm_ccChristophe JAILLET
In "struct rpm_cc", the 'rpm' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/9f92330c717e6f2dab27b1307565ffb108c304a7.1713017032.git.christophe.jaillet@wanadoo.fr Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-04-20Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "A couple clk driver fixes, a build fix, and a deadlock fix: - Mediatek mt7988 has broken PCIe because the wrong parent is used - Mediatek clk drivers may deadlock when registering their clks because the clk provider device is repeatedly runtime PM resumed and suspended during probe and clk registration. Resuming the clk provider device deadlocks with an ABBA deadlock due to genpd_lock and the clk prepare_lock. The fix is to keep the device runtime resumed while registering clks. - Another runtime PM related deadlock, this time with disabling unused clks during late init. We get an ABBA deadlock where a device is runtime PM resuming (or suspending) while the disabling of unused clks is happening in parallel. That runtime PM action calls into the clk framework and tries to grab the clk prepare_lock while the disabling of unused clks holds the prepare_lock and is waiting for that runtime PM action to complete. The fix is to runtime resume all the clk provider devices before grabbing the clk prepare_lock during disable unused. - A build fix to provide an empty devm_clk_rate_exclusive_get() function when CONFIG_COMMON_CLK=n" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: mediatek: mt7988-infracfg: fix clocks for 2nd PCIe port clk: mediatek: Do a runtime PM get on controllers during probe clk: Get runtime PM before walking tree for clk_summary clk: Get runtime PM before walking tree during disable_unused clk: Initialize struct clk_core kref earlier clk: Don't hold prepare_lock when calling kref_put() clk: Remove prepare_lock hold assertion in __clk_release() clk: Provide !COMMON_CLK dummy for devm_clk_rate_exclusive_get()
2024-04-20clk: qcom: clk-alpha-pll: Skip reconfiguring the running Lucid EvoAbel Vesa
The PLL0 is configured by the bootloader and is the parent of the mdp_clk_src. The Trion implementation of the configure function is already skipping this step if the PLL is enabled, so lets extend the same behavior to Lucid Evo variant. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20240418-clk-qcom-lucid-evo-skip-configuring-enabled-v1-1-caede5f1c7a3@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-04-20iio: adc: adi-axi-adc: only error out in major version mismatchNuno Sa
The IP core only has breaking changes when there major version changes. Hence, only match the major number. This is also in line with the other core ADI has upstream. The current check for erroring out 'expected_version > current_version"' is then wrong as we could just increase the core major with breaking changes and that would go unnoticed. Fixes: ef04070692a2 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-ad9467-new-features-v1-2-3e7628ff6d5e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20scsi: hpsa: Fix allocation size for Scsi_Host private dataYuri Karpov
struct Scsi_Host private data contains pointer to struct ctlr_info. Restore allocation of only 8 bytes to store pointer in struct Scsi_Host private data area. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bbbd25499100 ("scsi: hpsa: Fix allocation size for scsi_host_alloc()") Signed-off-by: Yuri Karpov <YKarpov@ispras.ru> Link: https://lore.kernel.org/r/20240312170447.743709-1-YKarpov@ispras.ru Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2024-04-20iio: dac: support the ad9739a RF DACNuno Sa
The AD9739A is a 14-bit, 2.5 GSPS high performance RF DACs that are capable of synthesizing wideband signals from DC up to 3 GHz. A dual-port, source synchronous, LVDS interface simplifies the digital interface with existing FGPA/ASIC technology. On-chip controllers are used to manage external and internal clock domain variations over temperature to ensure reliable data transfer from the host to the DAC core. Co-developed-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-10-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: dac: add support for AXI DAC IP coreNuno Sa
Support the Analog Devices Generic AXI DAC IP core. The IP core is used for interfacing with digital-to-analog (DAC) converters that require either a high-speed serial interface (JESD204B/C) or a source synchronous parallel interface (LVDS/CMOS). Typically (for such devices) SPI will be used for configuration only, while this IP core handles the streaming of data into memory via DMA. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-9-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: backend: add new functionalityNuno Sa
This adds the needed backend ops for supporting a backend inerfacing with an high speed dac. The new ops are: * data_source_set(); * set_sampling_freq(); * extend_chan_spec(); * ext_info_set(); * ext_info_get(). Also to note the new helpers that are meant to be used by the backends when extending an IIO channel (adding extended info): * iio_backend_ext_info_set(); * iio_backend_ext_info_get(). Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-8-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: buffer-dmaengine: Enable write supportPaul Cercueil
Use the iio_dma_buffer_write() and iio_dma_buffer_space_available() functions provided by the buffer-dma core, to enable write support in the buffer-dmaengine code. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-5-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: buffer-dmaengine: Support specifying buffer directionPaul Cercueil
Update the devm_iio_dmaengine_buffer_setup() function to support specifying the buffer direction. Update the iio_dmaengine_buffer_submit() function to handle input buffers as well as output buffers. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-4-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20Merge patch series "scsi: libsas: Fix the failure of adding phy with ↵Martin K. Petersen
zero-address to new port" Xingui Yang <yangxingui@huawei.com> says: This series is to solve the problem of a BUG() when adding phy with zero address to a new port. Link: https://lore.kernel.org/r/20240312141103.31358-1-yangxingui@huawei.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2024-04-20scsi: libsas: Fix the failure of adding phy with zero-address to portXingui Yang
As of commit 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions"), reset the phy->entacted_sas_addr address to a zero-address when the link rate is less than 1.5G. Currently we find that when a new device is attached, and the link rate is less than 1.5G, but the device type is not NO_DEVICE, for example: the link rate is SAS_PHY_RESET_IN_PROGRESS and the device type is stp. After setting the phy->entacted_sas_addr address to the zero address, the port will continue to be created for the phy with the zero-address, and other phys with the zero-address will be tried to be added to the new port: [562240.051197] sas: ex 500e004aaaaaaa1f phy19:U:0 attached: 0000000000000000 (no device) // phy19 is deleted but still on the parent port's phy_list [562240.062536] sas: ex 500e004aaaaaaa1f phy0 new device attached [562240.062616] sas: ex 500e004aaaaaaa1f phy00:U:5 attached: 0000000000000000 (stp) [562240.062680] port-7:7:0: trying to add phy phy-7:7:19 fails: it's already part of another port Therefore, it should be the same as sas_get_phy_attached_dev(). Only when device_type is SAS_PHY_UNUSED, sas_address is set to the 0 address. Fixes: 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions") Signed-off-by: Xingui Yang <yangxingui@huawei.com> Link: https://lore.kernel.org/r/20240312141103.31358-5-yangxingui@huawei.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2024-04-20scsi: libsas: Set port when ex_phy is added or deletedXingui Yang
We found that when ex_phy was attached and added to the parent wide port, ex_phy->port was not set, resulting in sas_unregister_devs_sas_addr() not calling sas_port_delete_phy() when deleting the phy, and the deleted phy was still on the parent wide port's phy_list. When we use sas_port_add_ex_phy() to set ex_phy->port to solve the above problem, we find that after all the phys of the parent_port are removed and the number of phy becomes 0, the parent_port will not be set to NULL. This causes the freed parent port to be used when attaching a new ex_phy in sas_ex_add_parent_port(). Use sas_port_add_ex_phy() instead of sas_port_add_phy() to set ex_phy->port when ex_phy is added to the parent port, and set ex_dev->parent_port to NULL when the number of phy on the port becomes 0. Signed-off-by: Xingui Yang <yangxingui@huawei.com> Link: https://lore.kernel.org/r/20240312141103.31358-4-yangxingui@huawei.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2024-04-20scsi: libsas: Move sas_add_parent_port() to sas_expander.cXingui Yang
Move sas_add_parent_port() to sas_expander.c and rename it to sas_ex_add_parent_port() as it is only used in this file. Signed-off-by: Xingui Yang <yangxingui@huawei.com> Link: https://lore.kernel.org/r/20240312141103.31358-3-yangxingui@huawei.com Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2024-04-20scsi: libsas: Add helper for port add ex_phyXingui Yang
This moves the process of adding ex_phy to a port into a new helper. Signed-off-by: Xingui Yang <yangxingui@huawei.com> Link: https://lore.kernel.org/r/20240312141103.31358-2-yangxingui@huawei.com Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2024-04-20iio: buffer-dma: Enable buffer write supportPaul Cercueil
Adding write support to the buffer-dma code is easy - the write() function basically needs to do the exact same thing as the read() function: dequeue a block, read or write the data, enqueue the block when entirely processed. Therefore, the iio_buffer_dma_read() and the new iio_buffer_dma_write() now both call a function iio_buffer_dma_io(), which will perform this task. Note that we preemptively reset block->bytes_used to the buffer's size in iio_dma_buffer_request_update(), as in the future the iio_dma_buffer_enqueue() function won't reset it. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-3-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: buffer-dma: Rename iio_dma_buffer_data_available()Paul Cercueil
Change its name to iio_dma_buffer_usage(), as this function can be used both for the .data_available and the .space_available callbacks. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-2-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: buffer-dma: add iio_dmaengine_buffer_setup()Nuno Sa
This brings the DMA buffer API more in line with what we have in the triggered buffer. There's no need of having both devm_iio_dmaengine_buffer_setup() and devm_iio_dmaengine_buffer_alloc(). Hence we introduce the new iio_dmaengine_buffer_setup() that together with devm_iio_dmaengine_buffer_setup() should be all we need. Note that as part of this change iio_dmaengine_buffer_alloc() is again static and the axi-adc was updated accordingly. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240419-iio-backend-axi-dac-v4-1-5ca45b4de294@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: pressure: dps310: simplify scale factor readingThomas Haemmerle
Both functions `dps310_get_pres_precision` and `dps310_get_temp_precision` provide the oversampling rate by calling the `BIT()` macro. However, to look up the corresponding scale factor, we need the register value itself. Currently, this is achieved by undoing the calculation of the oversampling rate with `ilog2()`. Simplify the two functions for getting the scale factor and directly use the register content for the lookup. Signed-off-by: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com> Link: https://lore.kernel.org/r/20240415105030.1161770-5-thomas.haemmerle@leica-geosystems.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: pressure: dps310: consistently check return value of `regmap_read`Thomas Haemmerle
Align the check of return values `regmap_read` so that it's consistent across this driver code. Signed-off-by: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com> Link: https://lore.kernel.org/r/20240415105030.1161770-4-thomas.haemmerle@leica-geosystems.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: pressure: dps310: introduce consistent error handlingThomas Haemmerle
Align error handling with `dps310_calculate_temp`, where it's not possible to differentiate between errors and valid calculations by checking if the returned value is negative. Signed-off-by: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com> Link: https://lore.kernel.org/r/20240415105030.1161770-3-thomas.haemmerle@leica-geosystems.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20iio: pressure: dps310: support negative temperature valuesThomas Haemmerle
The current implementation interprets negative values returned from `dps310_calculate_temp` as error codes. This has a side effect that when negative temperature values are calculated, they are interpreted as error. Fix this by using the return value only for error handling and passing a pointer for the value. Fixes: ba6ec48e76bc ("iio: Add driver for Infineon DPS310") Signed-off-by: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com> Link: https://lore.kernel.org/r/20240415105030.1161770-2-thomas.haemmerle@leica-geosystems.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-04-20serial: msm: check dma_map_sg() return value properlyJiri Slaby (SUSE)
The -next commit f8fef2fa419f (tty: msm_serial: use dmaengine_prep_slave_sg()), switched to using dma_map_sg(). But the return value of dma_map_sg() is special: it returns number of elements mapped. And not a standard error value. The commit also forgot to reset dma->tx_sg in case of this failure. Fix both these mistakes. Thanks to Marek who helped debugging this. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20240419080931.30949-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-19mlxsw: pci: Fix driver initialization with old firmwareIdo Schimmel
The driver queries the Management Capabilities Mask (MCAM) register during initialization to understand if a new and deeper reset flow is supported. However, not all firmware versions support this register, leading to the driver failing to load. Fix by treating an error in the register query as an indication that the feature is not supported. Fixes: f257c73e5356 ("mlxsw: pci: Add support for new reset flow") Reported-by: Tim 'mithro' Ansell <me@mith.ro> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/ee968c49d53bac96a4c66d1b09ebbd097d81aca5.1713446092.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-19mlxsw: core_env: Fix driver initialization with old firmwareIdo Schimmel
The driver queries the Management Capabilities Mask (MCAM) register during initialization to understand if it can read up to 128 bytes from transceiver modules. However, not all firmware versions support this register, leading to the driver failing to load. Fix by treating an error in the register query as an indication that the feature is not supported. Fixes: 1f4aea1f72da ("mlxsw: core_env: Read transceiver module EEPROM in 128 bytes chunks") Reported-by: Tim 'mithro' Ansell <me@mith.ro> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/0afa8b2e8bac178f5f88211344429176dcc72281.1713446092.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-19mlxsw: core: Unregister EMAD trap using FORWARD actionIdo Schimmel
The device's manual (PRM - Programmer's Reference Manual) classifies the trap that is used to deliver EMAD responses as an "event trap". Among other things, it means that the only actions that can be associated with the trap are TRAP and FORWARD (NOP). Currently, during driver de-initialization the driver unregisters the trap by setting its action to DISCARD, which violates the above guideline. Future firmware versions will prevent such misuses by returning an error. This does not prevent the driver from working, but an error will be printed to the kernel log during module removal / devlink reload: mlxsw_spectrum 0000:03:00.0: Reg cmd access status failed (status=7(bad parameter)) mlxsw_spectrum 0000:03:00.0: Reg cmd access failed (reg_id=7003(hpkt),type=write) Suppress the error message by aligning the driver to the manual and use a FORWARD (NOP) action when unregistering the trap. Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events") Cc: Jiri Pirko <jiri@resnulli.us> Cc: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/753a89e14008fde08cb4a2c1e5f537b81d8eb2d6.1713446092.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-19net: bcmasp: fix memory leak when bringing down interfaceJustin Chen
When bringing down the TX rings we flush the rings but forget to reclaimed the flushed packets. This leads to a memory leak since we do not free the dma mapped buffers. This also leads to tx control block corruption when bringing down the interface for power management. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240418180541.2271719-1-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-19clk: rs9: fix wrong default value for clock amplitudeCatalin Popescu
According to 9FGV0241, 9FGV0441 & 9FGV0841 datasheets, the default value for the clock amplitude is 0.8V, while the driver assumes 0.7V. Additionally, define constants for default values for both clock amplitude and spread spectrum and use them. Fixes: 892e0ddea1aa ("clk: rs9: Add Renesas 9-series PCIe clock generator driver") Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Reviewed-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20240415140348.2887619-1-catalin.popescu@leica-geosystems.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-04-19clk: gemini: Remove an unused field in struct clk_gemini_pciChristophe JAILLET
In "struct clk_gemini_pci", the 'rate' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/556770c7701868f9f1c0569674903bee3eff30cb.1713015940.git.christophe.jaillet@wanadoo.fr Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-04-19clk: highbank: Remove an unused field in struct hb_clkChristophe JAILLET
In "struct hb_clk", the 'parent_name' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/90b19f2af3077075d4254e01d5ae919c423d067e.1713016457.git.christophe.jaillet@wanadoo.fr Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-04-19clk: mediatek: mt8365-mm: fix DPI0 parentAlexandre Mergnat
To have a working display through DPI, a workaround has been implemented downstream to add "mm_dpi0_dpi0" and "dpi0_sel" to the DPI node. Shortly, that add an extra clock. It seems consistent to have the "dpi0_sel" as parent. Additionnaly, "vpll_dpix" isn't used/managed. Then, set the "mm_dpi0_dpi0" parent clock to "dpi0_sel". The new clock tree is: clk26m lvdspll lvdspll_X (2, 4, 8, 16) dpi0_sel mm_dpi0_dpi0 Fixes: d46adccb7966 ("clk: mediatek: add driver for MT8365 SoC") Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20231023-display-support-v3-12-53388f3ed34b@baylibre.com Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-04-19clk: sophgo: avoid open-coded 64-bit divisionArnd Bergmann
On 32-bit architectures, the 64-bit division leads to a link failure: arm-linux-gnueabi-ld: drivers/clk/sophgo/clk-cv18xx-pll.o: in function `fpll_calc_rate': clk-cv18xx-pll.c:(.text.fpll_calc_rate+0x26): undefined reference to `__aeabi_uldivmod' This one is not called in a fast path, and there is already another div_u64() variant used in the same function, so convert it to div64_u64_rem(). Fixes: 80fd61ec4612 ("clk: sophgo: Add clock support for CV1800 SoC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240415134532.3467817-1-arnd@kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404122344.d5pb2N1I-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202404140310.QEjZKtTN-lkp@intel.com/ Reviewed-by: Inochi Amaoto <inochiama@outlook.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-04-19Merge tag 'for-linus-iommufd' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd Pull iommufd fixes from Jason Gunthorpe: "Two fixes for the selftests: - CONFIG_IOMMUFD_TEST needs CONFIG_IOMMUFD_DRIVER to work - The kconfig fragment sshould include fault injection so the fault injection test can work" * tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd: iommufd: Add config needed for iommufd_fail_nth iommufd: Add missing IOMMUFD_DRIVER kconfig for the selftest
2024-04-19Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds
Pull rdma fixes from Jason Gunthorpe: - Add a missing mutex_destroy() in rxe - Enhance the debugging print for cm_destroy failures to help debug these - Fix mlx5 MAD processing in cases where multiport devices are running in switchedev mode * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: RDMA/mlx5: Fix port number for counter query in multi-port configuration RDMA/cm: Print the old state when cm_destroy_id gets timeout RDMA/rxe: Fix the problem "mutex_destroy missing"
2024-04-19thermal: core: Introduce .trip_crossed() callback for thermal governorsRafael J. Wysocki
Introduce a new thermal governor callback called .trip_crossed() that will be invoked whenever a trip point is crossed by the zone temperature, either on the way up or on the way down. The trip crossing direction information will be passed to it and if multiple trips are crossed in the same direction during one thermal zone update, the new callback will be invoked for them in temperature order, either ascending or descending, depending on the trip crossing direction. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
2024-04-19Merge tag 's390-6.9-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 updates from Alexander Gordeev: - Fix NULL pointer dereference in program check handler - Fake IRBs are important events relevant for problem analysis. Add traces when queueing and delivering - Fix a race condition in ccw_device_set_online() that can cause the online process to fail - Deferred condition code 1 response indicates that I/O was not started and should be retried. The current QDIO implementation handles a cc1 response as an error, resulting in a failed QDIO setup. Fix that by retrying the setup when a cc1 response is received * tag 's390-6.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/mm: Fix NULL pointer dereference s390/cio: log fake IRB events s390/cio: fix race condition during online processing s390/qdio: handle deferred cc1
2024-04-19drm/i915: Enable per-lane DP drive settings for bxt/glkVille Syrjälä
Now the bxt/glk PHY code is ready for per-lane drive settings so enable it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-19drm/i915/dpio: Program bxt/glk PHY TX registers per-laneVille Syrjälä
Program each bxt/glk PHY TX lane with its own settings instead of blasting them all with the same stuff via group access. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-19drm/i915/dpio: s/ddi/dpio/ for bxt/glk PHY stuffVille Syrjälä
Since all of this lives in intel_dpio_phy.c let's rename the bxt/glk functions to have bxt_dpio_phy_ namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-19drm/i915/dpio: Use intel_de_rmw() for BXT DPIO latency optim setupVille Syrjälä
Replace the hand rolled intel_de_rmw() with the real thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-19drm/i915/dpio: Introdude bxt_ddi_phy_rmw_grp()Ville Syrjälä
Add a helper to do the "read from one per-lane register and write to the group register" rmw cycle. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-19drm/i915/dpio: Extract bxt_dpio_phy_regs.hVille Syrjälä
Extract the BXT/GLK DPIO PHY register definitions into their own file. v2: Adjust gvt accordingly Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417151232.32175-1-ville.syrjala@linux.intel.com
2024-04-19drm/i915/dpio: Add per-lane PHY TX register definitons for bxt/glkVille Syrjälä
Add consistent definitions for the per-lane PHY TX registers on bxt/glk. The current situation is a slight mess with some registers having a LN0 define, while others have a parametrized per-lane definition. v2: Adjust gvt accordingly Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417151211.32135-1-ville.syrjala@linux.intel.com
2024-04-19drm/i915/dpio: Clean up bxt/glk PHY registersVille Syrjälä
Use REG_BIT() & co. for the bxt/glk PHY register definitons. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-19Merge tag 'thermal-6.9-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fix from Rafael Wysocki: "This prevents the thermal debug code from attempting to divide by zero and corrects trip point statistics (Rafael Wysocki)" * tag 'thermal-6.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal/debugfs: Add missing count increment to thermal_debug_tz_trip_up()
generated by cgit (git 2.34.1) at 2025-10-03 08:58:51 +0000