summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-05-13scsi: ufs: core: Support updating device command timeoutPeter Wang1-7/+28
The default device command timeout remains 1.5 seconds, but platform drivers can override it if needed. Some UFS device commands may timeout due to being blocked by regular SCSI write commands. Therefore, the maximum timeout needs to be extended to 30 seconds, matching the SCSI write command timeout. And for error injection purposes, set the minimum value to 1 ms. Signed-off-by: Peter Wang <peter.wang@mediatek.com> Link: https://lore.kernel.org/r/20250510080345.595798-1-peter.wang@mediatek.com Suggested-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: ufs: core: Change hwq_id type and valuePeter Wang1-1/+1
Change the type of hwq_id to u32 because the member id of struct ufs_hw_queue is u32 (hwq->id) and the trace entry hwq_id is also u32. Set hwq_id to 0 if MCQ is not supported, as SDB mode only supports one hardware queue. Signed-off-by: Peter Wang <peter.wang@mediatek.com> Link: https://lore.kernel.org/r/20250509021648.412098-1-peter.wang@mediatek.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: sd_zbc: block: Respect bio vector limits for REPORT ZONES bufferSteve Siwinski1-1/+5
The REPORT ZONES buffer size is currently limited by the HBA's maximum segment count to ensure the buffer can be mapped. However, the block layer further limits the number of iovec entries to 1024 when allocating a bio. To avoid allocation of buffers too large to be mapped, further restrict the maximum buffer size to BIO_MAX_INLINE_VECS. Replace the UIO_MAXIOV symbolic name with the more contextually appropriate BIO_MAX_INLINE_VECS. Fixes: b091ac616846 ("sd_zbc: Fix report zones buffer allocation") Cc: stable@vger.kernel.org Signed-off-by: Steve Siwinski <ssiwinski@atto.com> Link: https://lore.kernel.org/r/20250508200122.243129-1-ssiwinski@atto.com Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: ufs: core: Increase the UIC command timeout furtherBart Van Assche1-2/+2
On my development board I observed that it can take a little longer than two seconds before UIC completions are processed if the UART is enabled. Hence this patch that increases the UIC command timeout upper limit further. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20250508165411.3755300-1-bvanassche@acm.org Reviewed-by: Peter Wang <peter.wang@mediatek.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: zfcp: Simplify workqueue allocationBenjamin Block1-8/+6
alloc_ordered_workqueue() accepts a format string and format arguments as part of the call, so there is no need for the indirection of first using snprintf() to print the name into an local array, and then passing that array to the allocation call. Also make the error-/non-error-case handling more canonical in that the error case is tested in the 'if' that follows the allocation call, and the default return value of the function is '0'. Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com> Reviewed-by: Steffen Maier <maier@linux.ibm.com> Reviewed-by: M Nikhil <nikh1092@linux.ibm.com> Reviewed-by: Nihar Panda <niharp@linux.ibm.com> Signed-off-by: Nihar Panda <niharp@linux.ibm.com> Link: https://lore.kernel.org/r/20250507042854.3607038-3-niharp@linux.ibm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: ufs: core: Print error value as hex format in ufshcd_err_handler()Wonkon Kim1-1/+1
It is better to print saved_err and saved_uic_err in hex format. Integer format is hard to decode. [ 1024.485428] [2: kworker/u20:13:28211] exynos-ufs 17100000.ufs: ufshcd_err_handler started; HBA state eh_fatal; powered 1; shutting down 0; saved_err = 131072; saved_uic_err = 0; force_reset = 0; link is broken Signed-off-by: Wonkon Kim <wkon.kim@samsung.com> Link: https://lore.kernel.org/r/20250512025210.5802-1-wkon.kim@samsung.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: sd: Remove the stream_status member from scsi_stream_status_headerChristoph Hellwig1-1/+1
Having a variable length array at the end of scsi_stream_status_header only causes problems. Remove it and switch sd_is_perm_stream(), which is the only place that currently uses it, to use the scsi_stream_status directly following it in the local buf structure. Besides being a much better data structure design, this also avoids a -Wflex-array-member-not-at-end warning. Reported-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250505060640.3398500-1-hch@lst.de Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: core: Remove unused scsi_dev_info_list_del_keyed()Dr. David Alan Gilbert2-29/+0
The last use of scsi_dev_info_list_del_keyed() was removed by 2011's commit 2b132577a05e ("[SCSI] scsi_dh: code cleanup and remove the references to scsi_dev_info") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250503230743.124978-1-linux@treblig.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13scsi: isci: Remove unused sci_remote_device_reset()Dr. David Alan Gilbert2-45/+0
sci_remote_device_reset() last use was removed in 2012 by commit 14aaa9f0a318 ("isci: Redesign device suspension, abort, cleanup.") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250503230601.124794-1-linux@treblig.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-13net: dsa: b53: implement setting ageing timeJonas Gorski4-0/+37
b53 supported switches support configuring ageing time between 1 and 1,048,575 seconds, so add an appropriate setter. This allows b53 to pass the FDB learning test for both vlan aware and vlan unaware bridges. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250510092211.276541-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: mlx4: add SOF_TIMESTAMPING_TX_SOFTWARE flag when getting ts infoJason Xing1-0/+1
As mlx4 has implemented skb_tx_timestamp() in mlx4_en_xmit(), the SOFTWARE flag is surely needed when users are trying to get timestamp information. Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250510093442.79711-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13Merge branch 'for-next' of ↵Jakub Kicinski15-178/+313
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/linux Tony Nguyen says: ==================== Prepare for Intel IPU E2000 (GEN3) This is the first part in introducing RDMA support for idpf. ---------------------------------------------------------------- Tatyana Nikolova says: To align with review comments, the patch series introducing RDMA RoCEv2 support for the Intel Infrastructure Processing Unit (IPU) E2000 line of products is going to be submitted in three parts: 1. Modify ice to use specific and common IIDC definitions and pass a core device info to irdma. 2. Add RDMA support to idpf and modify idpf to use specific and common IIDC definitions and pass a core device info to irdma. 3. Add RDMA RoCEv2 support for the E2000 products, referred to as GEN3 to irdma. This first part is a 5 patch series based on the original "iidc/ice/irdma: Update IDC to support multiple consumers" patch to allow for multiple CORE PCI drivers, using the auxbus. Patches: 1) Move header file to new name for clarity and replace ice specific DSCP define with a kernel equivalent one in irdma 2) Unify naming convention 3) Separate header file into common and driver specific info 4) Replace ice specific DSCP define with a kernel equivalent one in ice 5) Implement core device info struct and update drivers to use it ---------------------------------------------------------------- v1: https://lore.kernel.org/20250505212037.2092288-1-anthony.l.nguyen@intel.com IWL reviews: [v5] https://lore.kernel.org/20250416021549.606-1-tatyana.e.nikolova@intel.com [v4] https://lore.kernel.org/20250225050428.2166-1-tatyana.e.nikolova@intel.com [v3] https://lore.kernel.org/20250207194931.1569-1-tatyana.e.nikolova@intel.com [v2] https://lore.kernel.org/20240824031924.421-1-tatyana.e.nikolova@intel.com [v1] https://lore.kernel.org/20240724233917.704-1-tatyana.e.nikolova@intel.com * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/linux: iidc/ice/irdma: Update IDC to support multiple consumers ice: Replace ice specific DSCP mapping num with a kernel define iidc/ice/irdma: Break iidc.h into two headers iidc/ice/irdma: Rename to iidc_* convention iidc/ice/irdma: Rename IDC header file ==================== Link: https://patch.msgid.link/20250509200712.2911060-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: vertexcom: mse102x: Simplify mse102x_rx_pkt_spiStefan Wahren1-22/+12
The function mse102x_rx_pkt_spi is used in two cases: * initial polling to re-arm RX interrupt * level based RX interrupt handler Both of them doesn't need an open-coded retry mechanism. In the first case the function can be called again, if the return code is IRQ_NONE. This keeps the error behavior during netdev open. In the second case the proper retry would be handled implicit by the SPI interrupt. So drop the retry code and simplify the receive path. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://patch.msgid.link/20250509120435.43646-7-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: vertexcom: mse102x: Return code for mse102x_rx_pkt_spiStefan Wahren1-6/+9
The MSE102x doesn't provide any interrupt register, so the only way to handle the level interrupt is to fetch the whole packet from the MSE102x internal buffer via SPI. So in cases the interrupt handler fails to do this, it should return IRQ_NONE. This allows the core to disable the interrupt in case the issue persists and prevent an interrupt storm. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://patch.msgid.link/20250509120435.43646-6-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: vertexcom: mse102x: Implement flag for valid CMDStefan Wahren1-4/+10
After removal of the invalid command counter only a relevant debug message is left, which can be cumbersome. So add a new flag to debugfs, which indicates whether the driver has ever received a valid CMD. This helps to differentiate between general and temporary receive issues. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250509120435.43646-5-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: vertexcom: mse102x: Drop invalid cmd statsStefan Wahren1-3/+0
There are several reasons for an invalid command response by the MSE102x: * SPI line interferences * MSE102x is in reset or has no firmware * MSE102x is busy * no packet in MSE102x receive buffer So the counter for invalid command isn't very helpful without further context. So drop the confusing statistics counter, but keep the debug messages about "unexpected response" in order to debug possible hardware issues. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250509120435.43646-4-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: vertexcom: mse102x: Add warning about IRQ trigger typeStefan Wahren1-0/+16
The example of the initial DT binding of the Vertexcom MSE 102x suggested a IRQ_TYPE_EDGE_RISING, which is wrong. So warn everyone to fix their device tree to level based IRQ. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250509120435.43646-3-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: dsa: sja1105: discard incoming frames in BR_STATE_LISTENINGVladimir Oltean1-5/+1
It has been reported that when under a bridge with stp_state=1, the logs get spammed with this message: [ 251.734607] fsl_dpaa2_eth dpni.5 eth0: Couldn't decode source port Further debugging shows the following info associated with packets: source_port=-1, switch_id=-1, vid=-1, vbid=1 In other words, they are data plane packets which are supposed to be decoded by dsa_tag_8021q_find_port_by_vbid(), but the latter (correctly) refuses to do so, because no switch port is currently in BR_STATE_LEARNING or BR_STATE_FORWARDING - so the packet is effectively unexpected. The error goes away after the port progresses to BR_STATE_LEARNING in 15 seconds (the default forward_time of the bridge), because then, dsa_tag_8021q_find_port_by_vbid() can correctly associate the data plane packets with a plausible bridge port in a plausible STP state. Re-reading IEEE 802.1D-1990, I see the following: "4.4.2 Learning: (...) The Forwarding Process shall discard received frames." IEEE 802.1D-2004 further clarifies: "DISABLED, BLOCKING, LISTENING, and BROKEN all correspond to the DISCARDING port state. While those dot1dStpPortStates serve to distinguish reasons for discarding frames, the operation of the Forwarding and Learning processes is the same for all of them. (...) LISTENING represents a port that the spanning tree algorithm has selected to be part of the active topology (computing a Root Port or Designated Port role) but is temporarily discarding frames to guard against loops or incorrect learning." Well, this is not what the driver does - instead it sets mac[port].ingress = true. To get rid of the log spam, prevent unexpected data plane packets to be received by software by discarding them on ingress in the LISTENING state. In terms of blame attribution: the prints only date back to commit d7f9787a763f ("net: dsa: tag_8021q: add support for imprecise RX based on the VBID"). However, the settings would permit a LISTENING port to forward to a FORWARDING port, and the standard suggests that's not OK. Fixes: 640f763f98c2 ("net: dsa: sja1105: Add support for Spanning Tree Protocol") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250509113816.2221992-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: phy: dp83867: use 2ns delay if not specified in DTBMatthias Schiffer1-40/+4
Most PHY drivers default to a 2ns delay if internal delay is requested and no value is specified. Having a default value makes sense, as it allows a Device Tree to only care about board design (whether there are delays on the PCB or not), and not whether the delay is added on the MAC or the PHY side when needed. Whether the delays are actually applied is controlled by the DP83867_RGMII_*_CLK_DELAY_EN flags, so the behavior is only changed in configurations that would previously be rejected with -EINVAL. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://patch.msgid.link/e2509b248a11ee29ea408a50c231da4c1fa0863b.1746612711.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: phy: dp83867: remove check of delay strap configurationMatthias Schiffer1-31/+1
The check that intended to handle "rgmii" PHY mode differently to the RGMII modes with internal delay never worked as intended: - added in commit 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy"): logic error caused the condition to always evaluate to true - changed in commit a46fa260f6f5 ("net: phy: dp83867: Fix warning check for setting the internal delay"): now the condition incorrectly evaluates to false for rgmii-txid - removed in commit 2b892649254f ("net: phy: dp83867: Set up RGMII TX delay") Around the time of the removal, commit c11669a2757e ("net: phy: dp83867: Rework delay rgmii delay handling") started clearing the delay enable flags in RGMIICTL. The change attempted to preserve the historical behavior of not disabling internal delays with "rgmii" PHY mode and also documented this in a comment, but due to a conflict between "Set up RGMII TX delay" and "Rework delay rgmii delay handling", the behavior dp83867_verify_rgmii_cfg() warned about (and that was also described in a comment in dp83867_config_init()) disappeared in the following merge of net into net-next in commit b4b12b0d2f02 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"). While is doesn't appear that this breaking change was intentional, it has been like this since 2019, and the new behavior to disable the delays with "rgmii" PHY mode is generally desirable - in particular with MAC drivers that have to fix up the delay mode, resulting in the PHY driver not even seeing the same mode that was specified in the Device Tree. Remove the obsolete check and comment. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://patch.msgid.link/8a286207cd11b460bb0dbd27931de3626b9d7575.1746612711.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: cadence: macb: Fix a possible deadlock in macb_halt_tx.Mathieu Othacehe1-13/+6
There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore. Fixes: e86cd53afc590 ("net/macb: better manage tx errors") Signed-off-by: Mathieu Othacehe <othacehe@gnu.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250509121935.16282-1-othacehe@gnu.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net: ixp4xx_eth: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()Vladimir Oltean1-32/+29
New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs for configuring hardware timestamping") from kernel v6.6. It is time to convert the intel ixp4xx ethernet driver to the new API, so that the ndo_eth_ioctl() path can be removed completely. hwtstamp_get() and hwtstamp_set() are only called if netif_running() when the code path is engaged through the legacy ioctl. As I don't want to make an unnecessary functional change which I can't test, preserve that restriction when going through the new operations. When cpu_is_ixp46x() is false, the execution of SIOCGHWTSTAMP and SIOCSHWTSTAMP falls through to phy_mii_ioctl(), which may process it in case of a timestamping PHY, or may return -EOPNOTSUPP. In the new API, the core handles timestamping PHYs directly and does not call the netdev driver, so just return -EOPNOTSUPP directly for equivalent logic. A gratuitous change I chose to do anyway is prefixing hwtstamp_get() and hwtstamp_set() with the driver name, ipx4xx. This reflects modern coding sensibilities, and we are touching the involved lines anyway. The remainder of eth_ioctl() is exactly equivalent to phy_do_ioctl_running(), so use that. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20250508211043.3388702-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13net/mlx5: support software TX timestampStanislav Fomichev2-3/+5
Having a software timestamp (along with existing hardware one) is useful to trace how the packets flow through the stack. mlx5e_tx_skb_update_hwts_flags is called from tx paths to setup HW timestamp; extend it to add software one as well. Reviewed-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Stanislav Fomichev <stfomichev@gmail.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250508235109.585096-1-stfomichev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-13hwmon: Add KEBA fan controller supportGerhard Engleder3-0/+257
The KEBA fan controller is found in the system FPGA of KEBA PLC devices. It detects if the fan is removed or blocked. For fans with tacho signal the monitoring of the speed of the fan is supported. It also supports to regulate the speed of fans with PWM input. The auxiliary device for this driver is instantiated by the cp500 misc driver. Signed-off-by: Gerhard Engleder <eg@keba.com> Link: https://lore.kernel.org/r/20250425194823.54664-1-gerhard@engleder-embedded.com [groeck: Added various missing "break;" statements] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-13bus: fsl-mc: Use strscpy() instead of strscpy_pad()Thorsten Blum1-2/+2
Both destination buffers are already zero-initialized, making strscpy() sufficient for safely copying 'obj_type'. The additional NUL-padding performed by strscpy_pad() is unnecessary. If the destination buffer has a fixed length, strscpy() automatically determines its size using sizeof() when the argument is omitted. This makes the explicit size arguments unnecessary. No functional changes intended. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250429104149.66334-1-thorsten.blum@linux.dev Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13soc: fsl: qbman: Remove const from portal->cgrs allocation typeKees Cook1-1/+1
In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct qman_cgrs *", but the returned type, while technically matching, is const qualified. As there is no general way to remove const qualifiers, adjust the allocation type to match the assignment. Signed-off-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20250426062040.work.047-kees@kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13bus: fsl_mc: Fix driver_managed_dma checkRobin Murphy1-3/+3
Since it's not currently safe to take device_lock() in the IOMMU probe path, that can race against really_probe() setting dev->driver before attempting to bind. The race itself isn't so bad, since we're only concerned with dereferencing dev->driver itself anyway, but sadly my attempt to implement the check with minimal churn leads to a kind of TOCTOU issue, where dev->driver becomes valid after to_fsl_mc_driver(NULL) is already computed, and thus the check fails to work as intended. Will and I both hit this with the platform bus, but the pattern here is the same, so fix it for correctness too. Reported-by: Will McVicker <willmcvicker@google.com> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Will McVicker <willmcvicker@google.com> Link: https://lore.kernel.org/r/20250425133929.646493-3-robin.murphy@arm.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS valueLaurentiu Tudor1-1/+1
In case the MC firmware runs in debug mode with extensive prints pushed to the console, the current timeout of 500ms is not enough. Increase the timeout value so that we don't have any chance of wrongly assuming that the firmware is not responding when it's just taking more time. Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250408105814.2837951-7-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13bus: fsl-mc: drop useless cleanupLaurentiu Tudor3-25/+0
This cleanup is actually a no-op because the resources are freed when the device objects are removed from the allocator at driver remove time. Remove the fsl_mc_cleanup_all_resource_pools() function and its call site. Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250408105814.2837951-6-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13bus: fsl-mc: add the dprc_get_mem() command to the whitelistIoana Ciornei1-0/+7
Add a new MC command to the list of accepted firmware commands. The DPRC_GET_MEM command can be used to gather information on the internal memory characteristics. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250408105814.2837951-5-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13bus: fsl-mc: fix GET/SET_TAILDROP command idsWan Junjie1-2/+2
Command ids for taildrop get/set can not pass the check when they are using from the restool user space utility. Correct them according to the user manual. Fixes: d67cc29e6d1f ("bus: fsl-mc: list more commands as accepted through the ioctl") Signed-off-by: Wan Junjie <junjie.wan@inceptio.ai> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Cc: stable@vger.kernel.org Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250408105814.2837951-4-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13bus: fsl-mc: do not add a device-link for the UAPI used DPMCP deviceIoana Ciornei1-6/+13
The fsl-mc bus associated to the root DPRC in a DPAA2 system exports a device file for userspace access to the MC firmware. In case the DPRC's local MC portal (DPMCP) is currently in use, a new DPMCP device is allocated through the fsl_mc_portal_allocate() function. In this case, the call to fsl_mc_portal_allocate() will fail with -EINVAL when trying to add a device link between the root DPRC (consumer) and the newly allocated DPMCP device (supplier). This is because the DPMCP is a dependent of the DPRC device (the bus). Fix this by not adding a device link in case the DPMCP is allocated for the root DPRC's usage. Fixes: afb77422819f ("bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate") Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250408105814.2837951-3-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13bus: fsl-mc: fix double-free on mc_devIoana Ciornei1-2/+4
The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus); Fixes: a042fbed0290 ("staging: fsl-mc: simplify couple of deallocations") Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250408105814.2837951-2-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13soc: fsl: Do not enable DPAA2_CONSOLE by default during compile testingKrzysztof Kozlowski1-1/+1
Enabling the compile test should not cause automatic enabling of such drivers. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250404112407.255126-1-krzysztof.kozlowski@linaro.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-05-13Merge tag 'renesas-pinctrl-for-v6.16-tag1' of ↵Linus Walleij2-130/+170
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: renesas: Updates for v6.16 - Add support for the RZ/V2N (R9A09G056) Soc. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-05-13soc: qcom: llcc-qcom: Add support for SM8750Melody Olvera1-0/+273
Add system cache table and configs for SM8750 SoCs. Signed-off-by: Melody Olvera <melody.olvera@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250512-sm8750_llcc_master-v5-3-d78dca6282a5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-13soc: qcom: llcc-qcom: Add support for LLCC V6Melody Olvera1-4/+220
Add support for LLCC V6. V6 adds several additional usecase IDs, rearrages several registers and offsets, and supports slice IDs over 31, so add a new function for programming LLCC V6. Signed-off-by: Melody Olvera <melody.olvera@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250512-sm8750_llcc_master-v5-2-d78dca6282a5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-12drm: nova-drm: add initial driver skeletonDanilo Krummrich9-0/+291
Add the initial nova-drm driver skeleton. nova-drm is connected to nova-core through the auxiliary bus and implements the DRM parts of the nova driver stack. For now, it implements the fundamental DRM abstractions, i.e. creates a DRM device and registers it, exposing a three sample IOCTLs. DRM_IOCTL_NOVA_GETPARAM - provides the PCI bar size from the bar that maps the GPUs VRAM from nova-core DRM_IOCTL_NOVA_GEM_CREATE - creates a new dummy DRM GEM object and returns a handle DRM_IOCTL_NOVA_GEM_INFO - provides metadata for the DRM GEM object behind a given handle I implemented a small userspace test suite [1] that utilizes this interface. Link: https://gitlab.freedesktop.org/dakr/drm-test [1] Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250424160452.8070-3-dakr@kernel.org [ Kconfig: depend on DRM=y rather than just DRM. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-12gpu: nova-core: register auxiliary device for nova-drmDanilo Krummrich3-1/+11
Register an auxiliary device for nova-drm. For now always use zero for the auxiliary device's ID; we don't use it yet anyways. However, once it lands, we should switch to XArray. Acked-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250424160452.8070-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-12Merge tag 'platform-drivers-x86-v6.15-5' of ↵Linus Torvalds7-5/+40
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform drivers fixes from Ilpo Järvinen: - amd/pmc: Use spurious 8042 quirk with MECHREVO Wujie 14XA - amd/pmf: - Ensure Smart PC policies are valid - Fix memory leak when the engine fails to start - amd/hsmp: Make amd_hsmp and hsmp_acpi as mutually exclusive drivers - asus-wmi: Fix wlan_ctrl_by_user detection - thinkpad_acpi: Add support for NEC Lavie X1475JAS * tag 'platform-drivers-x86-v6.15-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: asus-wmi: Fix wlan_ctrl_by_user detection platform/x86/amd/pmc: Declare quirk_spurious_8042 for MECHREVO Wujie 14XA (GX4HRXL) platform/x86: thinkpad_acpi: Support also NEC Lavie X1475JAS platform/x86/amd/hsmp: Make amd_hsmp and hsmp_acpi as mutually exclusive drivers drivers/platform/x86/amd: pmf: Check for invalid Smart PC Policies drivers/platform/x86/amd: pmf: Check for invalid sideloaded Smart PC Policies
2025-05-12hwmon: pmbus: mpq8785: Add support for MPM3695 familyPawel Dembicki1-1/+9
Add support for the Monolithic Power Systems MPM3695 family. It contains four devices with suffixes: -10, -20, -25 and -100. The device is PMBus compliant and shares characteristics with the MPM82504. MPM3695-25 has different VOLTAGE_SCALE_LOOP register size [11:0] and therefore needs to have a separate compatible entry. Tested with device tree based matching (MPM3695-10). Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-6-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: pmbus: mpq8785: Add support for MPM82504Pawel Dembicki1-1/+28
Add support for the Monolithic Power Systems MPM82504 digital voltage regulator. MPM82504 uses PMBus direct format for voltage output. Tested with device tree based matching. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-5-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: pmbus: mpq8785: Implement VOUT feedback resistor divider ratio ↵Pawel Dembicki1-0/+18
configuration Implement support for setting the VOUT_SCALE_LOOP PMBus register based on an optional device tree property "mps,vout-fb-divider-ratio-permille". This allows the driver to provide the correct VOUT value depending on the feedback voltage divider configuration for chips where the bootloader does not configure the VOUT_SCALE_LOOP register. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-4-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: pmbus: mpq8785: Prepare driver for multiple device supportPawel Dembicki1-8/+30
Refactor the driver to support multiple Monolithic Power Systems devices. Introduce chip ID handling based on device tree matching. No functional changes intended. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-3-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: (ina238) Modify the calculation formula to adapt to different chipsWenliang Yan1-23/+24
Modify the calculation formula to adapt to different chips. Signed-off-by: Wenliang Yan <wenliang202407@163.com> Link: https://lore.kernel.org/r/20250506053741.4837-4-wenliang202407@163.com [groeck: Fixed checkpatch issue (space before and after arithmetic operators)] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: (ina238) Add support for SQ52206Wenliang Yan1-9/+107
Add support for SQ52206 to the Ina238 driver. Add registers, increase compatibility, add compatibility programs for multiple chips. Signed-off-by: Wenliang Yan <wenliang202407@163.com> Link: https://lore.kernel.org/r/20250506053741.4837-3-wenliang202407@163.com [groeck: Fixed checkpatch issues (alignment, {} placing)] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: (ina238) Add ina238_config to save configurations for different chipsWenliang Yan1-5/+52
Add structure ina238_config to store proprietary properties for different chips to meet different chip adaptations Signed-off-by: Wenliang Yan <wenliang202407@163.com> Link: https://lore.kernel.org/r/20250506053741.4837-2-wenliang202407@163.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12drm/msm/dp: Introduce link training per-segment for LTTPRsAleksandrs Vinarskis1-37/+89
DisplayPort requires per-segment link training when LTTPR are switched to non-transparent mode, starting with LTTPR closest to the source. Only when each segment is trained individually, source can link train to sink. Implement per-segment link traning when LTTPR(s) are detected, to support external docking stations. On higher level, changes are: * Pass phy being trained down to all required helpers * Run CR, EQ link training per phy * Set voltage swing, pre-emphasis levels per phy Since at least some LTTPRs (eg. Parade PS8830) do not correctly report voltage-swing, pre-emphasis level 3 support, always assume level 3 is supported. This is permitted under DP 2.1(a) section 3.6.7.2 stating that LTTPR shall set its transmitter levels as close as possible to those requested by the DPTX, if the DPTX sets the voltage swing or pre-emphasis to a level that the LTTPR does not support. It shall be noted that LTTPR’s level choosing is implementation-specific. This ensures successful link training both when connected directly to the monitor (single LTTPR onboard most X1E laptops) and via the docking station (at least two LTTPRs). Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling") Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P Tested-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Rob Clark <robdclark@gmail.com> Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/652305/ Link: https://lore.kernel.org/r/20250507230113.14270-5-alex.vinarskis@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-05-12drm/msm/dp: Prepare for link training per-segment for LTTPRsAleksandrs Vinarskis2-6/+12
Per-segment link training requires knowing the number of LTTPRs (if any) present. Store the count during LTTPRs' initialization. Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling") Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P Tested-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/652306/ Link: https://lore.kernel.org/r/20250507230113.14270-4-alex.vinarskis@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-05-12drm/msm/dp: Account for LTTPRs capabilitiesAleksandrs Vinarskis3-4/+16
Take into account LTTPR capabilities when selecting maximum allowed link rate, number of data lines. Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling") Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> # SA8775P Tested-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/652302/ Link: https://lore.kernel.org/r/20250507230113.14270-3-alex.vinarskis@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-19 10:51:13 +0300