- 24 Dec, 2023 10 commits
-
-
Hermes Zhang authored
The BQ24296 is most similar to the BQ24196, but the: 1. OTG config is split from CHG config (REG01) 2. ICHG (Fast Charge Current limit) range is smaller (<=3008mA) 3. NTC fault is simplified to 2 bits Signed-off-by: Hermes Zhang <chenhuiz@axis.com> Link: https://lore.kernel.org/r/20231208034708.1248389-3-Hermes.Zhang@axis.comSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Hermes Zhang authored
The BQ24296 is most similar to the BQ24196, but the: 1. OTG config is split from CHG config (REG01) 2. ICHG (Fast Charge Current limit) range is smaller (<=3008mA) 3. NTC fault is simplified to 2 bits Signed-off-by: Hermes Zhang <chenhuiz@axis.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231208034708.1248389-2-Hermes.Zhang@axis.comSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Michal Simek authored
Rename zynqmp-power node name to power-management which is more aligned with generic node name recommendation. Signed-off-by: Michal Simek <michal.simek@amd.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/920c839ae2c9c5803c6c08b8705a0d8338bb94bc.1703161663.git.michal.simek@amd.comSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Konrad Dybcio authored
Currently, a not-yet-entirely-initialized battmgr (e.g. with pd-mapper not having yet started or ADSP not being up etc.) results in a couple of zombie power supply devices hanging around. This is particularly noticeable when trying to suspend the device (even s2idle): the PSY-internal thermal zone is inaccessible and returns -ENODEV, which causes log spam. Register the power supplies only after we received some notification indicating battmgr is ready to take off. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Tested-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20231218-topic-battmgr_fixture_attempt-v1-1-6145745f34fe@linaro.orgSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Johan Hovold authored
The current PON example is a bit of a mess after converting the binding document to yaml and in the process updating parts of the example to match the pmk8350 binding while leaving parts from the older pm8998 example in place. Clean up the example and make it consistent by adding some newline separators; dropping labels; removing stray spaces; fixing the PON node name; and fixing the unit address so that it matches the interrupt specifiers (which re-encodes the PON base address, 0x800 => 0x8). Fixes: 76ba1900 ("dt-bindings: power: reset: qcom-pon: Convert qcom PON binding to yaml") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231130173017.12723-1-johan+linaro@kernel.orgSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Kunwu Chan authored
devm_kasprintf and devm_kzalloc return a pointer to dynamically allocated memory which can be NULL upon failure. Fixes: 8648aeb5 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Link: https://lore.kernel.org/r/20231124075021.1335289-1-chentao@kylinos.cnSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Nathan Chancellor authored
When building with clang, there are two section mismatch warnings: WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x7c (section: .text) -> at91_wakeup_status (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text) Drop '__init' from at91_wakeup_status() to clear up the mismatch. Fixes: dde74a5d ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()") Fixes: 099806de ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Charalampos Mitrodimas authored
This resolves checkpatch warning "quoted string split across lines" on: 1640: WARNING: quoted string split across lines 1641: WARNING: quoted string split across lines The motive to use multiple MODULE_AUTHOR statements came from this comment from "include/linux/module.h": /* * Author(s), use "Name <email>" or just "Name", for multiple * authors use multiple MODULE_AUTHOR() statements/lines. */ #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author) Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Charalampos Mitrodimas authored
These were mentioned by checkpatch: Errors: (1) code indent should use tabs where possible (2) switch and case should be at the same indent Warnings: (1) Missing a blank line after declarations Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Andrew Davis authored
Use device life-cycle managed register function to simplify probe error path and eliminate need for explicit remove function. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
- 16 Nov, 2023 1 commit
-
-
Su Hui authored
smatch complains that there is a buffer overflow and clang complains 'ret' is never read. Smatch error: drivers/power/supply/bq256xx_charger.c:1578 bq256xx_hw_init() error: buffer overflow 'bq256xx_watchdog_time' 4 <= 4 Clang static checker: Value stored to 'ret' is never read. Add check for buffer overflow and error code from regmap_update_bits(). Fixes: 32e4978b ("power: supply: bq256xx: Introduce the BQ256XX charger driver") Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20231116041822.1378758-1-suhui@nfschina.comSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
- 15 Nov, 2023 20 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20231105094712.3706799-4-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20231105094712.3706799-3-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Returning an error if unregister_restart_handler() failed has no effect but triggering another error message. So converting this driver to .remove_new() has no effect but to suppress the duplicated error message. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-30-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-29-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-28-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-27-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-26-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-25-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231104211501.3676352-24-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-23-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-22-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20231104211501.3676352-21-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231104211501.3676352-20-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
On today's platforms the benefit of platform_driver_probe() isn't that relevant any more. It allows to drop some code after booting (or module loading) for .probe() and discard the .remove() function completely if the driver is built-in. This typically saves a few 100k. The downside of platform_driver_probe() is that the driver cannot be bound and unbound at runtime which is ancient and so slightly complicates testing. There are also thoughts to deprecate platform_driver_probe() because it adds some complexity in the driver core for little gain. Also many drivers don't use it correctly. This driver for example misses to mark the driver struct with __ref which is needed to suppress a (W=1) modpost warning. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20231104211501.3676352-19-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
On today's platforms the benefit of platform_driver_probe() isn't that relevant any more. It allows to drop some code after booting (or module loading) for .probe() and discard the .remove() function completely if the driver is built-in. This typically saves a few 100k. The downside of platform_driver_probe() is that the driver cannot be bound and unbound at runtime which is ancient and so slightly complicates testing. There are also thoughts to deprecate platform_driver_probe() because it adds some complexity in the driver core for little gain. Also many drivers don't use it correctly. This driver for example misses to mark the driver struct with __ref which is needed to suppress a (W=1) modpost warning. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20231104211501.3676352-18-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Uwe Kleine-König authored
On today's platforms the benefit of platform_driver_probe() isn't that relevant any more. It allows to drop some code after booting (or module loading) for .probe() and discard the .remove() function completely if the driver is built-in. This typically saves a few 100k. The downside of platform_driver_probe() is that the driver cannot be bound and unbound at runtime which is ancient and so slightly complicates testing. There are also thoughts to deprecate platform_driver_probe() because it adds some complexity in the driver core for little gain. Also many drivers don't use it correctly. This driver for example misses to mark the driver struct with __ref which is needed to suppress a (W=1) modpost warning. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20231104211501.3676352-17-u.kleine-koenig@pengutronix.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Marek Vasut authored
This driver uses delayed work to perform periodic battery state read out. This delayed work is not stopped across suspend and resume cycle. The read out can occur early in the resume cycle. In case of an I2C variant of this hardware, that read out triggers I2C transfer. That I2C transfer may happen while the I2C controller is still suspended, which produces a WARNING in the kernel log. Fix this by introducing trivial PM ops, which stop the delayed work before the system enters suspend, and schedule the delayed work right after the system resumes. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231104154920.68585-1-marex@denx.deSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Elliot Berman authored
nvmem-reboot-mode.yaml should $ref: reboot-mode.yaml, but instead rewrites the properties. Update so it $refs instead. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20231031-ref-nvmem-reboot-mode-v1-1-c1af9070ce52@quicinc.comSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Elliot Berman authored
syscon-reboot-mode.yaml should $ref: reboot-mode.yaml, but instead rewrites the properties. Update so it $refs instead. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231031-ref-reboot-mode-v1-1-18dde4faf7e8@quicinc.comSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
Asmaa Mnebhi authored
Replace the soft reset with a graceful reboot. An acpi event will be triggered by the irq in the pwr-mlxbf.c to trigger the graceful reboot. Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Link: https://lore.kernel.org/r/20231030203058.8056-1-asmaa@nvidia.comSigned-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-
- 13 Nov, 2023 1 commit
-
-
Linus Torvalds authored
-
- 12 Nov, 2023 5 commits
-
-
Miri Korenblit authored
The commands should be sorted inside the group definition. Fix the ordering so we won't get following warning: WARN_ON(iwl_cmd_groups_verify_sorted(trans_cfg)) Link: https://lore.kernel.org/regressions/2fa930bb-54dd-4942-a88d-05a47c8e9731@gmail.com/ Link: https://lore.kernel.org/linux-wireless/CAHk-=wix6kqQ5vHZXjOPpZBfM7mMm9bBZxi2Jh7XnaKCqVf94w@mail.gmail.com/ Fixes: b6e3d1ba ("wifi: iwlwifi: mvm: implement new firmware API for statistics") Tested-by: Niklāvs Koļesņikovs <pinkflames.linux@gmail.com> Tested-by: Damian Tometzki <damian@riscv-rocks.de> Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Merge tag 'parisc-for-6.7-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fixes from Helge Deller: - Include the upper 5 address bits when inserting TLB entries on a 64-bit kernel. On physical machines those are ignored, but in qemu it's nice to have them included and to be correct. - Stop the 64-bit kernel and show a warning if someone tries to boot on a machine with a 32-bit CPU - Fix a "no previous prototype" warning in parport-gsc * tag 'parisc-for-6.7-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Prevent booting 64-bit kernels on PA1.x machines parport: gsc: mark init function static parisc/pgtable: Do not drop upper 5 address bits of physical address
-
Linus Torvalds authored
Merge tag 'loongarch-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch updates from Huacai Chen: - support PREEMPT_DYNAMIC with static keys - relax memory ordering for atomic operations - support BPF CPU v4 instructions for LoongArch - some build and runtime warning fixes * tag 'loongarch-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: selftests/bpf: Enable cpu v4 tests for LoongArch LoongArch: BPF: Support signed mod instructions LoongArch: BPF: Support signed div instructions LoongArch: BPF: Support 32-bit offset jmp instructions LoongArch: BPF: Support unconditional bswap instructions LoongArch: BPF: Support sign-extension mov instructions LoongArch: BPF: Support sign-extension load instructions LoongArch: Add more instruction opcodes and emit_* helpers LoongArch/smp: Call rcutree_report_cpu_starting() earlier LoongArch: Relax memory ordering for atomic operations LoongArch: Mark __percpu functions as always inline LoongArch: Disable module from accessing external data directly LoongArch: Support PREEMPT_DYNAMIC with static keys
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Finish a refactor of pgprot_framebuffer() which dependend on some changes that were merged via the drm tree - Fix some kernel-doc warnings to quieten the bots Thanks to Nathan Lynch and Thomas Zimmermann. * tag 'powerpc-6.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/rtas: Fix ppc_rtas_rmo_buf_show() kernel-doc powerpc/pseries/rtas-work-area: Fix rtas_work_area_reserve_arena() kernel-doc powerpc/fb: Call internal __phys_mem_access_prot() in fbdev code powerpc: Remove file parameter from phys_mem_access_prot() powerpc/machdep: Remove trailing whitespaces
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull smb client fixes from Steve French: - ctime caching fix (for setxattr) - encryption fix - DNS resolver mount fix - debugging improvements - multichannel fixes including cases where server stops or starts supporting multichannel after mount - reconnect fix - minor cleanups * tag '6.7-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6: cifs: update internal module version number for cifs.ko cifs: handle when server stops supporting multichannel cifs: handle when server starts supporting multichannel Missing field not being returned in ioctl CIFS_IOC_GET_MNT_INFO smb3: allow dumping session and tcon id to improve stats analysis and debugging smb: client: fix mount when dns_resolver key is not available smb3: fix caching of ctime on setxattr smb3: minor cleanup of session handling code cifs: reconnect work should have reference on server struct cifs: do not pass cifs_sb when trying to add channels cifs: account for primary channel in the interface list cifs: distribute channels across interfaces based on speed cifs: handle cases where a channel is closed smb3: more minor cleanups for session handling routines smb3: minor RDMA cleanup cifs: Fix encryption of cleared, but unset rq_iter data buffers
-
- 11 Nov, 2023 1 commit
-
-
Linus Torvalds authored
Merge tag 'probes-fixes-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull probes fixes from Masami Hiramatsu: - Documentation update: Add a note about argument and return value fetching is the best effort because it depends on the type. - objpool: Fix to make internal global variables static in test_objpool.c. - kprobes: Unify kprobes_exceptions_nofify() prototypes. There are the same prototypes in asm/kprobes.h for some architectures, but some of them are missing the prototype and it causes a warning. So move the prototype into linux/kprobes.h. - tracing: Fix to check the tracepoint event and return event at parsing stage. The tracepoint event doesn't support %return but if $retval exists, it will be converted to %return silently. This finds that case and rejects it. - tracing: Fix the order of the descriptions about the parameters of __kprobe_event_gen_cmd_start() to be consistent with the argument list of the function. * tag 'probes-fixes-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing/kprobes: Fix the order of argument descriptions tracing: fprobe-event: Fix to check tracepoint event and return kprobes: unify kprobes_exceptions_nofify() prototypes lib: test_objpool: make global variables static Documentation: tracing: Add a note about argument and retval access
-
- 10 Nov, 2023 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdevLinus Torvalds authored
Pull fbdev fixes and cleanups from Helge Deller: - fix double free and resource leaks in imsttfb - lots of remove callback cleanups and section mismatch fixes in omapfb, amifb and atmel_lcdfb - error code fix and memparse simplification in omapfb * tag 'fbdev-for-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: (31 commits) fbdev: fsl-diu-fb: mark wr_reg_wa() static fbdev: amifb: Convert to platform remove callback returning void fbdev: amifb: Mark driver struct with __refdata to prevent section mismatch warning fbdev: hyperv_fb: fix uninitialized local variable use fbdev: omapfb/tpd12s015: Convert to platform remove callback returning void fbdev: omapfb/tfp410: Convert to platform remove callback returning void fbdev: omapfb/sharp-ls037v7dw01: Convert to platform remove callback returning void fbdev: omapfb/opa362: Convert to platform remove callback returning void fbdev: omapfb/hdmi: Convert to platform remove callback returning void fbdev: omapfb/dvi: Convert to platform remove callback returning void fbdev: omapfb/dsi-cm: Convert to platform remove callback returning void fbdev: omapfb/dpi: Convert to platform remove callback returning void fbdev: omapfb/analog-tv: Convert to platform remove callback returning void fbdev: atmel_lcdfb: Convert to platform remove callback returning void fbdev: omapfb/tpd12s015: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/tfp410: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/sharp-ls037v7dw01: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/opa362: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/hdmi: Don't put .remove() in .exit.text and drop suppress_bind_attrs fbdev: omapfb/dvi: Don't put .remove() in .exit.text and drop suppress_bind_attrs ...
-
Yujie Liu authored
The order of descriptions should be consistent with the argument list of the function, so "kretprobe" should be the second one. int __kprobe_event_gen_cmd_start(struct dynevent_cmd *cmd, bool kretprobe, const char *name, const char *loc, ...) Link: https://lore.kernel.org/all/20231031041305.3363712-1-yujie.liu@intel.com/ Fixes: 2a588dd1 ("tracing: Add kprobe event command generation functions") Suggested-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Yujie Liu <yujie.liu@intel.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
-