summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-11-03gpio: swnode: don't use the swnode's name as the key for GPIO lookupBartosz Golaszewski
Looking up a GPIO controller by label that is the name of the software node is wonky at best - the GPIO controller driver is free to set a different label than the name of its firmware node. We're already being passed a firmware node handle attached to the GPIO device to swnode_get_gpio_device() so use it instead for a more precise lookup. Acked-by: Linus Walleij <linus.walleij@linaro.org> Fixes: e7f9ff5dc90c ("gpiolib: add support for software nodes") Link: https://lore.kernel.org/r/20251103-reset-gpios-swnodes-v4-4-6461800b6775@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
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-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-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-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-03media: imx8mq-mipi-csi2: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probing so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Martin Kepplinger-Novakovic <martink@posteo.de> Link: https://patch.msgid.link/20251017060051.8204-3-johan@kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03media: imx7-media-csi: drop unused module aliasJohan Hovold
The driver has never supported anything but OF probing so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rui Miguel Silva <rui.silva@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20251017060051.8204-2-johan@kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03media: imx-mipi-csis: drop unused module aliasJohan Hovold
The driver does not support anything but OF probe since commit f0e7cfbb43f1 ("media: imx: imx7_mipi_csis: Add i.MX8MM support") so drop the unused platform module alias. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rui Miguel Silva <rui.silva@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20251017060051.8204-1-johan@kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03media: nxp: imx8-isi: Add ISI support for i.MX91Guoniu Zhou
The ISI module on i.MX91 implements only one channel and one parallel camera input. As no input source selection is required, gasket ops are unnecessary. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20250905-isi_imx93-v2-5-37db5f768c57@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03media: nxp: imx8-isi: Reorder the platform dataGuoniu Zhou
Sort platform data in the order of compatible strings in of_match table to make it more convenient to read. No functions changed. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20250905-isi_imx93-v2-4-37db5f768c57@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03media: nxp: imx8-isi: Add parallel camera input support for i.MX93Alice Yuan
The ISI module on i.MX93 implements one camera input which can be connected to either of MIPI CSI-2 or parallel camera. The source type can be selected by setting camera mux control register. Signed-off-by: Alice Yuan <alice.yuan@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20250905-isi_imx93-v2-3-37db5f768c57@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03media: nxp: imx8-isi: Refine code by using helper macroGuoniu Zhou
Make code more readable and easier to maintain by using the FIELD_PREP and GENMASK() macros. While at it, replace spaces with tabs for macro indentation. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Link: https://patch.msgid.link/20250905-isi_imx93-v2-2-37db5f768c57@nxp.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03media: rkisp1: Improve frame sequence correctness on stats and params buffersStefan Klug
On the rkisp1 (in my case on a NXP i.MX8 M Plus) the ISP interrupt handler is sometimes called with RKISP1_CIF_ISP_V_START (start of frame) and RKISP1_CIF_ISP_FRAME (end of frame) being set at the same time. In commit 8524fa22fd2f ("media: staging: rkisp1: isp: add a warning and debugfs var for irq delay") a warning was added for that. There are two cases where this condition can occur: 1. The v-sync and the frame-end belong to the same frame. This means, the irq was heavily delayed and the warning is likely appropriate. 2. The v-sync belongs to the next frame. This can happen if the vertical blanking between two frames is very short. The current code always handles case 1 although case 2 is in my experience the more common case and happens in regular usage. This leads to incorrect sequence numbers on stats and params buffers which in turn breaks the regulation in user space. Fix that by adding a frame_active flag to distinguish between these cases and handle the start of frame either at the beginning or at the end of the rkisp1_isp_isr(). Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Link: https://patch.msgid.link/20250922182003.3712101-2-stefan.klug@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-11-03Merge tag 'iwlwifi-next-2025-10-28' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi features. Notably: - Unsupported APIs cleanup - New sniffer API - small bugfixes and features ==================== Link: https://patch.msgid.link/DM3PPF63A6024A9B77EE7385B4C865E3E54A3FDA@DM3PPF63A6024A9.namprd11.prod.outlook.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-03mtd: onenand: Pass correct pointer to IRQ handlerDan Carpenter
This was supposed to pass "onenand" instead of "&onenand" with the ampersand. Passing a random stack address which will be gone when the function ends makes no sense. However the good thing is that the pointer is never used, so this doesn't cause a problem at run time. Fixes: e23abf4b7743 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-11-03mtd: spinand: fmsh: remove QE bit for FM25S01A flashMikhail Kshevetskiy
According to datasheet (http://eng.fmsh.com/nvm/FM25S01A_ds_eng.pdf) there is no QE (Quad Enable) bit for FM25S01A flash, so remove it. Fixes: 5f284dc15ca86 ("mtd: spinand: add support for FudanMicro FM25S01A") Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Tested-by: Tianling Shen <cnsztl@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-11-03soc: samsung: exynos-chipid: use a local dev variableTudor Ambarus
Use a local variable for struct device to avoid dereferencing. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20251031-gs101-chipid-v1-2-d78d1076b210@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-11-03drm/xe/display: Use display parent interface for xe runtime pmJouni Högander
Start using display parent interface for xe runtime pm. v2: keep xe_display_rpm.c Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251030202836.1815680-7-jouni.hogander@intel.com
2025-11-03drm/i915/display: Use display parent interface for i915 runtime pmJouni Högander
Start using display parent interface for i915 runtime pm. Doing the same for xe is done in coming changes. v3: - remove useless include v2: - use <> when including drm/intel/display_parent_interface.h - drop checks for validity of rpm function pointers Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251030202836.1815680-6-jouni.hogander@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 09:34:43 +0000