aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-05-29drm/amd/display: clean up some inconsistent indentingJiapeng Chong1-3/+1
No functional modification involved. drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:5200 dc_power_down_on_boot() warn: inconsistent indenting. Reported-by: Abaci Robot <[email protected]> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9166 Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-29drm/amdgpu: silence UBSAN warningAlex Deucher1-1/+1
Convert a variable sized array from [1] to []. Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-29drm/amdgpu: Adjust logic in amdgpu_device_partner_bandwidth()Alex Deucher1-7/+12
Use current speed/width on devices which don't support dynamic PCIe switching. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3289 Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-05-29Fix issue when using devm_of_regulator_put_matches andMark Brown1-16/+50
Merge series from Alina Yu <[email protected]>: There are two types of LDO VOUT: fixed voltage mode and adjustable voltage mode. As the fixed voltage for the LDO is outside the range of the adjustable voltage mode, the constraints for this scenario are not suitable to represent both modes. Therefore, A property is added to specify the fixed LDO VOUT. In this version, a software bug has been fixed. rtq2208_ldo_match is no longer a local variable. It prevents invalid memory access when devm_of_regulator_put_matches is called.
2024-05-29drm/xe: Drop undesired prefix from the platform nameMichal Wajdeczko1-12/+12
We don't have to use exact names of the enumerators as the potentially user-facing platform names. When constructing platform descriptor fields, use the unique platform tag and add the XE_ prefix only to the generated enum field. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Lucas De Marchi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-05-29Merge tag 'v6.10-p3' of ↵Linus Torvalds1-43/+4
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "This fixes a new run-time warning triggered by tpm" * tag 'v6.10-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: hwrng: core - Remove add_early_randomness
2024-05-29spi: Assign dummy scatterlist to unidirectional transfersAndy Shevchenko1-0/+9
Commit 8cc3bad9d9d6 ("spi: Remove unneded check for orig_nents") introduced a regression: unmapped data could now be passed to the DMA APIs, resulting in null pointer dereferences. Commit 9f788ba457b4 ("spi: Don't mark message DMA mapped when no transfer in it is") and commit da560097c056 ("spi: Check if transfer is mapped before calling DMA sync APIs") addressed the problem, but only partially. Unidirectional transactions will still result in null pointer dereference. To prevent that from happening, assign a dummy scatterlist when no data is mapped, so that the DMA API can be called and not result in a null pointer dereference. Signed-off-by: Andy Shevchenko <[email protected]> Reported-by: Neil Armstrong <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Reported-by: Nícolas F. R. A. Prado <[email protected]> Closes: https://lore.kernel.org/all/d3679496-2e4e-4a7c-97ed-f193bd53af1d@notapiano Closes: https://lore.kernel.org/all/4748499f-789c-45a8-b50a-2dd09f4bac8c@notapiano Fixes: 8cc3bad9d9d6 ("spi: Remove unneded check for orig_nents") Tested-by: Nícolas F. R. A. Prado <[email protected]> [nfraprado: wrote the commit message] Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-05-29regulator: rtq2208: Add fixed LDO VOUT property and check that matches the ↵Alina Yu1-2/+9
constraints A fixed LDO VOUT property has been added to specify the fixed_uV of the regulator_desc. Additionally, a check has been included in this version to ensure that the fixed_uV matches the constraints. Signed-off-by: Alina Yu <[email protected]> Link: https://msgid.link/r/39357ff9e6e5f3dec5a6f7f833a3591c0defc63a.1716870419.git.alina_yu@richtek.com Signed-off-by: Mark Brown <[email protected]>
2024-05-29regulator: rtq2208: Fix LDO to be compatible with both fixed and adjustable voutAlina Yu1-6/+31
In this patch, LDO's adjustable and fixed Vout settings are compatible. The LDO Vout ability depends on "richtek,fixed-microvolt". If adjustable, the Vout can be set to either 1800mV or 3300mV. Signed-off-by: Alina Yu <[email protected]> Link: https://msgid.link/r/5ad4c7728c7fa7f6286db36b99d31c9d0f5d16c7.1716870419.git.alina_yu@richtek.com Signed-off-by: Mark Brown <[email protected]>
2024-05-29ARM: st: add new compatible for PWR regulators onMark Brown1-0/+1
Merge series from Patrick Delaunay <[email protected]>: This patchset adds the new PWR regulators compatible for STM32MP13: "st,stm32mp13-pwr-reg". As this node is just introduced by [1] and it is is not used by any board in Linux, it is the good time to introduced this compatible and update the STM32MP13 SoC dtsi without ABI break. A new compatible is needed as the content of the PWR_CR3 register, used by this driver change with new bits on STM32MP13 for SD IO domain: - bit 23: VDDSD2VALID - bit 22: VDDSD1VALID - bit 16: VDDSD2RDY - bit 15: VDDSD2EN - bit 14: VDDSD1RDY - bit 13: VDDSD1EN I will push a update on STM32MP13 SoC dtsi if this new compatible is accepted to preserve the bisectability. [1] commit f798f7079233 ("ARM: dts: stm32: add PWR regulators support on stm32mp131") https://lore.kernel.org/linux-arm-kernel/[email protected]/
2024-05-29drm/xe/hwmon: Expose card power and energy attributes of BMGKarthik Poosa2-8/+18
In BMG there are separate registers for card/platform power and energy. These are exposed through channel 0 i.e power_1/energy1_xxx. Signed-off-by: Karthik Poosa <[email protected]> Reviewed-by: Badal Nilawar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-29drm/xe/hwmon: Add HWMON support for BMGKarthik Poosa2-4/+17
Add HWMON support for BMG. Exposing the pkg power, current, energy info. Signed-off-by: Karthik Poosa <[email protected]> Reviewed-by: Badal Nilawar <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-29wifi: iwlwifi: mvm: don't read past the mfuart notifcationEmmanuel Grumbach1-10/+0
In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing. This was reported by KFENCE. Fixes: bdccdb854f2f ("iwlwifi: mvm: support MFUART dump in case of MFUART assert") Signed-off-by: Emmanuel Grumbach <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240513132416.ba82a01a559e.Ia91dd20f5e1ca1ad380b95e68aebf2794f553d9b@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: Fix scan abort handling with HW rfkillIlan Peer1-1/+2
When HW rfkill is toggled to disable the RF, the flow to stop scan is called. When trying to send the command to abort the scan, since HW rfkill is toggled, the command is not sent due to rfkill being asserted, and -ERFKILL is returned from iwl_trans_send_cmd(), but this is silently ignored in iwl_mvm_send_cmd() and thus the scan abort flow continues to wait for scan complete notification and fails. Since it fails, the UID to type mapping is not cleared, and thus a warning is later fired when trying to stop the interface. To fix this, modify the UMAC scan abort flow to force sending the scan abort command even when in rfkill, so stop the FW from accessing the radio etc. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240513132416.8cbe2f8c1a97.Iffe235c12a919dafec88eef399eb1f7bae2c5bdb@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: check n_ssids before accessing the ssidsMiri Korenblit1-2/+2
In some versions of cfg80211, the ssids poinet might be a valid one even though n_ssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking n_ssids first. Fixes: c1a7515393e4 ("iwlwifi: mvm: add adaptive dwell support") Signed-off-by: Miri Korenblit <[email protected]> Reviewed-by: Ilan Peer <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Link: https://msgid.link/20240513132416.6e4d1762bf0d.I5a0e6cc8f02050a766db704d15594c61fe583d45@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: properly set 6 GHz channel direct probe optionAyala Beker1-1/+4
Ensure that the 6 GHz channel is configured with a valid direct BSSID, avoiding any invalid or multicast BSSID addresses. Signed-off-by: Ayala Beker <[email protected]> Reviewed-by: Ilan Peer <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240513132416.91a631a0fe60.I2ea2616af9b8a2eaf959b156c69cf65a2f1204d4@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: handle BA session teardown in RF-killJohannes Berg3-6/+11
When entering RF-kill, mac80211 tears down BA sessions, but due to RF-kill the commands aren't sent to the device. As a result, there can be frames pending on the reorder buffer or perhaps even received while doing so, leading to warnings. Avoid the warnings by doing the BA session teardown normally even in RF-kill, which also requires queue sync. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240513132416.0762cd80fb3d.I43c5877f3b546159b2db4f36d6d956b333c41cf0@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: Handle BIGTK cipher in kek_kck cmdYedidya Benshimol1-2/+11
The BIGTK cipher field was added to the kek_kck_material_cmd but wasn't assigned. Fix that by differentiating between the IGTK/BIGTK keys and assign the ciphers fields accordingly. Signed-off-by: Yedidya Benshimol <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240513132416.7fd0b22b7267.Ie9b581652b74bd7806980364d59e1b2e78e682c0@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: remove stale STA link data during restartBenjamin Berg3-5/+47
If pre-recovery mac80211 tried to disable a link but this disablement failed, then there might be a mismatch between mac80211 assuming the link has been disabled and the driver still having the data around. During recover itself, that is not a problem, but should the link be activated again at a later point, iwlwifi will refuse the activation as it detects the inconsistent state. Solve this corner-case by iterating the station in the restart cleanup handler. Signed-off-by: Benjamin Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240513132416.d2fd60338055.I840d4fdce5fd49fe69896d928b071067e3730259@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdefShahar S Matityahu1-1/+1
The driver should call iwl_dbg_tlv_free even if debugfs is not defined since ini mode does not depend on debugfs ifdef. Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external file") Signed-off-by: Shahar S Matityahu <[email protected]> Reviewed-by: Luciano Coelho <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240510170500.c8e3723f55b0.I5e805732b0be31ee6b83c642ec652a34e974ff10@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: set properly mac headerMordechay Goodstein1-1/+4
In the driver we only use skb_put* for adding data to the skb, hence data never moves and skb_reset_mac_haeder would set mac_header to the first time data was added and not to mac80211 header, fix this my using the actual len of bytes added for setting the mac header. Fixes: 3f7a9d577d47 ("wifi: iwlwifi: mvm: simplify by using SKB MAC header pointer") Signed-off-by: Mordechay Goodstein <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240510170500.12f2de2909c3.I72a819b96f2fe55bde192a8fd31a4b96c301aa73@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: revert gen2 TX A-MPDU size to 64Johannes Berg1-7/+2
We don't actually support >64 even for HE devices, so revert back to 64. This fixes an issue where the session is refused because the queue is configured differently from the actual session later. Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Liad Kaufman <[email protected]> Reviewed-by: Luciano Coelho <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240510170500.52f7b4cf83aa.If47e43adddf7fe250ed7f5571fbb35d8221c7c47@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: d3: fix WoWLAN command version lookupYedidya Benshimol1-1/+2
After moving from commands to notificaitons in the d3 resume flow, removing the WOWLAN_GET_STATUSES and REPLY_OFFLOADS_QUERY_CMD causes the return of the default value when looking up their version. Returning zero here results in the driver sending the not supported NON_QOS_TX_COUNTER_CMD. Signed-off-by: Yedidya Benshimol <[email protected]> Reviewed-by: Gregory Greenman <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240510170500.8cabfd580614.If3a0db9851f56041f8f5360959354abd5379224a@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: fix a crash on 7265Emmanuel Grumbach1-2/+2
Since IWL_FW_CMD_VER_UNKNOWN = 99, then my change to consider cmd_ver >= 7 instead of cmd_ver = 7 included also firmwares that don't advertise the command version at all. This made us send a command with a bad size and because of that, the firmware hit a BAD_COMMAND immediately after handling the REDUCE_TX_POWER_CMD command. Fixes: 8f892e225f41 ("wifi: iwlwifi: mvm: support iwl_dev_tx_power_cmd_v8") Signed-off-by: Emmanuel Grumbach <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240512072733.eb20ff5050d3.Ie4fc6f5496cd296fd6ff20d15e98676f28a3cccd@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: always set the TWT IE offsetShaul Triebitz3-1/+11
In beacon template version 14, make sure to always set the TWT IE offset before sending the beacon template command, also in the debugfs inject_beacon_ie path. If the TWT IE does not exist, the offset will be set to zero. Fixes: bf0212fd8faa ("wifi: iwlwifi: mvm: add beacon template version 14") Signed-off-by: Shaul Triebitz <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240512152312.eb27175c345a.If30ef24aba10fe47fd42a7a9703eb8903035e294@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29wifi: iwlwifi: mvm: don't initialize csa_work twiceMiri Korenblit1-2/+0
The initialization of this worker moved to iwl_mvm_mac_init_mvmvif but we removed only from the pre-MLD version of the add_interface callback. Remove it also from the MLD version. Fixes: 0bcc2155983e ("wifi: iwlwifi: mvm: init vif works only once") Signed-off-by: Miri Korenblit <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Link: https://msgid.link/20240512152312.4f15b41604f0.Iec912158e5a706175531d3736d77d25adf02fba4@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-05-29spi: cadence: Ensure data lines set to low during dummy-cycle periodWitold Sadowski1-5/+15
During dummy-cycles xSPI will switch GPIO into Hi-Z mode. In that dummy period voltage on data lines will slowly drop, what can cause unintentional modebyte transmission. Value send to SPI memory chip will depend on last address, and clock frequency. To prevent unforeseen consequences of that behaviour, force send single modebyte(0x00). Modebyte will be send only if number of dummy-cycles is not equal to 0. Code must also reduce dummycycle byte count by one - as one byte is send as modebyte. Signed-off-by: Witold Sadowski <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-05-29net: phy: xilinx-gmii2rgmii: Adopt clock supportVineeth Karumanchi1-0/+7
Add clock support to the gmii_to_rgmii IP. Make clk optional to keep DTB backward compatibility. Signed-off-by: Vineeth Karumanchi <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-29nfc/nci: Add the inconsistency check between the input data length and countEdward Adam Davis1-0/+4
write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf) Syzbot constructed a write() call with a data length of 3 bytes but a count value of 15, which passed too little data to meet the basic requirements of the function nci_rf_intf_activated_ntf_packet(). Therefore, increasing the comparison between data length and count value to avoid problems caused by inconsistent data length and count. Reported-and-tested-by: [email protected] Signed-off-by: Edward Adam Davis <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-29gpio: syscon: do not report bogus errorEtienne Buira1-11/+16
Do not issue "can't read the data register offset!" when gpio,syscon-dev is not set albeit unneeded. gpio-syscon is used with rk3328 chip, but this iomem region is documented in Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml and does not require gpio,syscon-dev setting. Signed-off-by: Etienne Buira <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/Zktwd4Y8zu6XSGaE@Z926fQmE5jqhFMgp6 Signed-off-by: Bartosz Golaszewski <[email protected]>
2024-05-29Add support for GPIO based CSMark Brown1-1/+5
Merge series from Prajna Rajendra Kumar <[email protected]>: The Microchip PolarFire SoC SPI "hard" controller supports eight chip selects. However, only one chip select is physically wired. Therefore, use GPIO descriptors to configure additional chip select lines.
2024-05-29spi: gpio: Convert to be used outside of OFMark Brown1-41/+25
Merge series from Andy Shevchenko <[email protected]>: Convert the driver to be used outside of OF and a couple of cleanups.
2024-05-29regulator: max77503: remove unused struct 'max77503_dev'Dr. David Alan Gilbert1-8/+0
'max77503_dev' is unused since the original commit a0c543bdf4ba ("regulator: max77503: Add ADI MAX77503 support"). Remove it. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-05-29spi: bitbang: Clean up the driverMark Brown1-46/+27
Merge series from Andy Shevchenko <[email protected]>: A few cleanups to the driver. No functional change intended.
2024-05-29spi: differentiate between unsupported and invalidMark Brown4-14/+16
Merge series from Miquel Raynal <[email protected]>: I am working on spi-nand continuous read support, which lead me to check what spi controllers were capable of. >From a caller (and reviewer) point of view, distinguishing between error cases has been proven useful, especially between two conditions: - the request is totally unsupported and will never work - the request is typically out of range somehow but a subsequent call with corrected parameters might work So while I was statically reading the various drivers, I attempted to clarify these situations and thought it might be nice to have this upstream as well. As ENOTSUPP is not a SUSV4 code and previous series have already been merged to reduce its use, I also converted these few cases to EOPNOTSUP instead, but if anybody doesn't like these changes, it can be dropped.
2024-05-29Add optional reset control for Cadence SPIMark Brown1-0/+13
Merge series from Ji Sheng Teoh <[email protected]>: The first patch adds optional reset control to support assertion and deassertion of reset signal to properly bring the SPI device into an operating condition. The second patch documents the optional reset control into dt-bindings.
2024-05-29net: ethernet: cortina: Restore TSO supportLinus Walleij1-4/+19
An earlier commit deleted the TSO support in the Cortina Gemini driver because the driver was confusing gso_size and MTU, probably because what the Linux kernel calls "gso_size" was called "MTU" in the datasheet. Restore the functionality properly reading the gso_size from the skbuff. Tested with iperf3, running a server on a different machine and client on the device with the cortina gemini ethernet: Connecting to host 192.168.1.2, port 5201 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=27da 60008000.ethernet-port eth0: segment offloading mss = 05ea len=0b92 60008000.ethernet-port eth0: segment offloading mss = 05ea len=2bda (...) (The hardware MSS 0x05ea here includes the ethernet headers.) If I disable all segment offloading on the receiving host and dump packets using tcpdump -xx like this: ethtool -K enp2s0 gro off gso off tso off tcpdump -xx -i enp2s0 host 192.168.1.136 I get segmented packages such as this when running iperf3: 23:16:54.024139 IP OpenWrt.lan.59168 > Fecusia.targus-getdata1: Flags [.], seq 1486:2934, ack 1, win 4198, options [nop,nop,TS val 3886192908 ecr 3601341877], length 1448 0x0000: fc34 9701 a0c6 14d6 4da8 3c4f 0800 4500 0x0010: 05dc 16a0 4000 4006 9aa1 c0a8 0188 c0a8 0x0020: 0102 e720 1451 ff25 9822 4c52 29cf 8010 0x0030: 1066 ac8c 0000 0101 080a e7a2 990c d6a8 (...) 0x05c0: 5e49 e109 fe8c 4617 5e18 7a82 7eae d647 0x05d0: e8ee ae64 dc88 c897 3f8a 07a4 3a33 6b1b 0x05e0: 3501 a30f 2758 cc44 4b4a Several such packets often follow after each other verifying the segmentation into 0x05a8 (1448) byte packages also on the reveiving end. As can be seen, the ethernet frames are 0x05ea (1514) in size. Performance with iperf3 before this patch: ~15.5 Mbit/s Performance with iperf3 after this patch: ~175 Mbit/s This was running a 60 second test (twice) the best measurement was 179 Mbit/s. For comparison if I run iperf3 with UDP I get around 1.05 Mbit/s both before and after this patch. While this is a gigabit ethernet interface, the CPU is a cheap D-Link DIR-685 router (based on the ARMv5 Faraday FA526 at ~50 MHz), and the software is not supposed to drive traffic, as the device has a DSA chip, so this kind of numbers can be expected. Fixes: ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-29drm/display: Fix HDMI state helper dependencyMaxime Ripard1-1/+1
During the life of the series that introduced the DRM_DISPLAY_HDMI_STATE_HELPER option, we reworked the Kconfig option dependency setup to rely on depends on with commit f6d2dc03fa85 ("drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on") which got reverted later on because it was creating too many issues by commit d7c128cb775e ("Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on""). However, since the series was out of tree at that time, DRM_DISPLAY_HDMI_STATE_HELPER wasn't properly updated to take the revert into account and is now creating build issues. Let's switch the depends on to a select to fix this. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2024-05-29drm/xe: Add engine name to the engine reset and cat-err logNirmoy Das1-2/+7
Add engine name to the engine reset and cat error log which should be useful while debugging. v2: Add logical mask and engine class(Matt) Use xe_gt_{info|dbg} (Michal) Cc: Matthew Brost <[email protected]> Cc: Michal Wajdeczko <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-05-29drm/xe: Check empty pinned BO list with lock held.Nirmoy Das1-6/+4
Use lock that is meant to use for accessing the BO pin list. Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]>
2024-05-29drm/i915: Fix audio component initializationImre Deak3-11/+24
After registering the audio component in i915_audio_component_init() the audio driver may call i915_audio_component_get_power() via the component ops. This could program AUD_FREQ_CNTRL with an uninitialized value if the latter function is called before display.audio.freq_cntrl gets initialized. The get_power() function also does a modeset which in the above case happens too early before the initialization step and triggers the "Reject display access from task" error message added by the Fixes: commit below. Fix the above issue by registering the audio component only after the initialization step. Fixes: 87c1694533c9 ("drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10291 Cc: [email protected] # v5.5+ Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit fdd0b80172758ce284f19fa8a26d90c61e4371d2) Signed-off-by: Jani Nikula <[email protected]>
2024-05-29drm/i915/dpt: Make DPT object unshrinkableVidya Srinivas1-1/+3
In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->bound_list. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic. Cc: [email protected] Reported-by: Shawn Lee <[email protected]> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by: Vidya Srinivas <[email protected]> [vsyrjala: Add TODO comment] Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c) Signed-off-by: Jani Nikula <[email protected]>
2024-05-29drm/i915/gt: Fix CCS id's calculation for CCS mode settingAndi Shyti3-1/+15
The whole point of the previous fixes has been to change the CCS hardware configuration to generate only one stream available to the compute users. We did this by changing the info.engine_mask that is set during device probe, reset during the detection of the fused engines, and finally reset again when choosing the CCS mode. We can't use the engine_mask variable anymore, as with the current configuration, it imposes only one CCS no matter what the hardware configuration is. Before changing the engine_mask for the third time, save it and use it for calculating the CCS mode. After the previous changes, the user reported a performance drop to around 1/4. We have tested that the compute operations, with the current patch, have improved by the same factor. Fixes: 6db31251bb26 ("drm/i915/gt: Enable only one CCS for compute workload") Signed-off-by: Andi Shyti <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Gnattu OC <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Matt Roper <[email protected]> Tested-by: Jian Ye <[email protected]> Reviewed-by: Umesh Nerlige Ramappa <[email protected]> Tested-by: Gnattu OC <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a09d2327a9ba8e3f5be238bc1b7ca2809255b464) Signed-off-by: Jani Nikula <[email protected]>
2024-05-29drm/panel/lg-sw43408: mark sw43408_backlight_ops as staticDmitry Baryshkov1-1/+1
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being declared. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reviewed-by: Neil Armstrong <[email protected]> Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Marijn Suijten <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-05-29drm/i915/selftests: Set always_coherent to false when reading from CPUNirmoy Das1-1/+1
Commit 8d4ba9fc1c6c ("drm/i915/selftests: Pick correct caching mode.") was not complete as for non LLC sharing platforms cpu read can happen from LLC which probably doesn't have the latest changes made by GPU. Cc: Andi Shyti <[email protected]> Cc: Janusz Krzysztofik <[email protected]> Cc: Jonathan Cavitt <[email protected]> Fixes: 8d4ba9fc1c6c ("drm/i915/selftests: Pick correct caching mode.") Reviewed-by: Jonathan Cavitt <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Nirmoy Das <[email protected]> (cherry picked from commit 007ed70831426d4cc108d879d688de6b8e3e6d45) Signed-off-by: Jani Nikula <[email protected]>
2024-05-29drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPERDmitry Baryshkov1-0/+2
This panel driver uses DSC PPS functions and as such depends on the DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions available to the driver. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-05-29drm/i915/guc: avoid FIELD_PREP warningArnd Bergmann1-3/+3
With gcc-7 and earlier, there are lots of warnings like In file included from <command-line>:0:0: In function '__guc_context_policy_add_priority.isra.66', inlined from '__guc_context_set_prio.isra.67' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3292:3, inlined from 'guc_context_set_prio' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3320:2: include/linux/compiler_types.h:399:38: error: call to '__compiletime_assert_631' declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ... drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2422:3: note: in expansion of macro 'FIELD_PREP' FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~~~~~~~~~ Make sure that GUC_KLV_0_KEY is an unsigned value to avoid the warning. Fixes: 77b6f79df66e ("drm/i915/guc: Update to GuC version 69.0.3") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Michal Wajdeczko <[email protected]> Signed-off-by: Julia Filipchuk <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 364e039827ef628c650c21c1afe1c54d9c3296d9) Signed-off-by: Jani Nikula <[email protected]>
2024-05-29drm/i915/gt: Disarm breadcrumbs if engines are already idleChris Wilson1-8/+7
The breadcrumbs use a GT wakeref for guarding the interrupt, but are disarmed during release of the engine wakeref. This leaves a hole where we may attach a breadcrumb just as the engine is parking (after it has parked its breadcrumbs), execute the irq worker with some signalers still attached, but never be woken again. That issue manifests itself in CI with IGT runner timeouts while tests are waiting indefinitely for release of all GT wakerefs. <6> [209.151778] i915: Running live_engine_pm_selftests/live_engine_busy_stats <7> [209.231628] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_5 <7> [209.231816] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_4 <7> [209.231944] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_3 <7> [209.232056] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_2 <7> [209.232166] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling DC_off <7> [209.232270] i915 0000:00:02.0: [drm:skl_enable_dc6 [i915]] Enabling DC6 <7> [209.232368] i915 0000:00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] Setting DC state from 00 to 02 <4> [299.356116] [IGT] Inactivity timeout exceeded. Killing the current test with SIGQUIT. ... <6> [299.356526] sysrq: Show State ... <6> [299.373964] task:i915_selftest state:D stack:11784 pid:5578 tgid:5578 ppid:873 flags:0x00004002 <6> [299.373967] Call Trace: <6> [299.373968] <TASK> <6> [299.373970] __schedule+0x3bb/0xda0 <6> [299.373974] schedule+0x41/0x110 <6> [299.373976] intel_wakeref_wait_for_idle+0x82/0x100 [i915] <6> [299.374083] ? __pfx_var_wake_function+0x10/0x10 <6> [299.374087] live_engine_busy_stats+0x9b/0x500 [i915] <6> [299.374173] __i915_subtests+0xbe/0x240 [i915] <6> [299.374277] ? __pfx___intel_gt_live_setup+0x10/0x10 [i915] <6> [299.374369] ? __pfx___intel_gt_live_teardown+0x10/0x10 [i915] <6> [299.374456] intel_engine_live_selftests+0x1c/0x30 [i915] <6> [299.374547] __run_selftests+0xbb/0x190 [i915] <6> [299.374635] i915_live_selftests+0x4b/0x90 [i915] <6> [299.374717] i915_pci_probe+0x10d/0x210 [i915] At the end of the interrupt worker, if there are no more engines awake, disarm the breadcrumb and go to sleep. Fixes: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission") Closes: https://gitlab.freedesktop.org/drm/intel/issues/10026 Signed-off-by: Chris Wilson <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: <[email protected]> # v5.12+ Signed-off-by: Janusz Krzysztofik <[email protected]> Acked-by: Nirmoy Das <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit fbad43eccae5cb14594195c20113369aabaa22b5) Signed-off-by: Jani Nikula <[email protected]>
2024-05-29Revert "drm/i915: Remove extra multi-gt pm-references"Janusz Krzysztofik1-0/+18
This reverts commit 1f33dc0c1189efb9ae19c6fc22b64dd3e26261fb. There was a patch supposed to fix an issue of illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle, reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT was acquired from i915_gem_do_execbuffer() -- see commit f56fe3e91787 ("drm/i915: Fix a VMA UAF for multi-gt platform"). However, that fix occurred insufficient -- the issue was still reported by CI. That wakeref was released on exit from i915_gem_do_execbuffer(), then potentially before completion of the request and deactivation of its associated VMAs. Moreover, CI reports indicated that single-GT platforms also suffered sporadically from the same race. Since that issue was fixed by another commit f3c71b2ded5c ("drm/i915/vma: Fix UAF on destroy against retire race"), the changes introduced by that insufficient fix were dropped as no longer useful. However, that series resulted in another VMA UAF scenario now being triggered in CI. <4> [260.290809] ------------[ cut here ]------------ <4> [260.290988] list_del corruption. prev->next should be ffff888118c5d990, but was ffff888118c5a510. (prev=ffff888118c5a510) <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62 __list_del_entry_valid_or_report+0xb7/0xe0 .. <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0 ... <4> [260.291087] Call Trace: <4> [260.291089] <TASK> <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915] <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915] <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915] <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [260.292301] </TASK> ... <4> [260.292506] ---[ end trace 0000000000000000 ]--- <4> [260.292782] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6ca3: 0000 [#1] PREEMPT SMP NOPTI <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: G W 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915] ... <4> [260.428756] Call Trace: <4> [260.431192] <TASK> <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915] <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [639.411134] </TASK> ... <4> [639.449979] ---[ end trace 0000000000000000 ]--- We defer actually closing, unbinding and destroying a VMA until next idle point, or until the object is freed in the meantime. By postponing the unbind, we allow for the VMA to be reopened by the client, avoiding the work required to rebind the VMA. Starting from commit b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()"), we assume that as long as a GT is held idle, no VMA would be reopened while we destroy them. That assumption is no longer true in multi-GT configurations, where a VMA we reopen may be handled by a GT different from the one that we already keep active via its engine while we set up an execbuf request. Restoring the extra GT0 PM wakeref removed from i915_gem_do_execbuffer() processing path seems to fix this issue. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608 Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Nirmoy Das <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Fixes: 1f33dc0c1189 ("drm/i915: Remove extra multi-gt pm-references") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> (cherry picked from commit 749670a58d935303ad1ce529acc73f12de25832e) Signed-off-by: Jani Nikula <[email protected]>
2024-05-29wifi: iwlwifi: move Bz and Gl iwl_dev_info entriesMiri Korenblit1-26/+26
The iwl_dev_info entries for these devices were incorrectly positioned within the array, out of chronological order. Move them arround. Signed-off-by: Miri Korenblit <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Reviewed-by: Emmanuel Grumbach <[email protected]> Link: https://msgid.link/20240527190228.a75e9a1eb86c.I003980f8ca60a96019657e396e848a07df6b92a4@changeid Signed-off-by: Johannes Berg <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.