aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-05-19random: use static branch for crng_ready()Jason A. Donenfeld1-4/+12
Since crng_ready() is only false briefly during initialization and then forever after becomes true, we don't need to evaluate it after, making it a prime candidate for a static branch. One complication, however, is that it changes state in a particular call to credit_init_bits(), which might be made from atomic context, which means we must kick off a workqueue to change the static key. Further complicating things, credit_init_bits() may be called sufficiently early on in system initialization such that system_wq is NULL. Fortunately, there exists the nice function execute_in_process_context(), which will immediately execute the function if !in_interrupt(), and otherwise defer it to a workqueue. During early init, before workqueues are available, in_interrupt() is always false, because interrupts haven't even been enabled yet, which means the function in that case executes immediately. Later on, after workqueues are available, in_interrupt() might be true, but in that case, the work is queued in system_wq and all goes well. Cc: Theodore Ts'o <[email protected]> Cc: Sultan Alsawaf <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-05-19mmc: core: Fix busy polling for MMC_SEND_OP_COND againUlf Hansson1-1/+1
It turned out that polling period for MMC_SEND_OP_COND, that currently is set to 1ms, still isn't sufficient. In particular a Micron eMMC on a Beaglebone platform, is reported to sometimes fail to initialize. Additional test, shows that extending the period to 4ms is working fine, so let's make that change. Reported-by: Jean Rene Dawin <[email protected]> Tested-by: Jean Rene Dawin <[email protected]> Fixes: 1760fdb6fe9f (mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND") Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-19bfq: Remove bfq_requeue_request_body()Jan Kara1-7/+2
The function has only a single caller and two lines. Just remove it since it is pointless and just harming readability. Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-05-19bfq: Remove superfluous conversion from RQ_BIC()Jan Kara1-1/+1
We store struct bfq_io_cq pointer in rq->elv.priv[0] in bfq_init_rq(). Thus a call to icq_to_bic() in RQ_BIC() is wrong. Luckily it does no harm currently because struct io_iq is the first one in struct bfq_io_cq. Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-05-19bfq: Allow current waker to defend against a tentative oneJan Kara1-2/+1
The code in bfq_check_waker() ignores wake up events from the current waker. This makes it more likely we select a new tentative waker although the current one is generating more wake up events. Treat current waker the same way as any other process and allow it to reset the waker detection logic. Fixes: 71217df39dc6 ("block, bfq: make waker-queue detection more robust") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-05-19bfq: Relax waker detection for shared queuesJan Kara2-2/+4
Currently we look for waker only if current queue has no requests. This makes sense for bfq queues with a single process however for shared queues when there is a larger number of processes the condition that queue has no requests is difficult to meet because often at least one process has some request in flight although all the others are waiting for the waker to do the work and this harms throughput. Relax the "no queued request for bfq queue" condition to "the current task has no queued requests yet". For this, we also need to start tracking number of requests in flight for each task. This patch (together with the following one) restores the performance for dbench with 128 clients that regressed with commit c65e6fd460b4 ("bfq: Do not let waker requests skip proper accounting") because this commit makes requests of wakers properly enter BFQ queues and thus these queues become ineligible for the old waker detection logic. Dbench results: Vanilla 5.18-rc3 5.18-rc3 + revert 5.18-rc3 patched Mean 1237.36 ( 0.00%) 950.16 * 23.21%* 988.35 * 20.12%* Numbers are time to complete workload so lower is better. Fixes: c65e6fd460b4 ("bfq: Do not let waker requests skip proper accounting") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-05-19xen: add support for initializing xenstore later as HVM domainLuca Miccio1-20/+71
When running as dom0less guest (HVM domain on ARM) the xenstore event channel is available at domain creation but the shared xenstore interface page only becomes available later on. In that case, wait for a notification on the xenstore event channel, then complete the xenstore initialization later, when the shared page is actually available. The xenstore page has few extra field. Add them to the shared struct. One of the field is "connection", when the connection is ready, it is zero. If the connection is not-zero, wait for a notification. Signed-off-by: Luca Miccio <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen: sync xs_wire.h header with upstream xenStefano Stabellini1-4/+33
Sync the xs_wire.h header file in Linux with the one in Xen. Signed-off-by: Stefano Stabellini <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19x86: xen: remove STACK_FRAME_NON_STANDARD from xen_cpuidMaximilian Heyne1-2/+0
Since commit 4d65adfcd119 ("x86: xen: insn: Decode Xen and KVM emulate-prefix signature"), objtool is able to correctly parse the prefixed instruction in xen_cpuid and emit correct orc unwind information. Hence, marking the function as STACKFRAME_NON_STANDARD is no longer needed. This commit is basically a revert of commit 983bb6d254c7 ("x86/xen: Mark xen_cpuid() stack frame as non-standard"). Signed-off-by: Maximilian Heyne <[email protected]> Reviewed-by: Juergen Gross <[email protected]> CC: Josh Poimboeuf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen-blk{back,front}: Update contact points for buffer_squeeze_duration_ms ↵SeongJae Park2-3/+3
and feature_persistent SeongJae is currently listed as a contact point for some blk{back,front} features, but he will not work for XEN for a while. This commit therefore updates the contact point to his colleague, Maximilian, who is understanding the context and actively working with the features now. Signed-off-by: SeongJae Park <[email protected]> Signed-off-by: Maximilian Heyne <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19fs-writeback: writeback_sb_inodes：Recalculate 'wrote' according skipped pagesZhihao Cheng1-5/+8
Commit 505a666ee3fc ("writeback: plug writeback in wb_writeback() and writeback_inodes_wb()") has us holding a plug during wb_writeback, which may cause a potential ABBA dead lock: wb_writeback fat_file_fsync blk_start_plug(&plug) for (;;) { iter i-1: some reqs have been added into plug->mq_list // LOCK A iter i: progress = __writeback_inodes_wb(wb, work) . writeback_sb_inodes // fat's bdev . __writeback_single_inode . . generic_writepages . . __block_write_full_page . . . . __generic_file_fsync . . . . sync_inode_metadata . . . . writeback_single_inode . . . . __writeback_single_inode . . . . fat_write_inode . . . . __fat_write_inode . . . . sync_dirty_buffer // fat's bdev . . . . lock_buffer(bh) // LOCK B . . . . submit_bh . . . . blk_mq_get_tag // LOCK A . . . trylock_buffer(bh) // LOCK B . . . redirty_page_for_writepage . . . wbc->pages_skipped++ . . --wbc->nr_to_write . wrote += write_chunk - wbc.nr_to_write // wrote > 0 . requeue_inode . redirty_tail_locked if (progress) // progress > 0 continue; iter i+1: queue_io // similar process with iter i, infinite for-loop ! } blk_finish_plug(&plug) // flush plug won't be called Above process triggers a hungtask like: [ 399.044861] INFO: task bb:2607 blocked for more than 30 seconds. [ 399.046824] Not tainted 5.18.0-rc1-00005-gefae4d9eb6a2-dirty [ 399.051539] task:bb state:D stack: 0 pid: 2607 ppid: 2426 flags:0x00004000 [ 399.051556] Call Trace: [ 399.051570] __schedule+0x480/0x1050 [ 399.051592] schedule+0x92/0x1a0 [ 399.051602] io_schedule+0x22/0x50 [ 399.051613] blk_mq_get_tag+0x1d3/0x3c0 [ 399.051640] __blk_mq_alloc_requests+0x21d/0x3f0 [ 399.051657] blk_mq_submit_bio+0x68d/0xca0 [ 399.051674] __submit_bio+0x1b5/0x2d0 [ 399.051708] submit_bio_noacct+0x34e/0x720 [ 399.051718] submit_bio+0x3b/0x150 [ 399.051725] submit_bh_wbc+0x161/0x230 [ 399.051734] __sync_dirty_buffer+0xd1/0x420 [ 399.051744] sync_dirty_buffer+0x17/0x20 [ 399.051750] __fat_write_inode+0x289/0x310 [ 399.051766] fat_write_inode+0x2a/0xa0 [ 399.051783] __writeback_single_inode+0x53c/0x6f0 [ 399.051795] writeback_single_inode+0x145/0x200 [ 399.051803] sync_inode_metadata+0x45/0x70 [ 399.051856] __generic_file_fsync+0xa3/0x150 [ 399.051880] fat_file_fsync+0x1d/0x80 [ 399.051895] vfs_fsync_range+0x40/0xb0 [ 399.051929] __x64_sys_fsync+0x18/0x30 In my test, 'need_resched()' (which is imported by 590dca3a71 "fs-writeback: unplug before cond_resched in writeback_sb_inodes") in function 'writeback_sb_inodes()' seldom comes true, unless cond_resched() is deleted from write_cache_pages(). Fix it by correcting wrote number according number of skipped pages in writeback_sb_inodes(). Goto Link to find a reproducer. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215837 Cc: [email protected] # v4.3 Signed-off-by: Zhihao Cheng <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2022-05-19xen/xenbus: eliminate xenbus_grant_ring()Juergen Gross2-48/+19
There is no external user of xenbus_grant_ring() left, so merge it into the only caller xenbus_setup_ring(). Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-34/+10
Simplify sndfront's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Tested-by: Oleksandr Tyshchenko <[email protected]> # Arm64 only Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/usbfront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-46/+15
Simplify xen-hcd's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/scsifront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-21/+7
Simplify scsifront's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/pcifront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-16/+3
Simplify pcifront's shared page creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-32/+11
Simplify drmfront's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Tested-by: Oleksandr Tyshchenko <[email protected]> # Arm64 only Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/tpmfront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-15/+3
Simplify tpmfront's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(), which are provided exactly for the use pattern as seen in this driver. Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/netfront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-41/+12
Simplify netfront's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/blkfront: use xenbus_setup_ring() and xenbus_teardown_ring()Juergen Gross1-29/+8
Simplify blkfront's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/xenbus: add xenbus_setup_ring() service functionJuergen Gross2-0/+73
Most PV device frontends share very similar code for setting up shared ring buffers: - allocate page(s) - init the ring admin data - give the backend access to the ring via grants Tearing down the ring requires similar actions in all frontends again: - remove grants - free the page(s) Provide service functions xenbus_setup_ring() and xenbus_teardown_ring() for that purpose. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen: update ring.hJuergen Gross2-7/+16
Update include/xen/interface/io/ring.h to its newest version. Switch the two improper use cases of RING_HAS_UNCONSUMED_RESPONSES() to XEN_RING_NR_UNCONSUMED_RESPONSES() in order to avoid the nasty XEN_RING_HAS_UNCONSUMED_IS_BOOL #define. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REFJuergen Gross1-13/+5
Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Tested-by: Oleksandr Tyshchenko <[email protected]> # Arm64 only Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/dmabuf: switch gntdev-dmabuf to use INVALID_GRANT_REFJuergen Gross1-11/+2
Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/sound: switch xen_snd_front to use INVALID_GRANT_REFJuergen Gross2-11/+2
Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Tested-by: Oleksandr Tyshchenko <[email protected]> # Arm64 only Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/drm: switch xen_drm_front to use INVALID_GRANT_REFJuergen Gross2-11/+2
Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Tested-by: Oleksandr Tyshchenko <[email protected]> # Arm64 only Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/usb: switch xen-hcd to use INVALID_GRANT_REFJuergen Gross1-8/+6
Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/scsifront: remove unused GRANT_INVALID_REF definitionJuergen Gross1-3/+0
GRANT_INVALID_REF isn't used in scsifront, so remove it. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/netfront: switch netfront to use INVALID_GRANT_REFJuergen Gross1-19/+17
Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/blkfront: switch blkfront to use INVALID_GRANT_REFJuergen Gross1-14/+12
Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/grant-table: never put a reserved grant on the free listJuergen Gross1-0/+4
Make sure a reserved grant is never put on the free list, as this could cause hard to debug errors. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen: update grant_table.hJuergen Gross3-68/+103
Update include/xen/interface/grant_table.h to its newest version. This allows to drop some private definitions in grant-table.c and include/xen/grant_table.h. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/scsifront: harden driver against malicious backendJuergen Gross1-28/+76
Instead of relying on a well behaved PV scsi backend verify all meta data received from the backend and avoid multiple reads of the same data from the shared ring page. In case any illegal data from the backend is detected switch the PV device to a new "error" state and deactivate it for further use. Use the "lateeoi" variant for the event channel in order to avoid event storms blocking the guest. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/scsifront: use new command result macrosJuergen Gross1-8/+56
Add a translation layer for the command result values. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen/scsiback: use new command result macrosJuergen Gross1-3/+79
Instead of using the kernel's values for the result of PV scsi operations use the values of the interface definition. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19xen: update vscsiif.hJuergen Gross1-4/+129
Update include/xen/interface/io/vscsiif.h to its newest version. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2022-05-19x86/boot: Wrap literal addresses in absolute_pointer()Kees Cook2-13/+25
GCC 11 (incorrectly[1]) assumes that literal values cast to (void *) should be treated like a NULL pointer with an offset, and raises diagnostics when doing bounds checking under -Warray-bounds. GCC 12 got "smarter" about finding these: In function 'rdfs8', inlined from 'vga_recalc_vertical' at /srv/code/arch/x86/boot/video-mode.c:124:29, inlined from 'set_mode' at /srv/code/arch/x86/boot/video-mode.c:163:3: /srv/code/arch/x86/boot/boot.h:114:9: warning: array subscript 0 is outside array bounds of 'u8[0]' {aka 'unsigned char[]'} [-Warray-bounds] 114 | asm volatile("movb %%fs:%1,%0" : "=q" (v) : "m" (*(u8 *)addr)); | ^~~ This has been solved in other places[2] already by using the recently added absolute_pointer() macro. Do the same here. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 [2] https://lore.kernel.org/all/[email protected]/ Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-19thermal: k3_j72xx_bandgap: Add the bandgap driver supportKeerthy2-1/+567
Add VTM thermal support. In the Voltage Thermal Management Module(VTM), K3 J72XX supplies a voltage reference and a temperature sensor feature that are gathered in the band gap voltage and temperature sensor (VBGAPTS) module. The band gap provides current and voltage reference for its internal circuits and other analog IP blocks. The analog-to-digital converter (ADC) produces an output value that is proportional to the silicon temperature. Currently reading temperatures only is supported. There are no active/passive cooling agent supported. J721e SoCs have errata i2128: https://www.ti.com/lit/pdf/sprz455 The VTM Temperature Monitors (TEMPSENSORs) are trimmed during production, with the resulting values stored in software-readable registers. Software should use these register values when translating the Temperature Monitor output codes to temperature values. It has an involved workaround. Software needs to read the error codes for -40C, 30C, 125C from the efuse for each device & derive a new look up table for adc to temperature conversion. Involved calculating slopes & constants using 3 different straight line equations with adc refernce codes as the y-axis & error codes in the x-axis. -40C to 30C 30C to 125C 125C to 150C With the above 2 line equations we derive the full look-up table to workaround the errata i2128 for j721e SoC. Tested temperature reading on J721e SoC & J7200 SoC. [[email protected]: Generate look-up tables run-time] Signed-off-by: Daniel Lezcano <[email protected]> Signed-off-by: Keerthy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19dt-bindings: thermal: k3-j72xx: Add VTM bindings documentationKeerthy1-0/+63
Add VTM bindings documentation. In the Voltage Thermal Management Module(VTM), K3 J72XX supplies a voltage reference and a temperature sensor feature that are gathered in the band gap voltage and temperature sensor (VBGAPTS) module. The band gap provides current and voltage reference for its internal circuits and other analog IP blocks. The analog-to-digital converter (ADC) produces an output value that is proportional to the silicon temperature. Signed-off-by: Keerthy <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probeMiaoqian Lin1-2/+4
of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: e20db70dba1c ("thermal: imx_sc: add i.MX system controller thermal support") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19thermal/core: Fix memory leak in __thermal_cooling_device_register()Yang Yingliang1-0/+1
I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888010080000 (size 264312): comm "182", pid 102533, jiffies 4296434960 (age 10.100s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 40 7f 1f b9 ff ff ff ff ........@....... backtrace: [<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969 [<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510 [<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586 [<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927 [<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041 [<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211 [<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561 If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called to free the memory allocated in thermal_cooling_device_setup_sysfs(). Fixes: 8ea229511e06 ("thermal: Add cooling device's statistics in sysfs") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19dt-bindings: thermal: tsens: Add sc8280xp compatibleBjorn Andersson1-0/+1
The Qualcomm SC8280XP platform has three instances of the tsens block, add a compatible for these instances. Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19dt-bindings: thermal: lmh: Add Qualcomm sc8180x compatibleBjorn Andersson1-0/+1
Add compatible for the LMh blocks found in the Qualcomm sc8180x platform. Signed-off-by: Bjorn Andersson <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19thermal/drivers/qcom/lmh: Add sc8180x compatibleBjorn Andersson1-0/+1
The LMh instances in the Qualcomm SC8180X platform looks to behave similar to those in SM8150, add additional compatibles to allow platform specific behavior to be added if needed. Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19thermal/drivers/rz2gl: Fix OTP Calibration Register valuesBiju Das1-2/+8
As per the latest RZ/G2L Hardware User's Manual (Rev.1.10 Apr, 2022), the bit 31 of TSU OTP Calibration Register(OTPTSUTRIM) indicates whether bit [11:0] of OTPTSUTRIM is valid or invalid. This patch updates the code to reflect this change. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19dt-bindings: thermal: rzg2l-thermal: Document RZ/G2UL bindingsBiju Das1-0/+1
Document RZ/G2UL TSU bindings. The TSU block on RZ/G2UL is identical to one found on RZ/G2L SoC. No driver changes are required as generic compatible string "renesas,rzg2l-tsu" will be used as a fallback. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19thermal: thermal_of: fix typo on __thermal_bind_paramsCorentin Labbe1-1/+1
Add a missing s to __thermal_bind_param kernel doc comment. This fixes the following sparse warnings: drivers/thermal/thermal_of.c:50: warning: expecting prototype for struct __thermal_bind_param. Prototype was for struct __thermal_bind_params instead Signed-off-by: Corentin Labbe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19tools/thermal: remove unneeded semicolonJiapeng Chong1-1/+1
Fix the following coccicheck warnings: ./tools/thermal/thermometer/thermometer.c:147:3-4: Unneeded semicolon. Reported-by: Abaci Robot <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19tools/lib/thermal: remove unneeded semicolonJiapeng Chong1-1/+1
Fix the following coccicheck warnings: ./tools/lib/thermal/commands.c:215:2-3: Unneeded semicolon. Reported-by: Abaci Robot <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
2022-05-19thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probeZheng Yongjun1-0/+3
platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. Fixes: 250e211057c72 ("thermal: broadcom: Add Stingray thermal driver") Signed-off-by: Zheng Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.