aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-09-04printk: Fail pr_flush() if before SYSTEM_SCHEDULINGJohn Ogness1-0/+4
A follow-up change adds pr_flush() to console unregistration. However, with boot consoles unregistration can happen very early if there are also regular consoles registering as well. In this case the pr_flush() is not important because all consoles are flushed when checking the initial console sequence number. Allow pr_flush() to fail if @system_state has not yet reached SYSTEM_SCHEDULING. This avoids might_sleep() and msleep() explosions that would otherwise occur: [ 0.436739][ T0] printk: legacy console [ttyS0] enabled [ 0.439820][ T0] printk: legacy bootconsole [earlyser0] disabled [ 0.446822][ T0] BUG: scheduling while atomic: swapper/0/0/0x00000002 [ 0.450491][ T0] 1 lock held by swapper/0/0: [ 0.457897][ T0] #0: ffffffff82ae5f88 (console_mutex){+.+.}-{4:4}, at: console_list_lock+0x20/0x70 [ 0.463141][ T0] Modules linked in: [ 0.465307][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.10.0-rc1+ #372 [ 0.469394][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 0.474402][ T0] Call Trace: [ 0.476246][ T0] <TASK> [ 0.481473][ T0] dump_stack_lvl+0x93/0xb0 [ 0.483949][ T0] dump_stack+0x10/0x20 [ 0.486256][ T0] __schedule_bug+0x68/0x90 [ 0.488753][ T0] __schedule+0xb9b/0xd80 [ 0.491179][ T0] ? lock_release+0xb5/0x270 [ 0.493732][ T0] schedule+0x43/0x170 [ 0.495998][ T0] schedule_timeout+0xc5/0x1e0 [ 0.498634][ T0] ? __pfx_process_timeout+0x10/0x10 [ 0.501522][ T0] ? msleep+0x13/0x50 [ 0.503728][ T0] msleep+0x3c/0x50 [ 0.505847][ T0] __pr_flush.constprop.0.isra.0+0x56/0x500 [ 0.509050][ T0] ? _printk+0x58/0x80 [ 0.511332][ T0] ? lock_is_held_type+0x9c/0x110 [ 0.514106][ T0] unregister_console_locked+0xe1/0x450 [ 0.517144][ T0] register_console+0x509/0x620 [ 0.519827][ T0] ? __pfx_univ8250_console_init+0x10/0x10 [ 0.523042][ T0] univ8250_console_init+0x24/0x40 [ 0.525845][ T0] console_init+0x43/0x210 [ 0.528280][ T0] start_kernel+0x493/0x980 [ 0.530773][ T0] x86_64_start_reservations+0x18/0x30 [ 0.533755][ T0] x86_64_start_kernel+0xae/0xc0 [ 0.536473][ T0] common_startup_64+0x12c/0x138 [ 0.539210][ T0] </TASK> And then the kernel goes into an infinite loop complaining about: 1. releasing a pinned lock 2. unpinning an unpinned lock 3. bad: scheduling from the idle thread! 4. goto 1 Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04printk: nbcon: Add function for printers to reacquire ownershipJohn Ogness2-7/+73
Since ownership can be lost at any time due to handover or takeover, a printing context _must_ be prepared to back out immediately and carefully. However, there are scenarios where the printing context must reacquire ownership in order to finalize or revert hardware changes. One such example is when interrupts are disabled during printing. No other context will automagically re-enable the interrupts. For this case, the disabling context _must_ reacquire nbcon ownership so that it can re-enable the interrupts. Provide nbcon_reacquire_nobuf() for exactly this purpose. It allows a printing context to reacquire ownership using the same priority as its previous ownership. Note that after a successful reacquire the printing context will have no output buffer because that has been lost. This function cannot be used to resume printing. Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]>
2024-09-04ARM: 9414/1: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATIONYuntao Liu2-4/+10
There is a build issue with LD segmentation fault, while CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled, as bellow. scripts/link-vmlinux.sh: line 49: 3796 Segmentation fault (core dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive ${objs} ${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group ${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs} The error occurs in older versions of the GNU ld with version earlier than 2.36. It makes most sense to have a minimum LD version as a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION and eliminate the impact of ".reloc .text, R_ARM_NONE, ." when CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled. Fixes: ed0f94102251 ("ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION") Reported-by: Harith George <[email protected]> Tested-by: Harith George <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Yuntao Liu <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Russell King (Oracle) <[email protected]>
2024-09-04perf jevents: Add cpuid to model lookup commandIan Rogers1-0/+73
When restricting jevents generated json lookup code with JEVENTS_MODEL a list of models must be provided. Some builds don't know model names but know cpuids. Add a command that can convert a cpuid to a model using mapfile.csv files. This can be used with JEVENTS_MODEL like: $ make JEVENTS_MODEL=`./pmu-events/models.py x86 'GenuineIntel-6-8D-1,AuthenticAMD-26-1' pmu-events/arch/` Committer testing: $ tools/perf/pmu-events/models.py x86 'GenuineIntel-6-8D-1,AuthenticAMD-26-1' tools/perf/pmu-events/arch/ tigerlake,amdzen5 $ perf stat -v sleep 1 |& head -1 Using CPUID GenuineIntel-6-B7-1 $ tools/perf/pmu-events/models.py x86 'GenuineIntel-6-B7-1' tools/perf/pmu-events/arch/ alderlake $ Signed-off-by: Ian Rogers <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-09-04thermal/drivers/imx_sc_thermal: Use dev_err_probeAlexander Stein1-2/+1
This adds the error code to the error message and also stores that message in case of probe deferral. Signed-off-by: Alexander Stein <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2024-09-04block: fix comment to use set_current_stateAlvaro Parker1-1/+1
The explanatory comment used `set_task_state` instead of `set_current_state` which is the function actually used in the code. Signed-off-by: Alvaro Parker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-09-04bio-integrity: don't restrict the size of integrity metadataMikulas Patocka1-4/+0
bio_integrity_add_page restricts the size of the integrity metadata to queue_max_hw_sectors(q). This restriction is not needed because oversized bios are split automatically. This restriction causes problems with dm-integrity 'inline' mode - if we send a large bio to dm-integrity and the bio's metadata are larger than queue_max_hw_sectors(q), bio_integrity_add_page fails and the bio is ended with BLK_STS_RESOURCE error. An example that triggers it: dd: error writing '/dev/mapper/in2': Cannot allocate memory 1+0 records in 0+0 records out 0 bytes copied, 0.00169291 s, 0.0 kB/s Signed-off-by: Mikulas Patocka <[email protected]> Fixes: fb0987682c62 ("dm-integrity: introduce the Inline mode") Fixes: 0ece1d649b6d ("bio-integrity: create multi-page bvecs in bio_integrity_add_page()") Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Anuj Gupta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-09-04ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery()Li Nan1-0/+2
When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the first one sets 'ubq->ubq_daemon' to NULL, and the second one triggers WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference issue. Fix it by adding the check in ublk_ctrl_start_recovery() and return immediately in case of zero 'ub->nr_queues_ready'. BUG: kernel NULL pointer dereference, address: 0000000000000028 RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x75/0x170 ? exc_page_fault+0x64/0x140 ? asm_exc_page_fault+0x22/0x30 ? ublk_ctrl_start_recovery.constprop.0+0x82/0x180 ublk_ctrl_uring_cmd+0x4f7/0x6c0 ? pick_next_task_idle+0x26/0x40 io_uring_cmd+0x9a/0x1b0 io_issue_sqe+0x193/0x3f0 io_wq_submit_work+0x9b/0x390 io_worker_handle_work+0x165/0x360 io_wq_worker+0xcb/0x2f0 ? finish_task_switch.isra.0+0x203/0x290 ? finish_task_switch.isra.0+0x203/0x290 ? __pfx_io_wq_worker+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_io_wq_worker+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Fixes: c732a852b419 ("ublk_drv: add START_USER_RECOVERY and END_USER_RECOVERY support") Reported-and-tested-by: Changhui Zhong <[email protected]> Closes: https://lore.kernel.org/all/CAGVVp+UvLiS+bhNXV-h2icwX1dyybbYHeQUuH7RYqUvMQf6N3w@mail.gmail.com Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Li Nan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-09-04rpmb: fix error path in rpmb_dev_register()Jens Wiklander1-6/+4
Until this patch was rpmb_dev_register() always freeing rdev in the error path. However, past device_register() it must not do that since the memory is now managed by the device even if it failed to register properly. So fix this by doing a put_device() before returning the error code. Fixes the smatch warning: drivers/misc/rpmb-core.c:204 rpmb_dev_register() warn: freeing device managed memory (leak): 'rdev' Fixes: 1e9046e3a154 ("rpmb: add Replay Protected Memory Block (RPMB) subsystem") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2024-09-04platform/x86: int3472: Use str_high_low()Andy Shevchenko1-1/+2
Use str_high_low() rather than open coding. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-04platform/x86: int3472: Use GPIO_LOOKUP() macroAndy Shevchenko1-5/+1
Use GPIO_LOOKUP() macro which provides a compound literal and can be used with dynamic data. Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-04perf check: Introduce 'check' subcommandAditya Gupta5-0/+281
Currently the presence of a feature is checked with a combination of perf version --build-options and greps, such as: perf version --build-options | grep " on .* HAVE_FEATURE" Instead of this, introduce a subcommand "perf check feature", with which scripts can test for presence of a feature, such as: perf check feature HAVE_FEATURE 'perf check feature' command is expected to have exit status of 0 if feature is built-in, and 1 if it's not built-in or if feature is not known. Multiple features can also be passed as a comma-separated list, in which case the exit status will be 1 only if all of the passed features are built-in. For example, with below command, it will have exit status of 0 only if both libtraceevent and bpf are enabled, else 1 in all other cases perf check feature libtraceevent,bpf The arguments are case-insensitive. An array 'supported_features' has also been introduced that can be used by other commands like 'perf version --build-options', so that new features can be added in one place, with the array Committer testing: $ perf check feature libtraceevent,bpf libtraceevent: [ on ] # HAVE_LIBTRACEEVENT bpf: [ on ] # HAVE_LIBBPF_SUPPORT $ perf check feature libtraceevent libtraceevent: [ on ] # HAVE_LIBTRACEEVENT $ perf check feature bpf bpf: [ on ] # HAVE_LIBBPF_SUPPORT $ perf check -q feature bpf && echo "BPF support is present" BPF support is present $ perf check -q feature Bogus && echo "Bogus support is present" $ Reviewed-by: Athira Rajeev <[email protected]> Signed-off-by: Aditya Gupta <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Disha Goel <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-09-04libsubcmd: Don't free the usage stringAditya Gupta7-5/+20
Currently, commands which depend on 'parse_options_subcommand()' don't show the usage string, and instead show '(null)' $ ./perf sched Usage: (null) -D, --dump-raw-trace dump raw trace in ASCII -f, --force don't complain, do it -i, --input <file> input file name -v, --verbose be more verbose (show symbol address, etc) 'parse_options_subcommand()' is generally expected to initialise the usage string, with information in the passed 'subcommands[]' array This behaviour was changed in: 230a7a71f92212e7 ("libsubcmd: Fix parse-options memory leak") Where the generated usage string is deallocated, and usage[0] string is reassigned as NULL. As discussed in [1], free the allocated usage string in the main function itself, and don't reset usage string to NULL in parse_options_subcommand With this change, the behaviour is restored. $ ./perf sched Usage: perf sched [<options>] {record|latency|map|replay|script|timehist} -D, --dump-raw-trace dump raw trace in ASCII -f, --force don't complain, do it -i, --input <file> input file name -v, --verbose be more verbose (show symbol address, etc) [1]: https://lore.kernel.org/linux-perf-users/htq5vhx6piet4nuq2mmhk7fs2bhfykv52dbppwxmo3s7du2odf@styd27tioc6e/ Fixes: 230a7a71f92212e7 ("libsubcmd: Fix parse-options memory leak") Suggested-by: Namhyung Kim <[email protected]> Signed-off-by: Aditya Gupta <[email protected]> Acked-by: Namhyung Kim <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Disha Goel <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-09-04ALSA: firewire: use nonatomic PCM operationTakashi Sakamoto10-7/+36
In the former commits, the callback of isochronous context runs on usual work process. In the case, ALSA PCM device has a flag, nonatomic, to acquire mutex lock instead of spin lock for PCM substream group. This commit uses the flag. It has an advantage in the case that ALSA PCM application uses the large size of intermediate buffer, since it takes too long time even in tasklet softIRQ to process many of isochronous packets, then result in the delay of system event due to disabled IRQ so long. It is avertible to switch to nonatomic operation. Reviewed-by: Takashi Iwai <[email protected]> Tested-by: Edmund Raile <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]>
2024-09-04firewire: core: non-atomic memory allocation for isochronous event to user ↵Takashi Sakamoto1-2/+2
client In the former commits, the callback of isochronous context runs on work process, thus no need to use atomic memory allocation. This commit replaces GFP_ATOMIC with GCP_KERNEL in the callback for user client. Tested-by: Edmund Raile <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]>
2024-09-04firewire: ohci: operate IT/IR events in sleepable work process instead of ↵Takashi Sakamoto1-10/+45
tasklet softIRQ This commit queues work item for IT/IR events at hardIRQ handler to operate the corresponding isochronous context. The work item is queued to any of worker-pools. The callback for either the implementation of unit protocol and user space clients is executed in sleepable work process context. The change could results in any errors of concurrent processing as well as sleep at atomic context. These errors are fixed by the following commits. Tested-by: Edmund Raile <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]>
2024-09-04firewire: core: add local API to queue work item to workqueue specific to ↵Takashi Sakamoto3-2/+39
isochronous contexts In the previous commit, the workqueue is added per the instance of fw_card structure for isochronous contexts. The workqueue is designed to be used by the implementation of fw_card_driver structure underlying the fw_card. This commit adds some local APIs to be used by the implementation. Tested-by: Edmund Raile <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]>
2024-09-04firewire: core: allocate workqueue to handle isochronous contexts in cardTakashi Sakamoto4-6/+35
This commit adds a workqueue dedicated for isochronous context processing. The workqueue is allocated per instance of fw_card structure to satisfy the following characteristics descending from 1394 OHCI specification: In 1394 OHCI specification, memory pages are reserved to each isochronous context dedicated to DMA transmission. It allows to operate these per-context pages concurrently. Software can schedule hardware interrupt for several isochronous context to the same cycle, thus WQ_UNBOUND is specified. Additionally, it is sleepable to operate the content of pages, thus WQ_BH is not used. The isochronous context delivers the packets with time stamp, thus WQ_HIGHPRI is specified for semi real-time data such as IEC 61883-1/6 protocol implemented by ALSA firewire stack. The isochronous context is not used by the implementation of SCSI over IEEE1394 protocol (sbp2), thus WQ_MEM_RECLAIM is not specified. It is useful for users to adjust cpu affinity of the workqueue depending on their work loads, thus WQ_SYS is specified to expose the attributes to user space. Tested-by: Edmund Raile <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]>
2024-09-04perf parse-events: Vary default_breakpoint_len on i386 and arm64Ian Rogers1-0/+16
On arm64 the breakpoint length should be 4-bytes but 8-bytes is tolerated as perf passes that as sizeof(long). Just pass the correct value. On i386 the sizeof(long) check in the kernel needs to match the kernel's long size. Check using an environment (uname checks) whether 4 or 8 bytes needs to be passed. Cache the value in a static. Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Chaitanya S Prakash <[email protected]> Cc: Colin Ian King <[email protected]> Cc: Dominique Martinet <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Garry <[email protected]> Cc: Junhao He <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Yang Jihong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-09-04perf parse-events: Add default_breakpoint_len helperIan Rogers6-5/+17
The default breakpoint length is "sizeof(long)" however this is incorrect on platforms like Aarch64 where sizeof(long) is 8 but the breakpoint length is 4. Add a helper function that can be used to determine the correct breakpoint length, in this change it just returns the existing default sizeof(long) value. Use the helper in the bp_account test so that, when modifying the event from a watchpoint to a breakpoint, the breakpoint length is appropriate for the architecture and not just sizeof(long). Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Chaitanya S Prakash <[email protected]> Cc: Colin Ian King <[email protected]> Cc: Dominique Martinet <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Garry <[email protected]> Cc: Junhao He <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Yang Jihong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-09-04Merge patch series "can: rockchip_canfd: add support for CAN-FD IP core ↵Marc Kleine-Budde12-0/+2269
found on Rockchip RK3568" Marc Kleine-Budde <[email protected]> says: This series adds support for the CAN-FD IP core found on the Rockchip RK3568. The IP core is a bit complicated and has several documented errata. The driver is added in several stages, first the base driver including the RX-path. Then several workarounds for errata and the TX-path, and finally features like hardware time stamping, loop-back mode and bus error reporting. Link: https://patch.msgid.link/[email protected] [mkl: removed DTS patches] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04platform/x86:dell-laptop: remove duplicate code w/ battery functionAndres Salomon1-82/+27
The dell battery patch added dell_send_request_for_tokenid() and dell_set_std_token_value(), which encapsulates a very common pattern when SMBIOS queries are addressed to token->location. This calls them in various places outside of the dell laptop code, allowing us to delete a bunch of code. Also some very minor cleanups: - mark the kbd init functions as __init - don't read buffer.output unless dell_send_request() was successful. - actually return errors from micmute_led_set/mute_led_set instead of always returning 0. Only minor behavior changes; the delayed read of buffer.output and actually returning errors for the brightness_set_blocking hooks. Signed-off-by: Andres Salomon <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Link: https://lore.kernel.org/r/20240820033335.4f68b162@5400 Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-04platform/x86:dell-laptop: Add knobs to change battery charge settingsAndres Salomon3-0/+318
The Dell BIOS allows you to set custom charging modes, which is useful in particular for extending battery life. This adds support for tweaking those various settings from Linux via sysfs knobs. One might, for example, have their laptop plugged into power at their desk the vast majority of the time and choose fairly aggressive battery-saving settings (eg, only charging once the battery drops below 50% and only charging up to 80%). When leaving for a trip, it would be more useful to instead switch to a standard charging mode (top off at 100%, charge any time power is available). Rebooting into the BIOS to change the charging mode settings is a hassle. For the Custom charging type mode, we reuse the common charge_control_{start,end}_threshold sysfs power_supply entries. The BIOS also has a bunch of other charging modes (with varying levels of usefulness), so this also adds a 'charge_type' sysfs entry that maps the standard values to Dell-specific ones. This work is based on a patch by Perry Yuan <[email protected]> and Limonciello Mario <[email protected]> submitted back in 2020. Hans de Goede: s/charge_type/charge_types/ since charge_types_show() used the new charge_types power-supply property output format. Signed-off-by: Andres Salomon <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Link: https://lore.kernel.org/r/20240820033005.09e03af1@5400 Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-09-04can: rockchip_canfd: add support for CAN_CTRLMODE_BERR_REPORTINGMarc Kleine-Budde1-8/+17
Add support for Bus Error Reporting. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add support for CAN_CTRLMODE_LOOPBACKMarc Kleine-Budde2-2/+7
Add support for loopback mode. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add hardware timestamping supportMarc Kleine-Budde6-3/+115
Add support for hardware based timestamping. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: enable full TX-FIFO depth of 2Marc Kleine-Budde1-1/+1
The previous commit prepared the TX path to make use of the full TX-FIFO depth as much as possible. Increase the available TX-FIFO depth to the hardware maximum of 2. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: prepare to use full TX-FIFO depthMarc Kleine-Budde3-3/+38
So far the TX-FIFO is only used with a depth of 1, although the hardware offers a depth of 2. The workaround for the chips that are affected by erratum 6, i.e. EFF frames may be send as standard frames, is to re-send the EFF frame. This means the driver cannot queue the next frame for sending, as long ad the EFF frame has not been successfully send out. Introduce rkcanfd_get_effective_tx_free() that returns "0" space in the TX-FIFO if an EFF frame is pending and the actual free space in the TX-FIFO otherwise. Then replace rkcanfd_get_tx_free() with rkcanfd_get_effective_tx_free() everywhere. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add stats support for errata workaroundsMarc Kleine-Budde5-1/+102
The driver contains workarounds for some of the rk3568v2 errata. Add ethtool-based statistics ("ethtool -S") to track how often an erratum workaround was needed. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: rkcanfd_get_berr_counter_corrected(): work around ↵Marc Kleine-Budde4-6/+69
broken {RX,TX}ERRORCNT register Tests show that sometimes both CAN bus error counters read 0x0, even if the controller is in warning mode (RKCANFD_REG_STATE_ERROR_WARNING_STATE in RKCANFD_REG_STATE set). To work around this issue, if both error counters read from hardware are 0x0, use the structure priv->bec, otherwise save the read value in priv->bec. In rkcanfd_handle_rx_int_one() decrement the priv->bec.rxerr for successfully RX'ed CAN frames. In rkcanfd_handle_tx_done_one() decrement the priv->bec.txerr for successfully TX'ed CAN frames. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: implement workaround for erratum 12Marc Kleine-Budde1-0/+7
The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | A dominant bit at the third bit of the intermission may cause a | transmission error. | | When sampling the third bit of the intermission as a dominant bit, if | tx_req is configured to transmit extended frames at this time, the | extended frame may be sent to the bus in the format of a standard | frame. The extended frame will be sent as a standard frame and will not | result in error frames Turn on "Interframe Spaceing RX Mode" only during TX to work around erratum 12, according to rock-chip: | Spaceing RX Mode = 1, the third Bit between frames cannot receive | and send, and the fourth Bit begins to receive and send. | | Spaceing RX Mode = 0, allowing the third Bit between frames to | receive and send. Message-ID: <[email protected]> Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: implement workaround for erratum 6Marc Kleine-Budde3-0/+71
The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | The CAN controller's transmission of extended frames may | intermittently change into standard frames. | | When using the CAN controller to send extended frames, if the | 'tx_req' is configured as 1 and coincides with the internal | transmission point, the extended frame will be transmitted onto the | bus in the format of a standard frame. To work around Erratum 6, the driver is in self-receiving mode (RXSTX) and all received CAN frames are passed through rkcanfd_rxstx_filter(). Add a check in rkcanfd_rxstx_filter() whether the received frame corresponds to the current outgoing frame, but the extended CAN ID has been mangled to a standard ID. In this case re-send the original CAN frame. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add TX PATHMarc Kleine-Budde4-1/+221
The IP core has a TX event FIFO. In other IP cores, this type of FIFO usually contains the events that a CAN frame has been successfully sent. However, the IP core on the rk3568v2 the FIFO also holds events of unsuccessful transmission attempts. It turned out that the best way to work around this problem is to set the IP core to self-receive mode (RXSTX), filter out the self-received frames and insert them into the complete TX path. Add a pair new functions to check if 2 struct canfd_frame are equal. The 1st checks if the header of the CAN frames are equal, the 2nd checks if the data portion are equal: - rkcanfd_can_frame_header_equal() - rkcanfd_can_frame_data_equal() Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: rkcanfd_register_done(): add warning for erratum 5Marc Kleine-Budde1-0/+7
Tests on the rk3568v2 and rk3568v3 show that a reduced "baudclk" (e.g. 80MHz, compared to the standard 300MHz) significantly increases the possibility of incorrect FIFO counters, i.e. erratum 5. Print an info message if the clock is below the known good value of 300MHz. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: rkcanfd_handle_rx_int_one(): implement workaround for ↵Marc Kleine-Budde2-0/+36
erratum 5: check for empty FIFO The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | Erratum 5: Counters related to the TXFIFO and RXFIFO exhibit | abnormal counting behavior. | | Due to a bug in the cross-asynchronous logic of the enable signals | for rx_fifo_cnt and txe_fifo_frame_cnt counters, the counts of these | two counters become inaccurate. This issue has resulted in the | inability to use the TXFIFO and RXFIFO functions. The errata sheet mentioned above states that only the rk3568v2 is affected by this erratum, but tests with the rk3568v2 and rk3568v3 show that the RX_FIFO_CNT is sometimes too high. This leads to CAN frames being read from the FIFO, which is then already empty. Further tests on the rk3568v2 and rk3568v3 show that in this situation (i.e. empty FIFO) all elements of the FIFO header (frameinfo, id, ts) contain the same data. On the rk3568v2 and rk3568v3, this problem only occurs extremely rarely with the standard clock of 300 MHz, but almost immediately at 80 MHz. To workaround this problem, check for empty FIFO with rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit early. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add notes about known issuesMarc Kleine-Budde1-0/+20
Even the rk3568v3 has some known issues. Document them together with a reproducer. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add support for rk3568v3Marc Kleine-Budde2-0/+21
Add the support for the rk3568v3 SoC, the CAN-FD IP core has 7 documented errata. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add quirk for broken CAN-FD supportMarc Kleine-Budde2-1/+25
The errata sheets doesn't say anything about CAN-FD, but tests on the rk3568v2 and rk3568v3 show that receiving certain CAN-FD frames triggers an Error Interrupt. Mark the CAN-FD support as broken. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add quirks for errata workaroundsMarc Kleine-Budde2-2/+64
Add a basic infrastructure for quirks for the 12 documented errata. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add driver for Rockchip CAN-FD controllerMarc Kleine-Budde10-0/+1395
Add driver for the Rockchip CAN-FD controller. The IP core on the rk3568v2 SoC has 12 documented errata. Corrections for these errata will be added in the upcoming patches. Since several workarounds are required for the TX path, only add the base driver that only implements the RX path. Although the RX path implements CAN-FD support, it's not activated in ctrlmode_supported, as the IP core in the rk3568v2 has problems with receiving or sending certain CAN-FD frames. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04ACPI: battery: use driver core managed async probingThomas Weißschuh1-24/+7
In commit 0f66af530116 ("ACPI: battery: asynchronous init") the ACPI battery driver switched to a custom async driver probing to avoid delaying the system boot. In the meantime the driver core gained its own async probing logic for "slow devices which probing order is not essential for booting the system". Switch over to the core logic and drop the custom one. Signed-off-by: Thomas Weißschuh <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changelog edit ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-09-04Documentation: PM: Discourage use of deprecated macrosAndy Shevchenko2-8/+7
The Documentation refers to some deprecated macros. Update those parts accordingly. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changelog edit ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-09-04pm-graph: Update directory handling and installation process in MakefileAmit Vadhavana1-38/+73
- Standardize directory variables to support more flexible installations. - Add copyright and licensing information to the Makefile. - Introduce ".PHONY" declarations to ensure that specific targets are always executed, regardless of the presence of files with matching names. - Add a help target to provide usage instructions. Signed-off-by: Amit Vadhavana <[email protected]> Acked-by: Todd Brandt <[email protected]> Link: https://patch.msgid.link/Update directory handling and installation process in Makefile [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-09-04pm-graph: Make git ignore sleepgraph.py artifactsYo-Jung (Leo) Lin1-0/+3
By default, sleepgraph.py creates suspend-{date}-{time} directories to store artifacts, or suspend-{date}-{time}-xN if the --multi option is used. Ignore those directories by adding a .gitignore file. Signed-off-by: Yo-Jung (Leo) Lin <[email protected]> Acked-by: Todd Brandt <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-09-04PCI: brcmstb: Use common error handling code in brcm_pcie_probe()Jim Quinlan1-13/+12
Refactor the error handling in the bottom half of the probe function for readability. The invocation of clk_prepare_enable() is moved lower in the function and this simplifies a couple of return paths. The dev_err_probe() is also used when it is apt. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2024-09-04dt-bindings: PCI: brcm,stb-pcie: Add 7712 SoC descriptionJim Quinlan1-2/+26
Add description for the 7712 SoC, a Broadcom STB sibling chip of the Raspberry Pi 5. The 7712 uses three reset controllers: rescal, for PHY reset calibration; bridge, for the bridge between the PCIe bus and the memory bus; and swinit, which is a "soft" initialization of the PCIe HW. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]>
2024-09-04dt-bindings: PCI: brcm,stb-pcie: Use maxItems for reset controllersJim Quinlan1-4/+8
Provide the maxItem property for the reset controllers and drop their superfluous descriptions. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]>
2024-09-04dt-bindings: PCI: brcm,stb-pcie: Change brcmstb maintainer and cleanupJim Quinlan1-3/+3
Change maintainer: Nicolas has not been active for a while. It also makes sense for a Broadcom employee to be the maintainer as many of the details are privy to Broadcom. Also, alphabetize the compatible strings. Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Jim Quinlan <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]>
2024-09-04regulator: Move OF-specific regulator lookup code to of_regulator.cChen-Yu Tsai3-87/+119
There's still a bit of OF-specific code in the regulator device lookup function. Move those bits of code over to of_regulator.c, and create a new function of_regulator_dev_lookup() to encapsulate the code moved out of regulator_dev_lookup(). Also mark of_find_regulator_by_node() as static, since there are no other users in other compile units. There are no functional changes. A line alignment was also fixed. Signed-off-by: Chen-Yu Tsai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-09-04Merge branch 'fbnic-ethtool'David S. Miller12-3/+260
Mohsin Bashir says: ==================== eth: Add basic ethtool support for fbnic This patch series adds basic ethtool support for fbnic. Specifically, the two patches focus on the following two features respectively: 1: Enable 'ethtool -i <dev>' to provide driver, firmware and bus information. 2: Provide mac group stats. Changes since v2: - Fix v1 reference link - Fix nit --- v2: https://lore.kernel.org/netdev/[email protected] v1: https://lore.kernel.org/netdev/[email protected] ==================== Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.