summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-17soc: qcom: pd-mapper: Add Kaanapali compatiblePrasad Kumpatla
Add support for the Qualcomm Kaanapali SoC to the protection domain mapper. Kaanapali shares the same protection domain configuration as SM8550, except charger_pd as it move to SoCCP. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251014-knp-pdmapper-v2-v2-1-ba44422ac503@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-17clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resetsKonrad Dybcio
Currently, some of the USB4 clocks/resets are described, but not all of the back-end muxes are present. Configuring them properly is necessary for proper operation of the hardware. Add all the resets & muxes and wire up any unaccounted USB4 clock paths. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251003-topic-hamoa_gcc_usb4-v2-2-61d27a14ee65@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-17drm/i915/dp: Fix panel replay when DSC is enabledImre Deak
Prevent enabling panel replay if the sink doesn't support this due to DSC being enabled. Panel replay has two modes, updating full frames or only selected regions of the frame. If the sink doesn't support Panel Replay in full frame update mode with DSC prevent Panel Replay completely if DSC is enabled. If the sink doesn't support Panel Replay only in the selective update mode while DSC is enabled, it will still support Panel Replay in the full frame update mode, so only prevent selective updates in this case. v2: - Use Panel Replay instead of PR in debug prints. (Jouni) - Rebase on change tracking the link DSC state in the crtc state. Cc: Jouni Högander <jouni.hogander@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the linkImre Deak
The state of all the CRTCs on an MST link must be recomputed, if DSC gets enabled on any of the CRTCs on the link. For instance an MST docking station's Panel Replay capability may depend on whether DSC is enabled on any of the dock's streams (aka CRTCs). To assist the Panel Replay state computation for a CRTC based on the above, track in the CRTC state if DSC is enabled on any CRTC on an MST link. The intel_link_bw_limits::force_fec_pipes mask is used for a reason similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST link if DSC is enabled on any of the link's CRTCs. The FEC enabled state for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is always enabled by the HW for UHBR, hence it's not tracked by the intel_crtc_state::fec_enable flag for such links, where this flag is always false). Based on the above, to be able to determine the DSC state on both non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link state (instead of the FEC-enabled-on-link state) for each CRTC in intel_link_bw_limits. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-7-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Track DSC enabled status on the MST linkImre Deak
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI) this will always match the CRTC's DSC state, those links having only a single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will be as follows: CRTC#0: - compression_enable = true - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b CRTC#1: - compression_enable = false - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b This patch only sets compression_enabled_on_link for CRTC#0 above and enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b MST link. A follow-up change will make sure that the state of all the CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on any CRTC, setting compression_enabled_on_link and fec_enable for these. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC configImre Deak
Reuse the DP-SST helper to compute the state for the FEC enabled state for DP-MST as well. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-5-imre.deak@intel.com
2025-10-17drm/i915/dp: Export helper to determine if FEC on non-UHBR links is requiredImre Deak
Export the helper function to determine if FEC is required on a non-UHBR (8b10b) SST or MST link. A follow up change will take this into use for MST as well. While at it determine the output type from the CRTC state, which allows dropping the intel_dp argument. Also make the function return the required FEC state, instead of setting this in the CRTC state, which allows only querying this requirement, without changing the state. Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that the function determines if FEC is required on an 8b10b link (on 128b132b links FEC is always enabled by the HW implicitly, so the function will return false for that case). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
2025-10-17drm/i915/dp: Ensure the FEC state stays disabled for UHBR linksImre Deak
Atm, in the DP SST case the FEC state is computed before intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr() will always return false and the FEC state will be always computed assuming a non-UHBR link. This happens to work, since the FEC state is recomputed later in intel_dp_mtp_tu_compute_config(), where port_clock will be set already, so intel_crtc_state::fec_enable will be reset as expected for UHBR. This also depends on link rates being tried in an increasing order (i.e. from non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus intel_crtc_state::fec_enable being set for the non-UHBR rates and getting reset for the first UHBR rate as expected. A follow-up change will reuse intel_dp_fec_compute_config() for the DP MST state computation, prepare for that here, making sure that the function determines the correct intel_crtc_state::fec_enable=false state for UHBR link rates based on the above. The DP SST and MST state computation should be further unified to avoid computing/setting the intel_crtc_state::fec_enable state multiple times, but that's left for a follow-up change. For now add only code comments about this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
2025-10-17drm/i915/dsc: Add helper to enable the DSC configuration for a CRTCImre Deak
Add a helper to enable the DSC compression configuration for a CRTC. Follow-up changes will introduce tracking for the same DSC state on the whole link, which will need to be set whenever DSC is enabled for the CRTC. Also, according to the above, when querying the DSC state on the link, both the CRTC's and the link's DSC state must be considered. Setting the DSC configuration for a CRTC and querying the DSC configuration for the link (added by follow-up changes) is better done via helper functions based on the above, prepare for that here. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-2-imre.deak@intel.com
2025-10-17spi: airoha: driver fixes & improvementsMark Brown
Merge series from Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>: This patch series greatly improve airoha snfi driver and fix a number of serious bugs. Fixed bugs: * Fix reading/writing of flashes with more than one plane per lun * Fill the buffer with 0xff before writing * Fix reading of flashes supporting continuous reading mode * Fix error paths Improvements: * Add support of dual/quad wires spi modes in exec_op(). This also fix flash reading/writing if dirmap can't be created. * Support of dualio/quadio flash reading commands * Remove dirty hack that reads flash page settings from SNFI registers during driver startup * Add support of EN7523 SoC Patched kernel tests: root@OpenWrt:/lib/modules/6.6.79# insmod mtd_oobtest.ko dev=1 [ 263.191711] [ 263.193218] ================================================= [ 263.199014] mtd_oobtest: MTD device: 1 [ 263.202768] mtd_oobtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 263.216791] mtd_test: scanning for bad eraseblocks [ 263.221956] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 263.227361] mtd_oobtest: test 1 of 5 [ 265.077216] mtd_oobtest: writing OOBs of whole device [ 265.121767] mtd_oobtest: written up to eraseblock 0 [ 275.174147] mtd_oobtest: written up to eraseblock 256 [ 285.210279] mtd_oobtest: written up to eraseblock 512 [ 295.241724] mtd_oobtest: written up to eraseblock 768 [ 305.280167] mtd_oobtest: written up to eraseblock 1024 [ 315.326883] mtd_oobtest: written up to eraseblock 1280 [ 325.364049] mtd_oobtest: written up to eraseblock 1536 [ 335.398609] mtd_oobtest: written up to eraseblock 1792 [ 345.358981] mtd_oobtest: written 2047 eraseblocks [ 345.363694] mtd_oobtest: verifying all eraseblocks [ 345.386088] mtd_oobtest: verified up to eraseblock 0 [ 349.830833] mtd_oobtest: verified up to eraseblock 256 [ 354.276245] mtd_oobtest: verified up to eraseblock 512 [ 358.721496] mtd_oobtest: verified up to eraseblock 768 [ 363.166881] mtd_oobtest: verified up to eraseblock 1024 [ 367.612694] mtd_oobtest: verified up to eraseblock 1280 [ 372.058211] mtd_oobtest: verified up to eraseblock 1536 [ 376.503820] mtd_oobtest: verified up to eraseblock 1792 [ 380.914843] mtd_oobtest: verified 2047 eraseblocks [ 380.919660] mtd_oobtest: test 2 of 5 [ 384.202620] mtd_oobtest: writing OOBs of whole device [ 384.247584] mtd_oobtest: written up to eraseblock 0 [ 394.305121] mtd_oobtest: written up to eraseblock 256 [ 404.342199] mtd_oobtest: written up to eraseblock 512 [ 414.374204] mtd_oobtest: written up to eraseblock 768 [ 424.409891] mtd_oobtest: written up to eraseblock 1024 [ 434.453378] mtd_oobtest: written up to eraseblock 1280 [ 444.494321] mtd_oobtest: written up to eraseblock 1536 [ 454.534480] mtd_oobtest: written up to eraseblock 1792 [ 464.490962] mtd_oobtest: written 2047 eraseblocks [ 464.495681] mtd_oobtest: verifying all eraseblocks [ 464.518015] mtd_oobtest: verified up to eraseblock 0 [ 468.955635] mtd_oobtest: verified up to eraseblock 256 [ 473.395502] mtd_oobtest: verified up to eraseblock 512 [ 477.834373] mtd_oobtest: verified up to eraseblock 768 [ 482.272717] mtd_oobtest: verified up to eraseblock 1024 [ 486.712148] mtd_oobtest: verified up to eraseblock 1280 [ 491.150704] mtd_oobtest: verified up to eraseblock 1536 [ 495.589439] mtd_oobtest: verified up to eraseblock 1792 [ 499.993138] mtd_oobtest: verified 2047 eraseblocks [ 499.997951] mtd_oobtest: test 3 of 5 [ 503.404228] mtd_oobtest: writing OOBs of whole device [ 503.448822] mtd_oobtest: written up to eraseblock 0 [ 513.480773] mtd_oobtest: written up to eraseblock 256 [ 523.489361] mtd_oobtest: written up to eraseblock 512 [ 533.506896] mtd_oobtest: written up to eraseblock 768 [ 543.506268] mtd_oobtest: written up to eraseblock 1024 [ 553.506503] mtd_oobtest: written up to eraseblock 1280 [ 563.511266] mtd_oobtest: written up to eraseblock 1536 [ 573.519567] mtd_oobtest: written up to eraseblock 1792 [ 583.455111] mtd_oobtest: written 2047 eraseblocks [ 583.459837] mtd_oobtest: verifying all eraseblocks [ 583.499358] mtd_oobtest: verified up to eraseblock 0 [ 592.382953] mtd_oobtest: verified up to eraseblock 256 [ 601.267297] mtd_oobtest: verified up to eraseblock 512 [ 610.150907] mtd_oobtest: verified up to eraseblock 768 [ 619.034702] mtd_oobtest: verified up to eraseblock 1024 [ 627.919683] mtd_oobtest: verified up to eraseblock 1280 [ 636.821168] mtd_oobtest: verified up to eraseblock 1536 [ 645.705487] mtd_oobtest: verified up to eraseblock 1792 [ 654.520336] mtd_oobtest: verified 2047 eraseblocks [ 654.525134] mtd_oobtest: test 4 of 5 [ 657.578146] mtd_oobtest: attempting to start write past end of OOB [ 657.584336] mtd_oobtest: an error is expected... [ 657.588974] mtd_oobtest: error occurred as expected [ 657.593848] mtd_oobtest: attempting to start read past end of OOB [ 657.599953] mtd_oobtest: an error is expected... [ 657.604569] mtd_oobtest: error occurred as expected [ 657.609450] mtd_oobtest: attempting to write past end of device [ 657.615367] mtd_oobtest: an error is expected... [ 657.619990] mtd_oobtest: error occurred as expected [ 657.624864] mtd_oobtest: attempting to read past end of device [ 657.630715] mtd_oobtest: an error is expected... [ 657.635333] mtd_oobtest: error occurred as expected [ 657.641043] mtd_oobtest: attempting to write past end of device [ 657.646966] mtd_oobtest: an error is expected... [ 657.651574] mtd_oobtest: error occurred as expected [ 657.656451] mtd_oobtest: attempting to read past end of device [ 657.662277] mtd_oobtest: an error is expected... [ 657.666901] mtd_oobtest: error occurred as expected [ 657.671774] mtd_oobtest: test 5 of 5 [ 659.382333] mtd_oobtest: writing OOBs of whole device [ 659.388056] mtd_oobtest: written up to eraseblock 0 [ 659.393526] mtd_oobtest: written up to eraseblock 0 [ 659.704525] mtd_oobtest: written up to eraseblock 256 [ 659.710187] mtd_oobtest: written up to eraseblock 256 [ 660.021093] mtd_oobtest: written up to eraseblock 512 [ 660.026752] mtd_oobtest: written up to eraseblock 512 [ 660.338427] mtd_oobtest: written up to eraseblock 768 [ 660.344048] mtd_oobtest: written up to eraseblock 768 [ 660.655718] mtd_oobtest: written up to eraseblock 1024 [ 660.661462] mtd_oobtest: written up to eraseblock 1024 [ 660.970676] mtd_oobtest: written up to eraseblock 1280 [ 660.976386] mtd_oobtest: written up to eraseblock 1280 [ 661.286858] mtd_oobtest: written up to eraseblock 1536 [ 661.292587] mtd_oobtest: written up to eraseblock 1536 [ 661.605397] mtd_oobtest: written up to eraseblock 1792 [ 661.611142] mtd_oobtest: written up to eraseblock 1792 [ 661.918754] mtd_oobtest: written 2046 eraseblocks [ 661.923458] mtd_oobtest: verifying all eraseblocks [ 661.928812] mtd_oobtest: verified up to eraseblock 0 [ 662.072499] mtd_oobtest: verified up to eraseblock 256 [ 662.216152] mtd_oobtest: verified up to eraseblock 512 [ 662.359956] mtd_oobtest: verified up to eraseblock 768 [ 662.503238] mtd_oobtest: verified up to eraseblock 1024 [ 662.646847] mtd_oobtest: verified up to eraseblock 1280 [ 662.790603] mtd_oobtest: verified up to eraseblock 1536 [ 662.934269] mtd_oobtest: verified up to eraseblock 1792 [ 663.076329] mtd_oobtest: verified 2046 eraseblocks [ 663.081114] mtd_oobtest: finished with 0 errors [ 663.085647] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_pagetest.ko dev=1 [ 1142.213082] [ 1142.214590] ================================================= [ 1142.220433] mtd_pagetest: MTD device: 1 [ 1142.224278] mtd_pagetest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1142.238388] mtd_test: scanning for bad eraseblocks [ 1142.243536] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1142.248935] mtd_pagetest: erasing whole device [ 1143.962562] mtd_pagetest: erased 2047 eraseblocks [ 1143.967301] mtd_pagetest: writing whole device [ 1144.011729] mtd_pagetest: written up to eraseblock 0 [ 1154.137933] mtd_pagetest: written up to eraseblock 256 [ 1164.265201] mtd_pagetest: written up to eraseblock 512 [ 1174.393365] mtd_pagetest: written up to eraseblock 768 [ 1184.525700] mtd_pagetest: written up to eraseblock 1024 [ 1194.650920] mtd_pagetest: written up to eraseblock 1280 [ 1204.773676] mtd_pagetest: written up to eraseblock 1536 [ 1214.896934] mtd_pagetest: written up to eraseblock 1792 [ 1224.942600] mtd_pagetest: written 2047 eraseblocks [ 1224.947410] mtd_pagetest: verifying all eraseblocks [ 1225.053133] mtd_pagetest: verified up to eraseblock 0 [ 1250.760034] mtd_pagetest: verified up to eraseblock 256 [ 1276.448242] mtd_pagetest: verified up to eraseblock 512 [ 1302.138825] mtd_pagetest: verified up to eraseblock 768 [ 1327.824020] mtd_pagetest: verified up to eraseblock 1024 [ 1353.532178] mtd_pagetest: verified up to eraseblock 1280 [ 1379.234385] mtd_pagetest: verified up to eraseblock 1536 [ 1404.943865] mtd_pagetest: verified up to eraseblock 1792 [ 1430.468816] mtd_pagetest: verified 2047 eraseblocks [ 1430.473702] mtd_pagetest: crosstest [ 1430.477717] mtd_pagetest: reading page at 0x0 [ 1430.482328] mtd_pagetest: reading page at 0xffdf800 [ 1430.487469] mtd_pagetest: reading page at 0x0 [ 1430.492084] mtd_pagetest: verifying pages read at 0x0 match [ 1430.497668] mtd_pagetest: crosstest ok [ 1430.501409] mtd_pagetest: erasecrosstest [ 1430.505323] mtd_pagetest: erasing block 0 [ 1430.511511] mtd_pagetest: writing 1st page of block 0 [ 1430.517166] mtd_pagetest: reading 1st page of block 0 [ 1430.522505] mtd_pagetest: verifying 1st page of block 0 [ 1430.527739] mtd_pagetest: erasing block 0 [ 1430.532565] mtd_pagetest: writing 1st page of block 0 [ 1430.538229] mtd_pagetest: erasing block 2046 [ 1430.544181] mtd_pagetest: reading 1st page of block 0 [ 1430.549498] mtd_pagetest: verifying 1st page of block 0 [ 1430.554718] mtd_pagetest: erasecrosstest ok [ 1430.558900] mtd_pagetest: erasetest [ 1430.562381] mtd_pagetest: erasing block 0 [ 1430.567208] mtd_pagetest: writing 1st page of block 0 [ 1430.572858] mtd_pagetest: erasing block 0 [ 1430.577680] mtd_pagetest: reading 1st page of block 0 [ 1430.582990] mtd_pagetest: verifying 1st page of block 0 is all 0xff [ 1430.589279] mtd_pagetest: erasetest ok [ 1430.593023] mtd_pagetest: finished with 0 errors [ 1430.597651] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_readtest.ko dev=1 [ 1478.691648] [ 1478.693158] ================================================= [ 1478.698981] mtd_readtest: MTD device: 1 [ 1478.702829] mtd_readtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1478.716939] mtd_test: scanning for bad eraseblocks [ 1478.722072] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1478.727475] mtd_readtest: testing page read [ 1548.352125] mtd_readtest: finished [ 1548.355553] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_speedtest.ko dev=1 [ 1617.353002] [ 1617.354511] ================================================= [ 1617.360332] mtd_speedtest: MTD device: 1 [ 1617.364258] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1617.380150] mtd_test: scanning for bad eraseblocks [ 1617.385428] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1621.021861] mtd_speedtest: testing eraseblock write speed [ 1700.915306] mtd_speedtest: eraseblock write speed is 3279 KiB/s [ 1700.921250] mtd_speedtest: testing eraseblock read speed [ 1734.931886] mtd_speedtest: eraseblock read speed is 7705 KiB/s [ 1738.682742] mtd_speedtest: testing page write speed [ 1818.818644] mtd_speedtest: page write speed is 3269 KiB/s [ 1818.824058] mtd_speedtest: testing page read speed [ 1852.913595] mtd_speedtest: page read speed is 7687 KiB/s [ 1856.674492] mtd_speedtest: testing 2 page write speed [ 1936.437284] mtd_speedtest: 2 page write speed is 3285 KiB/s [ 1936.442869] mtd_speedtest: testing 2 page read speed [ 1970.498124] mtd_speedtest: 2 page read speed is 7694 KiB/s [ 1970.503624] mtd_speedtest: Testing erase speed [ 1974.343389] mtd_speedtest: erase speed is 68316 KiB/s [ 1974.348479] mtd_speedtest: Testing 2x multi-block erase speed [ 1976.068855] mtd_speedtest: 2x multi-block erase speed is 152811 KiB/s [ 1976.075309] mtd_speedtest: Testing 4x multi-block erase speed [ 1977.790232] mtd_speedtest: 4x multi-block erase speed is 153301 KiB/s [ 1977.796693] mtd_speedtest: Testing 8x multi-block erase speed [ 1979.511905] mtd_speedtest: 8x multi-block erase speed is 153273 KiB/s [ 1979.518367] mtd_speedtest: Testing 16x multi-block erase speed [ 1981.230700] mtd_speedtest: 16x multi-block erase speed is 153539 KiB/s [ 1981.237249] mtd_speedtest: Testing 32x multi-block erase speed [ 1982.948381] mtd_speedtest: 32x multi-block erase speed is 153648 KiB/s [ 1982.954918] mtd_speedtest: Testing 64x multi-block erase speed [ 1984.665992] mtd_speedtest: 64x multi-block erase speed is 153655 KiB/s [ 1984.672531] mtd_speedtest: finished [ 1984.676054] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_stresstest.ko dev=1 [ 2190.651750] [ 2190.653263] ================================================= [ 2190.659087] mtd_stresstest: MTD device: 1 [ 2190.663105] mtd_stresstest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 2190.679846] mtd_test: scanning for bad eraseblocks [ 2190.684981] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 2190.690389] mtd_stresstest: doing operations [ 2190.694655] mtd_stresstest: 0 operations done [ 2214.262705] mtd_stresstest: 1024 operations done [ 2239.019612] mtd_stresstest: 2048 operations done [ 2262.820899] mtd_stresstest: 3072 operations done [ 2285.061376] mtd_stresstest: 4096 operations done [ 2308.297322] mtd_stresstest: 5120 operations done [ 2330.530459] mtd_stresstest: 6144 operations done [ 2352.651759] mtd_stresstest: 7168 operations done [ 2375.188275] mtd_stresstest: 8192 operations done [ 2397.738174] mtd_stresstest: 9216 operations done [ 2414.792572] mtd_stresstest: finished, 10000 operations done [ 2414.798257] ================================================= Speed test of original driver (with patch to fix support of flashes with more than one plane per lun) root@OpenWrt:/lib/modules/6.6.79# insmod mtd_speedtest.ko dev=1 [ 2894.142208] [ 2894.143719] ================================================= [ 2894.149556] mtd_speedtest: MTD device: 1 [ 2894.153486] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 2894.168888] mtd_test: scanning for bad eraseblocks [ 2894.174023] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 2897.500416] mtd_speedtest: testing eraseblock write speed [ 2977.807233] mtd_speedtest: eraseblock write speed is 3262 KiB/s [ 2977.813171] mtd_speedtest: testing eraseblock read speed [ 3013.906597] mtd_speedtest: eraseblock read speed is 7260 KiB/s [ 3017.440320] mtd_speedtest: testing page write speed [ 3097.833394] mtd_speedtest: page write speed is 3259 KiB/s [ 3097.838812] mtd_speedtest: testing page read speed [ 3134.004981] mtd_speedtest: page read speed is 7245 KiB/s [ 3137.538423] mtd_speedtest: testing 2 page write speed [ 3217.906288] mtd_speedtest: 2 page write speed is 3260 KiB/s [ 3217.911883] mtd_speedtest: testing 2 page read speed [ 3254.049757] mtd_speedtest: 2 page read speed is 7251 KiB/s [ 3254.055254] mtd_speedtest: Testing erase speed [ 3257.599146] mtd_speedtest: erase speed is 74027 KiB/s [ 3257.604213] mtd_speedtest: Testing 2x multi-block erase speed [ 3259.320945] mtd_speedtest: 2x multi-block erase speed is 153139 KiB/s [ 3259.327413] mtd_speedtest: Testing 4x multi-block erase speed [ 3261.044585] mtd_speedtest: 4x multi-block erase speed is 153098 KiB/s [ 3261.051047] mtd_speedtest: Testing 8x multi-block erase speed [ 3262.786520] mtd_speedtest: 8x multi-block erase speed is 151479 KiB/s [ 3262.792979] mtd_speedtest: Testing 16x multi-block erase speed [ 3264.509898] mtd_speedtest: 16x multi-block erase speed is 153130 KiB/s [ 3264.516454] mtd_speedtest: Testing 32x multi-block erase speed [ 3266.233403] mtd_speedtest: 32x multi-block erase speed is 153125 KiB/s [ 3266.239961] mtd_speedtest: Testing 64x multi-block erase speed [ 3267.957985] mtd_speedtest: 64x multi-block erase speed is 153029 KiB/s [ 3267.964525] mtd_speedtest: finished [ 3267.968039] ================================================= It looks like a patched driver is a bit faster write speed: 3260 KiB/s vs 3277 KiB/s read speed: 7252 KiB/s vs 7695 KiB/s
2025-10-17spi: aspeed: Fix an IS_ERR() vs NULL bug in probe()Dan Carpenter
The platform_get_resource() function doesn't return error pointers, it returns NULL on error. Update the error checking to match. Fixes: 64d87ccfae33 ("spi: aspeed: Only map necessary address window region") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aPJpEnfK31pHz8_w@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-17HID: intel-ish-hid: ipc: Separate hibernate callbacks in dev_pm_opsZhang Lixu
The same suspend and resume callbacks are used for both suspend-to-RAM/idle and hibernation. These callbacks invoke pm_suspend_via_firmware() and pm_resume_via_firmware(), respectively. In the .freeze() of hibernation, pm_suspend_via_firmware() returns false, causing the driver to put ISH into D0i3. However, during the .thaw(), pm_resume_via_firmware() returns true, leading the driver to treat ISH as resuming from D3 instead of D0i3. The asymmetric behavior between .freeze() and .thaw() during hibernation can cause the client connection states on the firmware side and the driver side to become inconsistent. To address the inconsistent client connection states issue, separate hibernate-related callbacks (freeze, thaw) in dev_pm_ops. Since ISH does not need to save any firmware-related state when entering hibernation, it is sufficient to call pci_save_state() in .freeze() to prevent the PCI bus from changing the ISH power state. No actions are required in .thaw(). Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Use IPC RESET instead of void message in ish_wakeup()Zhang Lixu
On ISH power-up, the bootloader enters sleep after preparing to load the main firmware, waiting for the driver to be ready. When the driver is ready, it sends a void message to wake up the bootloader and load the main firmware. The main firmware then sends MNG_RESET_NOTIFY to the driver for handshake. This void message-based IPC handshake only works if the main firmware has not been loaded. During hibernation resume, if the restore kernel has the ISH driver, the driver wakes up the bootloader to load the main firmware and perform IPC handshake. However, when switching to the image kernel, since the main firmware is already loaded, sending a void message in the .restore() callback does not trigger IPC handshake. By sending MNG_RESET_NOTIFY (IPC RESET message) in ish_wakeup() instead of a void message, we can explicitly wake up the bootloader and perform IPC handshake, regardless of the firmware state. Additionally, since ish_ipc_reset() already waits for recvd_hw_ready, the redundant wait for recvd_hw_ready in ish_hw_start() is removed. The timeout for waiting for HW ready is set to 10 seconds, matching the original timeout value used in ish_wakeup(), to ensure reliable wakeup on hardware that requires more time, such as the Lenovo ThinkPad X1 Titanium Gen 1. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: ipc: Always schedule FW reset work on RESET_NOTIFY/ACKZhang Lixu
Both ISH firmware and driver can actively send MNG_RESET_NOTIFY to initiate an FW reset handshake. Upon receiving this, the peer should reply with MNG_RESET_NOTIFY_ACK. Therefore, the driver should schedule the FW reset handshake work function when receiving either MNG_RESET_NOTIFY or MNG_RESET_NOTIFY_ACK. Previously, driver only scheduled the work function on MNG_RESET_NOTIFY. This patch ensures the work function is scheduled on both messages, but only replies with MNG_RESET_NOTIFY_ACK when receiving MNG_RESET_NOTIFY. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-ipc: Reset clients state on resume from D3Zhang Lixu
When ISH resumes from D3, the connection between ishtp clients and firmware is lost. The ish_resume() function schedules resume_work asynchronously to re-initiate the connection and then returns immediately. This can cause a race where the upper-layer ishtp client driver's .resume() may execute before the connection is fully restored, leaving the client in a stale connected state. If the client sends messages during this window, the firmware cannot respond. To avoid this, reset the ishtp clients' state before returning from ish_resume() if ISH is resuming from D3. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ishtp-hid: Clear suspended flag only after connected on resumeZhang Lixu
When resuming from suspend-to-RAM or hibernate, the ISH firmware is powered on from D3, causing all previous client connections between the firmware and driver to be lost. Although the underlying ishtp bus driver initiates a client reconnection flow, this process is asynchronous. As a result, when hid_ishtp_cl_resume_handler() is executed, the connection may not have been re-established yet. Clearing the suspended flag prematurely in this scenario can lead to a timeout when the upper-layer HID sensor driver set feature during resume. To prevent such timeouts, only clear the suspended flag after confirming that the connection state is ISHTP_CL_CONNECTED. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Add ishtp_get_connection_state() interfaceZhang Lixu
Add the ishtp_get_connection_state() function for struct ishtp_cl, allowing ishtp client drivers to retrieve the current connection state. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blockingZhang Lixu
During suspend/resume tests with S2IDLE, some ISH functional failures were observed because of delay in executing ISH resume handler. Here schedule_work() is used from resume handler to do actual work. schedule_work() uses system_wq, which is a per CPU work queue. Although the queuing is not bound to a CPU, but it prefers local CPU of the caller, unless prohibited. Users of this work queue are not supposed to queue long running work. But in practice, there are scenarios where long running work items are queued on other unbound workqueues, occupying the CPU. As a result, the ISH resume handler may not get a chance to execute in a timely manner. In one scenario, one of the ish_resume_handler() executions was delayed nearly 1 second because another work item on an unbound workqueue occupied the same CPU. This delay causes ISH functionality failures. A similar issue was previously observed where the ISH HID driver timed out while getting the HID descriptor during S4 resume in the recovery kernel, likely caused by the same workqueue contention problem. Create dedicated unbound workqueues for all ISH operations to allow work items to execute on any available CPU, eliminating CPU-specific bottlenecks and improving resume reliability under varying system loads. Also ISH has three different components, a bus driver which implements ISH protocols, a PCI interface layer and HID interface. Use one dedicated work queue for all of them. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17Merge tag 'block-6.18-20251016' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - NVMe pull request via Keith: - iostats accounting fixed on multipath retries (Amit) - secure concatenation response fixup (Martin) - tls partial record fixup (Wilfred) - Fix for a lockdep reported issue with the elevator lock and blk group frozen operations - Fix for a regression in this merge window, where updating 'nr_requests' would not do the right thing for queues with shared tags * tag 'block-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: nvme/tcp: handle tls partially sent records in write_space() block: Remove elevator_lock usage from blkg_conf frozen operations blk-mq: fix stale tag depth for shared sched tags in blk_mq_update_nr_requests() nvme-auth: update sc_c in host response nvme-multipath: Skip nr_active increments in RETRY disposition
2025-10-17Merge tag 'mmc-v6.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull mmc cleanup from Ulf Hansson: "Move rpmb_frame struct and constants to rpmb common header This helps us to avoid sharing an immutable branch between our git trees. I was planning to send it before rc1, but I didn't make it" * tag 'mmc-v6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: rpmb: move rpmb_frame struct and constants to common header
2025-10-17Merge tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "As per usual xe/amdgpu are the leaders, with some i915 and then a bunch of scattered fixes. There are a bunch of stability fixes for some older amdgpu cards. draw: - Avoid color truncation gpuvm: - Avoid kernel-doc warning sched: - Avoid double free i915: - Skip GuC communication warning if reset is in progress - Couple frontbuffer related fixes - Deactivate PSR only on LNL and when selective fetch enabled xe: - Increase global invalidation timeout to handle some workloads - Fix NPD while evicting BOs in an array of VM binds - Fix resizable BAR to account for possibly needing to move BARs other than the LMEMBAR - Fix error handling in xe_migrate_init() - Fix atomic fault handling with mixed mappings or if the page is already in VRAM - Enable media samplers power gating for platforms before Xe2 - Fix de-registering exec queue from GuC when unbinding - Ensure data migration to system if indicated by madvise with SVM - Fix kerneldoc for kunit change - Always account for cacheline alignment on migration - Drop bogus assertion on eviction amdgpu: - Backlight fix - SI fixes - CIK fix - Make CE support debug only - IP discovery fix - Ring reset fixes - GPUVM fault memory barrier fix - Drop unused structures in amdgpu_drm.h - JPEG debugfs fix - VRAM handling fixes for GPUs without VRAM - GC 12 MES fixes amdkfd: - MES fix ast: - Fix display output after reboot bridge: - lt9211: Fix version check panthor: - Fix MCU suspend qaic: - Init bootlog in correct order - Treat remaining == 0 as error in find_and_map_user_pages() - Lock access to DBC request queue rockchip: - vop2: Fix destination size in atomic check" * tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernel: (44 commits) drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies drm/xe/evict: drop bogus assert drm/xe/migrate: don't misalign current bytes drm/xe/kunit: Fix kerneldoc for parameterized tests drm/xe/svm: Ensure data will be migrated to system if indicated by madvise. drm/gpuvm: Fix kernel-doc warning for drm_gpuvm_map_req.map drm/i915/psr: Deactivate PSR only on LNL and when selective fetch enabled drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off accel/qaic: Synchronize access to DBC request queue head & tail pointer accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() accel/qaic: Fix bootlog initialization ordering drm/rockchip: vop2: use correct destination rectangle height check drm/draw: fix color truncation in drm_draw_fill24 drm/xe/guc: Check GuC running state before deregistering exec queue drm/xe: Enable media sampler power gating drm/xe: Handle mixed mappings and existing VRAM on atomic faults drm/xe/migrate: Fix an error path drm/xe: Move rebar to be done earlier drm/xe: Don't allow evicting of BOs in same VM in array of VM binds drm/xe: Increase global invalidation timeout to 1000us ...
2025-10-17drm/xe/pf: Allow to restore auto-provisioning modeMichal Wajdeczko
After doing tweaks to the VFs provisioning we may want to restore back the auto-provisioning mode. Allow that unless VFs are still enabled. This can be also used to release all VFs resources. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-5-michal.wajdeczko@intel.com
2025-10-17Merge tag 'i2c-for-6.18-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: - PM cleanup after all prerequisites are merged with rc1 - usbio: missing addition after all dependencies are in - slimpro: DT binding schema conversion * tag 'i2c-for-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: dt-bindings: i2c: Convert apm,xgene-slimpro-i2c to DT schema i2c: usbio: Add ACPI device-id for MTL-CVF devices i2c: Remove redundant pm_runtime_mark_last_busy() calls
2025-10-17drm/xe/pf: Disable auto-provisioning if changed using debugfsMichal Wajdeczko
When we attempt to tweak VFs configurations using debugfs, stop assuming that VFs need auto-(un)provisioning. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-4-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Automatically provision VFs only in auto-modeMichal Wajdeczko
We shouldn't attempt to auto-provision VFs once we allow other provisioning methods. Make the code aware of the new condition. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-3-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Promote VFs provisioning helpersMichal Wajdeczko
As we plan to add more VFs provisioning methods, start moving related code into single place. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-2-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Always expose VRAM provisioning data on discrete GPUsLukasz Laguna
Currently, VRAM provisioning data is only exposed if the device supports LMTT. While it should not be possible to modify VRAM provisioning on platforms without LMTT, it is still useful to be able to read the VRAM provisioning data on all discrete GPU platforms. Expose the VRAM debugfs attributes whenever running on dGFX, adjusting file permissions to read only when LMTT is not available. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251016122233.3789-1-lukasz.laguna@intel.com
2025-10-17hwmon: (corsair-psu) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (corsair-psu) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (chipcap2) Drop unnecessary include filesGuenter Roeck
The driver does not perform any locking, does not execute or use any sleep related functionality, and does not allocate memory. Drop the unnecessary include files. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (asus_rog_ryujin) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (i5500_temp) Drop unnecessary include filesGuenter Roeck
The driver does not perform any locking, does not execute or use any sleep related functionality, and does not allocate memory. Drop the unnecessary include files. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (gpd-fan) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (aquacomputer_d5next) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ltc4282) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17hwmon: (lochnagar-hwmon) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (sfctemp) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (adt7x10) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17hwmon: (peci) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (ltc2947-core) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17hwmon: (adt7411) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
2025-10-17PCI/VGA: Select SCREEN_INFO on X86Mario Limonciello (AMD)
commit 337bf13aa9dda ("PCI/VGA: Replace vga_is_firmware_default() with a screen info check") introduced an implicit dependency upon SCREEN_INFO by removing the open coded implementation. If a user didn't have CONFIG_SCREEN_INFO set, vga_is_firmware_default() would now return false. SCREEN_INFO is only used on X86 so add a conditional select for SCREEN_INFO to ensure that the VGA arbiter works as intended. Fixes: 337bf13aa9dda ("PCI/VGA: Replace vga_is_firmware_default() with a screen info check") Reported-by: Eric Biggers <ebiggers@kernel.org> Closes: https://lore.kernel.org/linux-pci/20251012182302.GA3412@sol/ Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20251013220829.1536292-1-superm1@kernel.org
2025-10-17PCI: vmd: Override irq_startup()/irq_shutdown() in vmd_init_dev_msi_info()Inochi Amaoto
Since commit 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per device domains") set callback irq_startup() and irq_shutdown() of the struct pci_msi[x]_template, __irq_startup() will always invokes irq_startup() callback instead of irq_enable() callback overridden in vmd_init_dev_msi_info(). This will not start the IRQ correctly. Also override irq_startup()/irq_shutdown() in vmd_init_dev_msi_info(), so the irq_startup() can invoke the real logic. Fixes: 54f45a30c0d0 ("PCI/MSI: Add startup/shutdown for per device domains") Reported-by: Kenneth Crudup <kenny@panix.com> Closes: https://lore.kernel.org/r/8a923590-5b3a-406f-a324-7bd1cf894d8f@panix.com/ Reported-by: Genes Lists <lists@sapience.com> Closes: https://lore.kernel.org/r/4b392af8847cc19720ffcd53865f60ab3edc56b3.camel@sapience.com Reported-by: Todd Brandt <todd.e.brandt@intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220658 Reported-by: Oliver Hartkopp <socketcan@hartkopp.net> Closes: https://lore.kernel.org/r/8d6887a5-60bc-423c-8f7a-87b4ab739f6a@hartkopp.net Reported-by: Hervé <herve@dxcv.net> Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Kenneth R. Crudup <kenny@panix.com> Tested-by: Genes Lists <lists@sapience.com> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Tested-by: Hervé <herve@dxcv.net> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251014014607.612586-1-inochiama@gmail.com
2025-10-17Merge tag 'tee-qcomtee-fixes-for-v6.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes TEE QTEE fixes for v6.18 - Adds ARCH_QCOM dependency for the QTEE driver - Fixing return values for copy_from_user() failures - Guarding against potential off by one read * tag 'tee-qcomtee-fixes-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: QCOMTEE should depend on ARCH_QCOM tee: qcom: return -EFAULT instead of -EINVAL if copy_from_user() fails tee: qcom: prevent potential off by one read
2025-10-17Merge tag 'zynqmp-soc-for-6.18' of https://github.com/Xilinx/linux-xlnx into ↵Arnd Bergmann
soc/drivers arm64: Xilinx SOC changes for 6.18 firmware: - Add debugfs interface - Wire versal-net compatible string - Change SOC family detection * tag 'zynqmp-soc-for-6.18' of https://github.com/Xilinx/linux-xlnx: drivers: firmware: xilinx: Switch to new family code in zynqmp_pm_get_family_info() drivers: firmware: xilinx: Add unique family code for all platforms firmware: xilinx: Add Versal NET platform compatible string firmware: xilinx: Add debugfs support for PM_GET_NODE_STATUS
2025-10-17irqchip/qcom-irq-combiner: Rename driver structureJohan Hovold
The "_probe" suffix of the driver structure name prevents modpost from warning about section mismatches so replace it to catch any future issues like the recently fixed probe function being incorrectly marked as __init. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2025-10-17can: m_can: m_can_get_berr_counter(): don't wake up controller if interface ↵Marc Kleine-Budde
is down If the interface is down, the CAN controller might be powered down, the clock disabled, and/or it's external reset asserted. Don't wake up the controller to read the CAN bus error counters, if the interface is down. Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-7-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: m_can_tx_submit(): remove unneeded sanity checksMarc Kleine-Budde
m_can_tx_submit() is only called for peripheral devices. So remove the sanity check. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-6-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: m_can_class_register(): remove error message in case ↵Marc Kleine-Budde
devm_kzalloc() fails If devm_kzalloc() fails, it already outputs an error message. Remove the error message from m_can_class_register() accordingly. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-5-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-17can: m_can: m_can_interrupt_enable(): use m_can_write() instead of open ↵Marc Kleine-Budde
coding it As everywhere else in the driver, use m_can_write() instead of open coding it. Link: https://patch.msgid.link/20251008-m_can-cleanups-v1-4-1784a18eaa84@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-05 01:56:30 +0000