- Sep 24, 2023
-
-
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/20230920125829.1478827-10-u.kleine-koenig@pengutronix.de Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.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 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 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 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 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:
Jeff LaBundy <jeff@labundy.com> Link: https://lore.kernel.org/r/20230920125829.1478827-5-u.kleine-koenig@pengutronix.de Signed-off-by:
-
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 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:
Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230920125829.1478827-3-u.kleine-koenig@pengutronix.de Signed-off-by:
-
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:
-
- Sep 07, 2023
-
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20230729005133.1095051-22-dmitry.torokhov@gmail.com Signed-off-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with sysfs_create_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
Andi Shyti <andi.shyti@kernel.org> Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Acked-by:
Michael Hennerich <michael.hennerich@analog.com> Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Acked-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
-
Dmitry Torokhov authored
Instead of creating driver-specific device attributes with devm_device_add_group() have device core do this by setting up dev_groups pointer in the driver structure. Reviewed-by:
Guenter Roeck <groeck@chromium.org> Reviewed-by:
-
- Sep 06, 2023
-
-
Dmitry Torokhov authored
Sync up with mainline to bring in updates to the shared infrastructure.
-
- Aug 28, 2023
-
-
Linus Torvalds authored
-
- Aug 27, 2023
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Three small driver fixes and one larger unused function set removal in the raid class (so no external impact)" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: snic: Fix double free in snic_tgt_create() scsi: core: raid_class: Remove raid_component_add() scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW major version > 5 scsi: ufs: mcq: Fix the search/wrap around logic
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: "Fix an FPU invalidation bug on exec(), and fix a performance regression due to a missing setting of X86_FEATURE_OSXSAVE" * tag 'x86-urgent-2023-08-26' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/fpu: Set X86_FEATURE_OSXSAVE feature after enabling OSXSAVE in CR4 x86/fpu: Invalidate FPU state correctly on exec()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fix from Thomas Gleixner: "A last minute fix for a regression introduced in the v6.5 merge window. The conversion of the software based interrupt resend mechanism to hlist missed to add a check whether the descriptor is already enqueued and dropped the interrupt descriptor lookup for nested interrupts. The missing check whether the descriptor is already queued causes hlist corruption and can be observed in the wild. The dropped parent descriptor lookup has not yet caused problems, but it would result in stale interrupt line in the worst case. Add the missing enqueued check and bring the descriptor lookup back to cure this" * tag 'irq-urgent-2023-08-26' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq: Fix software resend lockup and nested resend
-
Linus Torvalds authored
Merge tag 'loongarch-fixes-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: "Fix a ptrace bug, a hw_breakpoint bug, some build errors/warnings and some trivial cleanups" * tag 'loongarch-fixes-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch: Fix hw_breakpoint_control() for watchpoints LoongArch: Ensure FP/SIMD registers in the core dump file is up to date LoongArch: Put the body of play_dead() into arch_cpu_idle_dead() LoongArch: Add identifier names to arguments of die() declaration LoongArch: Return earlier in die() if notify_die() returns NOTIFY_STOP LoongArch: Do not kill the task in die() if notify_die() returns NOTIFY_STOP LoongArch: Remove <asm/export.h> LoongArch: Replace #include <asm/export.h> with #include <linux/export.h> LoongArch: Remove unneeded #include <asm/export.h> LoongArch: Replace -ffreestanding with finer-grained -fno-builtin's LoongArch: Remove redundant "source drivers/firmware/Kconfig"
-
Johan Hovold authored
The switch to using hlist for managing software resend of interrupts broke resend in at least two ways: First, unconditionally adding interrupt descriptors to the resend list can corrupt the list when the descriptor in question has already been added. This causes the resend tasklet to loop indefinitely with interrupts disabled as was recently reported with the Lenovo ThinkPad X13s after threaded NAPI was disabled in the ath11k WiFi driver. This bug is easily fixed by restoring the old semantics of irq_sw_resend() so that it can be called also for descriptors that have already been marked for resend. Second, the offending commit also broke software resend of nested interrupts by simply discarding the code that made sure that such interrupts are retriggered using the parent interrupt. Add back the corresponding code that adds the parent descriptor to the resend list. Fixes: bc06a9e0 ("genirq: Use hlist for managing resend handlers") Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/lkml/20230809073432.4193-1-johan+linaro@kernel.org/ Link: https://lore.kernel.org/r/20230826154004.1417-1-johan+linaro@kernel.org
-
- Aug 26, 2023
-
-
Huacai Chen authored
In hw_breakpoint_control(), encode_ctrl_reg() has already encoded the MWPnCFG3_LoadEn/MWPnCFG3_StoreEn bits in info->ctrl. We don't need to add (1 << MWPnCFG3_LoadEn | 1 << MWPnCFG3_StoreEn) unconditionally. Otherwise we can't set read watchpoint and write watchpoint separately. Cc: stable@vger.kernel.org Signed-off-by:Huacai Chen <chenhuacai@loongson.cn>
-
Huacai Chen authored
This is a port of commit 379eb01c ("riscv: Ensure the value of FP registers in the core dump file is up to date"). The values of FP/SIMD registers in the core dump file come from the thread.fpu. However, kernel saves the FP/SIMD registers only before scheduling out the process. If no process switch happens during the exception handling, kernel will not have a chance to save the latest values of FP/SIMD registers. So it may cause their values in the core dump file incorrect. To solve this problem, force fpr_get()/simd_get() to save the FP/SIMD registers into the thread.fpu if the target task equals the current task. Cc: stable@vger.kernel.org Signed-off-by:
-
