summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-03drm/rockchip: include drm_print.h where neededJani Nikula
rockchip_drm_vop2.c depends on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. Include drm_print.h explicitly. Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Closes: https://lore.kernel.org/r/9c67c29b-06e9-469b-9273-eaac368632d6@suse.de Fixes: f6e8dc9edf96 ("drm: include drm_print.h where needed") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/59277a2dd7939ef5fe6e8fc61311873775141ef8.1762161597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-03drm/renesas: include drm_print.h where neededJani Nikula
rzg2l_du_drv.c depends on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. Include drm_print.h explicitly. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20251103112418.031b3f8c@canb.auug.org.au Fixes: f6e8dc9edf96 ("drm: include drm_print.h where needed") Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/04f617d5fe37f92d750efbb73065df3997f5c6b5.1762161597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-03modules: add rust modules files to MAINTAINERSAndreas Hindborg
The module subsystem people agreed to maintain rust support for modules [1]. Thus, add entries for relevant files to modules entry in MAINTAINERS. Link: https://lore.kernel.org/all/0d9e596a-5316-4e00-862b-fd77552ae4b5@suse.com/ [1] Acked-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Daniel Gomez <da.gomez@kernel.org>
2025-11-03rust: samples: add a module parameter to the rust_minimal sampleAndreas Hindborg
Showcase the rust module parameter support by adding a module parameter to the `rust_minimal` sample. Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Daniel Gomez <da.gomez@kernel.org>
2025-11-03rust: module: update the module macro with module parameter supportAndreas Hindborg
Allow module parameters to be declared in the rust `module!` macro. Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Daniel Gomez <da.gomez@kernel.org>
2025-11-03rust: module: use a reference in macros::module::moduleAndreas Hindborg
When we add parameter support to the module macro, we want to be able to pass a reference to `ModuleInfo` to a helper function. That is not possible when we move out of the local `modinfo`. So change the function to access the local via reference rather than value. Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Daniel Gomez <da.gomez@kernel.org>
2025-11-03rust: introduce module_param moduleAndreas Hindborg
Add types and traits for interfacing the C moduleparam API. Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Daniel Gomez <da.gomez@kernel.org>
2025-11-03rust: str: add radix prefixed integer parsing functionsAndreas Hindborg
Add the trait `ParseInt` for parsing string representations of integers where the string representations are optionally prefixed by a radix specifier. Implement the trait for the primitive integer types. Suggested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Daniel Gomez <da.gomez@samsung.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Daniel Gomez <da.gomez@kernel.org>
2025-11-03rust: sync: add `SetOnce`Andreas Hindborg
Introduce the `SetOnce` type, a container that can only be written once. The container uses an internal atomic to synchronize writes to the internal value. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Tested-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Daniel Gomez <da.gomez@kernel.org>
2025-11-03rtc: sh: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20251101-max_user_freq-v1-11-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: rx8025: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-10-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: rx8010: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-9-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: rx6110: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-8-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: rv8803: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-7-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: rv3032: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-6-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: rv3028: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-5-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: renesas-rtca3: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20251101-max_user_freq-v1-4-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: pic32: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-3-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: ds1685: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Acked-by: Joshua Kinard <linux@kumba.dev> Link: https://patch.msgid.link/20251101-max_user_freq-v1-2-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03rtc: sa1100: stop setting max_user_freqAlexandre Belloni
max_user_freq has not been related to the hardware RTC since commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop setting it from individual driver to avoid confusing new contributors. Link: https://patch.msgid.link/20251101-max_user_freq-v1-1-c9a274fd6883@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03perf/arm_cspmu: nvidia: Add pmevfiltr2 supportBesar Wicaksono
Support NVIDIA PMU that utilizes the optional event filter2 register. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-03perf/arm_cspmu: nvidia: Add revision id matchingBesar Wicaksono
Distinguish NVIDIA devices by revision and variant bits in PMIIDR register in addition to product id. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-03perf/arm_cspmu: Add pmpidr supportBesar Wicaksono
The PMIIDR value is composed by the values in PMPIDR registers. We can use PMPIDR registers as alternative for device identification for systems that do not implement PMIIDR. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-03perf/arm_cspmu: Add callback to reset filter configBesar Wicaksono
Implementer may need to reset a filter config when stopping a counter, thus adding a callback for this. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-03rtc: amlogic-a4: simplify probeAlexandre Belloni
Use devm_device_init_wakeup to simplify probe and remove .remove as it is now empty. Also remove the unnecessary error string as there are no error path without an error message in devm_rtc_register_device. Reviewed-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20251031204724.756857-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-11-03perf: arm_pmuv3: Don't use PMCCNTR_EL0 on SMT coresYicong Yang
CPU_CYCLES is expected to count the logical CPU (PE) clock. Currently it's preferred to use PMCCNTR_EL0 for counting CPU_CYCLES, but it'll count processor clock rather than the PE clock (ARM DDI0487 L.b D13.1.3) if one of the SMT siblings is not idle on a multi-threaded implementation. So don't use it on SMT cores. Introduce topology_core_has_smt() for knowing the SMT implementation and cached it in arm_pmu::has_smt during allocation. When counting cycles on SMT CPU 2-3 and CPU 3 is idle, without this patch we'll get: [root@client1 tmp]# perf stat -e cycles -A -C 2-3 -- stress-ng -c 1 --taskset 2 --timeout 1 [...] Performance counter stats for 'CPU(s) 2-3': CPU2 2880457316 cycles CPU3 2880459810 cycles 1.254688470 seconds time elapsed With this patch the idle state of CPU3 is observed as expected: [root@client1 ~]# perf stat -e cycles -A -C 2-3 -- stress-ng -c 1 --taskset 2 --timeout 1 [...] Performance counter stats for 'CPU(s) 2-3': CPU2 2558580492 cycles CPU3 305749 cycles 1.113626410 seconds time elapsed Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-03drm/imagination: Optionally depend on POWER_SEQUENCINGMatt Coster
When the change using pwrseq was added, I nixed the dependency on POWER_SEQUENCING since we didn't want it pulled in on platforms where it's not needed [1]. I hadn't, however, considered the link-time implications of this for configs with POWER_SEQUENCING=m. [1]: https://lore.kernel.org/r/a265a20e-8908-40d8-b4e0-2c8b8f773742@imgtec.com/ Fixes: e38e8391f30b ("drm/imagination: Use pwrseq for TH1520 GPU power management") Cc: stable@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202510111806.CMulNMKW-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202511011739.SONHjSfR-lkp@intel.com/ Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20251014-pwrseq-dep-v1-1-49aabd9d8fa1@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-11-03regulator: pf9453: remove unused I2C_LT registerJoy Zou
Remove unused I2C_LT registers, which not defined in PF9453 datasheet. Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://patch.msgid.link/20251103-b4-next-pf9453-v1-3-a025d536eee1@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03regulator: pf9453: remove low power modeJoy Zou
Remove low power mode support to align with the Rev.1.0 -- 25 June 2025 datasheet, which no longer support this feature. Datasheet is available at https://www.nxp.com/docs/en/data-sheet/PF9453.pdf. Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://patch.msgid.link/20251103-b4-next-pf9453-v1-2-a025d536eee1@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03regulator: pf9453: change the device ID register addressJoy Zou
Remove unnecessary register OTP_Ver and change the device ID address to 0x1. Previous version chip is never mass production. So not broken compatibility. Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://patch.msgid.link/20251103-b4-next-pf9453-v1-1-a025d536eee1@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03regulator: Small cleanup in of_get_regulation_constraints()Dan Carpenter
Just pass "init_data" instead the address of it. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aQYKoiivuec3m0Jj@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03ASoC: codecs: aw88261: pass pointer directly instead of passing the addressDan Carpenter
It's a little bit cleaner to just pass "aw88261" instead of the address of it "&aw88261". Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aQYKxl2f-zGVdYFC@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03ASoC: codecs: simplify aw87390_init() argument a bitDan Carpenter
Just pass "aw87390" instead of the address of it. It's a bit simpler. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aQYKuQuKekmoUrHP@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03ASoC: max98090/91: adding the two virtual Mux widgets in the routesSharique Mohammad
The two virtual multiplexers are now part of the alsa routing. The "DMIC M1 Mux" now sits between the primary digital mics "DMICL"/"DMICR" and the virtual multiplexer "DMIC Mux". And "DMIC M2 Mux" sits between the secondary digital mics "DMIC2L"/"DMIC2R" and the audio out interfaces "AIFOUT2L"/"AIFOUT2R". This patch makes sure that the M1 and M2 mics can be switched On/Off independently, by default both will be enabled. Signed-off-by: Sharique Mohammad <sharq0406@gmail.com> Link: https://patch.msgid.link/20251103091648.771947-1-sharq0406@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03ASoC: fsl_spdif: Constify some structuresChristophe JAILLET
'struct fsl_spdif_soc_data' and 'struct snd_kcontrol_new' are not modified in this driver. Constifying these structures moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 53548 25576 128 79252 13594 sound/soc/fsl/fsl_spdif.o After: ===== text data bss dec hex filename 54828 24296 128 79252 13594 sound/soc/fsl/fsl_spdif.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/5fe08f028395a6c6f50d11eee8fdb4a90b1f68ab.1762151503.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03ASoC: max98090/91: adding two virtual Mux widgets for digital micsSharique Mohammad
The two digital mics M1(primary digital mic) and M2(secondary digital mic) work independently of one another. It means they could be switched On or Off independently of one another. To control their On or Off state, with this patch creating two virtual multiplexer widgets "DMIC M1 Mux" and "DMIC M2 Mux", with two options "Enable" and "Disable". Signed-off-by: Sharique Mohammad <sharq0406@gmail.com> Link: https://patch.msgid.link/20251103091447.771793-1-sharq0406@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03ASoC: doc: cs35l56: Update firmware filename description for B0 siliconRichard Fitzgerald
Update the text for firmware file naming to show that the l?u? suffix is supported on CS35L56 B0 silicon and ampN was only used on early firmware. The previous version of this text only said that B0 silicon used the ampN suffix. Since kernel 6.16 the driver supports both the old ampN and new l?u? suffix for B0 silicon. New firmwares will use the l?u? suffix. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20251103115809.33953-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-03firmware: stratix10-svc: fix bug in saving controller dataKhairul Anuar Romli
Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free. Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features") Cc: stable@vger.kernel.org # 6.6+ Signed-off-by: Ang Tien Sung <tiensung.ang@altera.com> Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-11-03drm/bridge: synopsys: dw-dp: add bridge before attachingLuca Ceresoli
DRM bridges should be always added to the global bridge list before being attached. Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-6-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/bridge: add warning for bridges using neither devm_drm_bridge_alloc() ↵Luca Ceresoli
nor drm_bridge_add() The correct sequence for bridge initialization is: 1. devm_drm_bridge_alloc() 2. drm_bridge_add() 3. drm_bridge_attach() For bridges missing either 1 or 2 there are warnings in place already, presenting an explanatory error message. Bridges missing both 1 and 2 would still face a poorly understandable message, as reported in a recent regression report [0]: WARNING: [...] at [...]/lib/refcount.c:25 drm_bridge_attach+0x2c/0x1dc ... Call trace: ... drm_bridge_attach ... Add a new warning to ensure an understandable message is logged in such cases. Use the same message and warning message already in place in drm_bridge_add(). [0] https://lore.kernel.org/all/hlf4wdopapxnh4rekl5s3kvoi6egaga3lrjfbx6r223ar3txri@3ik53xw5idyh/ Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-5-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/bridge: add warning for bridges attached without being addedLuca Ceresoli
DRM bridges must be added before they are attached. Add a warning to catch violations. The warning is based on the bridge not being part of any list, so it will trigger if the bridge is being attached without ever having been added. It won't catch cases of bridges attached after having been added and then removed, because in that case the bridge will be in bridge_lingering_list. However such a case is both more demanding to detect and less likely to happen, so it can be left unchecked, at least for now. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/all/20250709-sophisticated-loon-of-rain-6ccdd8@houat/ Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-4-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/bridge: document that adding a bridge is mandatory before attachLuca Ceresoli
At the moment it's not documented that you need to add a bridge before attaching it. Clarify that. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/all/20250709-sophisticated-loon-of-rain-6ccdd8@houat/ Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-3-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/sti: hdmi: add bridge before attachingLuca Ceresoli
DRM bridges should be always added to the global bridge list before being attached. Acked-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-2-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/sti: hda: add bridge before attachingLuca Ceresoli
DRM bridges should be always added to the global bridge list before being attached. Acked-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-1-bb8611acbbfb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03x86/amd_node: Fix AMD root device cachingYazen Ghannam
Recent AMD node rework removed the "search and count" method of caching AMD root devices. This depended on the value from a Data Fabric register that was expected to hold the PCI bus of one of the root devices attached to that fabric. However, this expectation is incorrect. The register, when read from PCI config space, returns the bitwise-OR of the buses of all attached root devices. This behavior is benign on AMD reference design boards, since the bus numbers are aligned. This results in a bitwise-OR value matching one of the buses. For example, 0x00 | 0x40 | 0xA0 | 0xE0 = 0xE0. This behavior breaks on boards where the bus numbers are not exactly aligned. For example, 0x00 | 0x07 | 0xE0 | 0x15 = 0x1F. The examples above are for AMD node 0. The first root device on other nodes will not be 0x00. The first root device for other nodes will depend on the total number of root devices, the system topology, and the specific PCI bus number assignment. For example, a system with 2 AMD nodes could have this: Node 0 : 0x00 0x07 0x0e 0x15 Node 1 : 0x1c 0x23 0x2a 0x31 The bus numbering style in the reference boards is not a requirement. The numbering found in other boards is not incorrect. Therefore, the root device caching method needs to be adjusted. Go back to the "search and count" method used before the recent rework. Search for root devices using PCI class code rather than fixed PCI IDs. This keeps the goal of the rework (remove dependency on PCI IDs) while being able to support various board designs. Merge helper functions to reduce code duplication. [ bp: Reflow comment. ] Fixes: 40a5f6ffdfc8 ("x86/amd_nb: Simplify root device search") Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/all/20251028-fix-amd-root-v2-1-843e38f8be2c@amd.com
2025-11-03drm/display: bridge_connector: get/put the panel_bridgeLuca Ceresoli
The panel_bridge pointer is taken inside the loop and used after the loop. Being a local variable, use a cleanup action to ensure it is put on return. Based on the code structure the panel_bridge pointer might be assigned during multiple loop iterations. Even though this is probably not possible in the practice, ensure there is no reference leak by putting the reference to the old value before overwriting with the new value. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-3-667abf6d47c0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03drm/display: bridge_connector: get/put the stored bridgesLuca Ceresoli
drm_bridge_connector_init() takes eight pointers to various bridges, some of which can be identical, and stores them in pointers inside struct drm_bridge_connector. Get a reference to each of the taken bridges and put it on cleanup. Achieve this by adding a drmm cleanup callback whic puts all the non-NULL bridges. Using drmm ensures the cleanup happens on drm_device teardown, whichever is the return value of this function. Four of these pointers (edid, hpd, detect and modes) can be written multiple times (up to once per loop iterations), in order to eventually store the last matching bridge. So when one of those pointers is overwritten, we need to put the reference that we got during the previous assignment. Add a drm_bridge_put() before writing them to handle this. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-2-667abf6d47c0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03Revert "drm/display: bridge_connector: get/put the stored bridges"Luca Ceresoli
This reverts commit 2be300f9a0b6f6b0ae2a90be97e558ec0535be54. The commit being reverted moved all the bridge_connector->bridge_* assignments to just before the final successful return in order to handle the bridge refcounting in a clean way. This introduced a bug, because a bit before the successful return drmm_connector_hdmi_cec_register() is called, which calls funcs->init() which is drm_bridge_connector_hdmi_cec_init() which needs bridge_connector->bridge_hdmi_cec to be set. The reported bug may be fixed in a relatively simple way, but other similar patterns are potentially present, so just revert the offending commit. A different approach will be implemented. Fixes: 2be300f9a0b6 ("drm/display: bridge_connector: get/put the stored bridges") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/336fbfdd-c424-490e-b5d1-8ee84043dc80@samsung.com/ Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Closes: https://lore.kernel.org/r/CA+G9fYuKHp3QgPKjgFY3TfkDdh5Vf=Ae5pCW+eU41Bu=D7th2g@mail.gmail.com Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-1-667abf6d47c0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-11-03thunderbolt: Update deprecated firmware update site in icm.cAlan Borzeszkowski
Update leftover reference to Thunderbolt firmware upgrade site (thunderbolttechnology.net) with the preferred method described in Documentation/admin-guide/thunderbolt.rst. Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-11-03thunderbolt: Update NVM firmware upgrade documentationAlan Borzeszkowski
Update guide about firmware upgrade of Thunderbolt devices, replacing outdated recommendations with the use of modern "fwupd" tool. Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
generated by cgit v1.3 (git 2.53.0) at 2026-11-06 10:53:16 +0000