| Age | Commit message (Collapse) | Author |
|---|
|
According to the description, CONFIG_BTRFS_DEBUG is only for extra
debug info, meanwhile sanity checks should be managed by
CONFIG_BTRFS_ASSERT.
There is no need to check both to enable assert_rbio().
Just remove the check for CONFIG_BTRFS_DEBUG.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
Running fstests btrfs/011 with MKFS_OPTIONS="-O rst" to force the usage of
the RAID stripe-tree, we get the following splat from lockdep:
BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started
============================================
WARNING: possible recursive locking detected
6.11.0-rc3-btrfs-for-next #599 Not tainted
--------------------------------------------
btrfs/2326 is trying to acquire lock:
ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
but task is already holding lock:
ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&fs_info->dev_replace.rwsem);
lock(&fs_info->dev_replace.rwsem);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by btrfs/2326:
#0: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250
stack backtrace:
CPU: 1 UID: 0 PID: 2326 Comm: btrfs Not tainted 6.11.0-rc3-btrfs-for-next #599
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x80
__lock_acquire+0x2798/0x69d0
? __pfx___lock_acquire+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
lock_acquire+0x19d/0x4a0
? btrfs_map_block+0x39f/0x2250
? __pfx_lock_acquire+0x10/0x10
? find_held_lock+0x2d/0x110
? lock_is_held_type+0x8f/0x100
down_read+0x8e/0x440
? btrfs_map_block+0x39f/0x2250
? __pfx_down_read+0x10/0x10
? do_raw_read_unlock+0x44/0x70
? _raw_read_unlock+0x23/0x40
btrfs_map_block+0x39f/0x2250
? btrfs_dev_replace_by_ioctl+0xd69/0x1d00
? btrfs_bio_counter_inc_blocked+0xd9/0x2e0
? __kasan_slab_alloc+0x6e/0x70
? __pfx_btrfs_map_block+0x10/0x10
? __pfx_btrfs_bio_counter_inc_blocked+0x10/0x10
? kmem_cache_alloc_noprof+0x1f2/0x300
? mempool_alloc_noprof+0xed/0x2b0
btrfs_submit_chunk+0x28d/0x17e0
? __pfx_btrfs_submit_chunk+0x10/0x10
? bvec_alloc+0xd7/0x1b0
? bio_add_folio+0x171/0x270
? __pfx_bio_add_folio+0x10/0x10
? __kasan_check_read+0x20/0x20
btrfs_submit_bio+0x37/0x80
read_extent_buffer_pages+0x3df/0x6c0
btrfs_read_extent_buffer+0x13e/0x5f0
read_tree_block+0x81/0xe0
read_block_for_search+0x4bd/0x7a0
? __pfx_read_block_for_search+0x10/0x10
btrfs_search_slot+0x78d/0x2720
? __pfx_btrfs_search_slot+0x10/0x10
? lock_is_held_type+0x8f/0x100
? kasan_save_track+0x14/0x30
? __kasan_slab_alloc+0x6e/0x70
? kmem_cache_alloc_noprof+0x1f2/0x300
btrfs_get_raid_extent_offset+0x181/0x820
? __pfx_lock_acquire+0x10/0x10
? __pfx_btrfs_get_raid_extent_offset+0x10/0x10
? down_read+0x194/0x440
? __pfx_down_read+0x10/0x10
? do_raw_read_unlock+0x44/0x70
? _raw_read_unlock+0x23/0x40
btrfs_map_block+0x5b5/0x2250
? __pfx_btrfs_map_block+0x10/0x10
scrub_submit_initial_read+0x8fe/0x11b0
? __pfx_scrub_submit_initial_read+0x10/0x10
submit_initial_group_read+0x161/0x3a0
? lock_release+0x20e/0x710
? __pfx_submit_initial_group_read+0x10/0x10
? __pfx_lock_release+0x10/0x10
scrub_simple_mirror.isra.0+0x3eb/0x580
scrub_stripe+0xe4d/0x1440
? lock_release+0x20e/0x710
? __pfx_scrub_stripe+0x10/0x10
? __pfx_lock_release+0x10/0x10
? do_raw_read_unlock+0x44/0x70
? _raw_read_unlock+0x23/0x40
scrub_chunk+0x257/0x4a0
scrub_enumerate_chunks+0x64c/0xf70
? __mutex_unlock_slowpath+0x147/0x5f0
? __pfx_scrub_enumerate_chunks+0x10/0x10
? bit_wait_timeout+0xb0/0x170
? __up_read+0x189/0x700
? scrub_workers_get+0x231/0x300
? up_write+0x490/0x4f0
btrfs_scrub_dev+0x52e/0xcd0
? create_pending_snapshots+0x230/0x250
? __pfx_btrfs_scrub_dev+0x10/0x10
btrfs_dev_replace_by_ioctl+0xd69/0x1d00
? lock_acquire+0x19d/0x4a0
? __pfx_btrfs_dev_replace_by_ioctl+0x10/0x10
? lock_release+0x20e/0x710
? btrfs_ioctl+0xa09/0x74f0
? __pfx_lock_release+0x10/0x10
? do_raw_spin_lock+0x11e/0x240
? __pfx_do_raw_spin_lock+0x10/0x10
btrfs_ioctl+0xa14/0x74f0
? lock_acquire+0x19d/0x4a0
? find_held_lock+0x2d/0x110
? __pfx_btrfs_ioctl+0x10/0x10
? lock_release+0x20e/0x710
? do_sigaction+0x3f0/0x860
? __pfx_do_vfs_ioctl+0x10/0x10
? do_raw_spin_lock+0x11e/0x240
? lockdep_hardirqs_on_prepare+0x270/0x3e0
? _raw_spin_unlock_irq+0x28/0x50
? do_sigaction+0x3f0/0x860
? __pfx_do_sigaction+0x10/0x10
? __x64_sys_rt_sigaction+0x18e/0x1e0
? __pfx___x64_sys_rt_sigaction+0x10/0x10
? __x64_sys_close+0x7c/0xd0
__x64_sys_ioctl+0x137/0x190
do_syscall_64+0x71/0x140
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f0bd1114f9b
Code: Unable to access opcode bytes at 0x7f0bd1114f71.
RSP: 002b:00007ffc8a8c3130 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f0bd1114f9b
RDX: 00007ffc8a8c35e0 RSI: 00000000ca289435 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000007
R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffc8a8c6c85
R13: 00000000398e72a0 R14: 0000000000004361 R15: 0000000000000004
</TASK>
This happens because on RAID stripe-tree filesystems we recurse back into
btrfs_map_block() on scrub to perform the logical to device physical
mapping.
But as the device replace task is already holding the dev_replace::rwsem
we deadlock.
So don't take the dev_replace::rwsem in case our task is the task performing
the device replace.
Suggested-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
- Enable modular build of the new mul_u64_u64_div_u64() test.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/4092672cb64b86ec3f300b4cf0ea0c2db2b52e2e.1727699197.git.geert@linux-m68k.org
|
|
By using the printk_force_console the loglevel workaround can be removed.
The workaround existed to always send the sysrq header message to all
consoles not matter what was the current loglevel, but it won't work for
deferred messages, since the loglevel can be restore before the message
is printed, suppressing the message that wasn't supposed to be
suppressed by the workaround.
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20241105-printk-loud-con-v2-2-bd3ecdf7b0e4@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
|
|
Introduce FORCE_CON flag to printk. The new flag will make it possible to
create a context where printk messages will never be suppressed.
This mechanism will be used in the next patch to create a force_con
context on sysrq handling, removing an existing workaround on the
loglevel global variable. The workaround existed to make sure that sysrq
header messages were sent to all consoles, but this doesn't work with
deferred messages because the loglevel might be restored to its original
value before a console flushes the messages.
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20241105-printk-loud-con-v2-1-bd3ecdf7b0e4@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
|
|
Remove .owner field if calls are used which set it automatically.
./drivers/spi/spi-apple.c:522:3-8: No need to set .owner here. The core will do it.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=11799
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://patch.msgid.link/20241111065425.103645-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch adds a quirk to include the codec amplifier function for this
Dell SKU.
Note: In this SKU '0CF1', the RT722 codec amplifier is
excluded, and an external amplifier is used instead.
Signed-off-by: Deep Harsora <deep_harsora@dell.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241111070618.5414-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The audio graph card doesn't mark its subnodes such as multi {}, dpcm {}
and c2c {} as not requiring any suppliers. This causes a hang as Linux
waits for these phantom suppliers to show up on boot.
Make it clear these nodes have no suppliers.
Example error message:
[ 15.208558] platform 2034000.i2s: deferred probe pending: platform: wait for supplier /sound/multi
[ 15.208584] platform sound: deferred probe pending: asoc-audio-graph-card2: parse error
Signed-off-by: John Watts <contact@jookia.org>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/20241108-graph_dt_fix-v1-1-173e2f9603d6@jookia.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Linux 6.12-rc7
* tag 'v6.12-rc7': (1909 commits)
Linux 6.12-rc7
filemap: Fix bounds checking in filemap_read()
i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set
mailmap: add entry for Thorsten Blum
ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()
signal: restore the override_rlimit logic
fs/proc: fix compile warning about variable 'vmcore_mmap_ops'
ucounts: fix counter leak in inc_rlimit_get_ucounts()
selftests: hugetlb_dio: check for initial conditions to skip in the start
mm: fix docs for the kernel parameter ``thp_anon=``
mm/damon/core: avoid overflow in damon_feed_loop_next_input()
mm/damon/core: handle zero schemes apply interval
mm/damon/core: handle zero {aggregation,ops_update} intervals
mm/mlock: set the correct prev on failure
objpool: fix to make percpu slot allocation more robust
mm/page_alloc: keep track of free highatomic
bcachefs: Fix UAF in __promote_alloc() error path
bcachefs: Change OPT_STR max to be 1 less than the size of choices array
bcachefs: btree_cache.freeable list fixes
bcachefs: check the invalid parameter for perf test
...
|
|
pcim_iomap_table() and pcim_request_regions() have been deprecated in
e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()") and
d140f80f6035 ("PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()"),
respectively.
Replace these functions with pcim_iomap_region().
Additionally, pass the actual driver name to pcim_iomap_region() instead of
the previous pci_name(), since the @name parameter should always reflect which
driver owns a region.
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20241111103602.16615-2-pstanner@redhat.com
|
|
On x86_64, with allmodconfig, struct uprobe_task is 72 bytes long, with a
hole and some padding.
/* size: 72, cachelines: 2, members: 7 */
/* sum members: 64, holes: 1, sum holes: 4 */
/* padding: 4 */
/* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
/* last cacheline: 8 bytes */
Reorder the structure to fill the hole and avoid the padding.
This way, the whole structure fits in a single cacheline and some memory is
saved when it is allocated.
/* size: 64, cachelines: 1, members: 7 */
/* forced alignments: 1 */
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/a9f541d0cedf421f765c77a1fb93d6a979778a88.1730495562.git.christophe.jaillet@wanadoo.fr
|
|
Add mising braces after an if condition that contains scoped_guard().
This style is both preferred and necessary here, to fix warning after
scoped_guard() change in commit fcc22ac5baf0 ("cleanup: Adjust
scoped_guard() macros to avoid potential warning") to have if-else inside
of the macro. Current (no braces) use in af8133j_set_scale() yields
the following warnings:
af8133j.c:315:12: warning: suggest explicit braces to avoid ambiguous 'else' [-Wdangling-else]
af8133j.c:316:3: warning: add explicit braces to avoid dangling else [-Wdangling-else]
Fixes: fcc22ac5baf0 ("cleanup: Adjust scoped_guard() macros to avoid potential warning")
Closes: https://lore.kernel.org/oe-kbuild-all/202409270848.tTpyEAR7-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20241108154258.21411-1-przemyslaw.kitszel@intel.com
|
|
truncation in amd_uncore_umc_ctx_init
Fix the following warning:
CC [M] arch/x86/events/amd/uncore.o
arch/x86/events/amd/uncore.c: In function ‘amd_uncore_umc_ctx_init’:
arch/x86/events/amd/uncore.c:951:52: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 8 [-Wformat-truncation=]
snprintf(pmu->name, sizeof(pmu->name), "amd_umc_%d", index);
^~
arch/x86/events/amd/uncore.c:951:43: note: directive argument in the range [0, 2147483647]
snprintf(pmu->name, sizeof(pmu->name), "amd_umc_%d", index);
^~~~~~~~~~~~
arch/x86/events/amd/uncore.c:951:4: note: ‘snprintf’ output between 10 and 19 bytes into a destination of size 16
snprintf(pmu->name, sizeof(pmu->name), "amd_umc_%d", index);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As far as I can see, there can't be more than UNCORE_GROUP_MAX (256)
groups and each group can't have more than 255 PMU, so the number
printed by this %d can't exceed 65279, that's only 5 digits and would
fit into the buffer. So it's a false positive warning. But we can
make the compiler happy by declaring index as a 16-bit number.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Sandipan Das <sandipan.das@amd.com>
Link: https://lore.kernel.org/r/20241105095253.18f34b4d@endymion.delvare
|
|
When PREEMPT_RT=y, spin locks are mapped to rt_mutex types, so using
spinlock_check() + __raw_spin_lock_init() to initialize spin locks is
incorrect, and would cause build errors.
Introduce __spin_lock_init() to initialize a spin lock with lockdep
rquired information for PREEMPT_RT builds, and use it in the Rust
helper.
Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.")
Closes: https://lore.kernel.org/oe-kbuild-all/202409251238.vetlgXE9-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Eder Zulian <ezulian@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Tested-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20241107163223.2092690-2-ezulian@redhat.com
|
|
Add the "Lazy" part to the comment for TIF_NEED_RESCHED_LAZY so it is
not the same as TIF_NEED_RESCHED.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20241106162449.sk6rDddk@linutronix.de
|
|
For some, as of yet unexplained reason, Clang-19, but not GCC,
generates and endless stream of:
drivers/iio/imu/bno055/bno055_ser.o: warning: objtool: __tracepoint_send_chunk+0x20: data relocation to !ENDBR: __SCT__tp_func_send_chunk+0x0
drivers/iio/imu/bno055/bno055_ser.o: warning: objtool: __tracepoint_cmd_retry+0x20: data relocation to !ENDBR: __SCT__tp_func_cmd_retry+0x0
drivers/iio/imu/bno055/bno055_ser.o: warning: objtool: __tracepoint_write_reg+0x20: data relocation to !ENDBR: __SCT__tp_func_write_reg+0x0
drivers/iio/imu/bno055/bno055_ser.o: warning: objtool: __tracepoint_read_reg+0x20: data relocation to !ENDBR: __SCT__tp_func_read_reg+0x0
drivers/iio/imu/bno055/bno055_ser.o: warning: objtool: __tracepoint_recv+0x20: data relocation to !ENDBR: __SCT__tp_func_recv+0x0
Which is entirely correct, but harmless. Add the __tracepoints section
to the exclusion list.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20241108184618.GG38786@noisy.programming.kicks-ass.net
|
|
Backmerging to get fixes from v6.12-rc7.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
|
When the proportion of folios from the zeromap is small, missing their
accounting may not significantly impact profiling. However, it's easy to
construct a scenario where this becomes an issue—for example, allocating
1 GB of memory, writing zeros from userspace, followed by MADV_PAGEOUT,
and then swapping it back in. In this case, the swap-out and swap-in
counts seem to vanish into a black hole, potentially causing semantic
ambiguity.
On the other hand, Usama reported that zero-filled pages can exceed 10% in
workloads utilizing zswap, while Hailong noted that some app in Android
have more than 6% zero-filled pages. Before commit 0ca0c24e3211 ("mm:
store zero pages to be swapped out in a bitmap"), both zswap and zRAM
implemented similar optimizations, leading to these optimized-out pages
being counted in either zswap or zRAM counters (with pswpin/pswpout also
increasing for zRAM). With zeromap functioning prior to both zswap and
zRAM, userspace will no longer detect these swap-out and swap-in actions.
We have three ways to address this:
1. Introduce a dedicated counter specifically for the zeromap.
2. Use pswpin/pswpout accounting, treating the zero map as a standard
backend. This approach aligns with zRAM's current handling of
same-page fills at the device level. However, it would mean losing the
optimized-out page counters previously available in zRAM and would not
align with systems using zswap. Additionally, as noted by Nhat Pham,
pswpin/pswpout counters apply only to I/O done directly to the backend
device.
3. Count zeromap pages under zswap, aligning with system behavior when
zswap is enabled. However, this would not be consistent with zRAM, nor
would it align with systems lacking both zswap and zRAM.
Given the complications with options 2 and 3, this patch selects
option 1.
We can find these counters from /proc/vmstat (counters for the whole
system) and memcg's memory.stat (counters for the interested memcg).
For example:
$ grep -E 'swpin_zero|swpout_zero' /proc/vmstat
swpin_zero 1648
swpout_zero 33536
$ grep -E 'swpin_zero|swpout_zero' /sys/fs/cgroup/system.slice/memory.stat
swpin_zero 3905
swpout_zero 3985
This patch does not address any specific zeromap bug, but the missing
swpout and swpin counts for zero-filled pages can be highly confusing and
may mislead user-space agents that rely on changes in these counters as
indicators. Therefore, we add a Fixes tag to encourage the inclusion of
this counter in any kernel versions with zeromap.
Many thanks to Kanchana for the contribution of changing
count_objcg_event() to count_objcg_events() to support large folios[1],
which has now been incorporated into this patch.
[1] https://lkml.kernel.org/r/20241001053222.6944-5-kanchana.p.sridhar@intel.com
Link: https://lkml.kernel.org/r/20241107011246.59137-1-21cnbao@gmail.com
Fixes: 0ca0c24e3211 ("mm: store zero pages to be swapped out in a bitmap")
Co-developed-by: Kanchana P Sridhar <kanchana.p.sridhar@intel.com>
Signed-off-by: Barry Song <v-songbaohua@oppo.com>
Reviewed-by: Nhat Pham <nphamcs@gmail.com>
Reviewed-by: Chengming Zhou <chengming.zhou@linux.dev>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Yosry Ahmed <yosryahmed@google.com>
Cc: Hailong Liu <hailong.liu@oppo.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: Kairui Song <kasong@tencent.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
We can't assume that btrees only contain keys of a given type - even if
they only have a single key type listed in the allowed key types for
that btree; this is a forwards compatibility issue.
Reported-by: syzbot+a27c3aaa3640dd3e1dfb@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
Fixes: baefd3f849ed ("bcachefs: btree_cache.freeable list fixes")
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
PMBUS_NO_WRITE_PROTECT and PMBUS_USE_COEFFICIENTS_CMD flags have been added
to pmbus, but the corresponding documentation was not updated.
Update the documentation before adding new flags
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Message-ID: <20241105-tps25990-v4-1-0e312ac70b62@baylibre.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
SY24655: Support for current and voltage detection as well as
power calculation.
Signed-off-by: Wenliang Yan <wenliang202407@163.com>
Message-ID: <20241106150547.2538-1-wenliang202407@163.com>
[groeck: Changed order of compatible entries;
dropped spurious extra return statement in is_visible();
fixed code problems]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
SY24655 is similar to INA226. Its supply voltage and pin definitions
are therefore the same. Compared to INA226, SY24655 has two additional
registers for configuring and calculating average power.
Signed-off-by: Wenliang Yan <wenliang202407@163.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Message-ID: <20241106150547.2538-2-wenliang202407@163.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add support for LTC7841. The LTC7841 is a high performance
PolyPhase® single output synchronous boost converter controller.
Multiphase operation reduces input and output capacitor
requirements and allows the use of smaller inductors than the
single-phase equivalent.
The relevant registers in the LTC7841 are similar to the
LTC7880, only reduced by some amount. So it's just a matter of adding
the chip id. The device also doesn't support polling, on top of the
reduced register set, so a separate case for setting the chip info is
added.
Signed-off-by: Mariel Tinaco <Mariel.Tinaco@analog.com>
Message-ID: <20241029013734.293024-4-Mariel.Tinaco@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add LTC7841 to compatible devices of LTC2978
Signed-off-by: Mariel Tinaco <Mariel.Tinaco@analog.com>
Message-ID: <20241029013734.293024-3-Mariel.Tinaco@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add LTC7841 to supported devices of LTC2978. It has similar set of
registers to LTC7880, differing only in number of output channels and
some unimplemented PMBUS status and functionalities.
Signed-off-by: Mariel Tinaco <Mariel.Tinaco@analog.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Message-ID: <20241029013734.293024-2-Mariel.Tinaco@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
The NCT7363Y is a fan controller which provides up to 16
independent FAN input monitors. It can report each FAN input count
values. The NCT7363Y also provides up to 16 independent PWM
outputs. Each PWM can output specific PWM signal by manual mode to
control the FAN duty outside.
Signed-off-by: Ban Feng <kcfeng0@nuvoton.com>
Message-ID: <20241022052905.4062682-3-kcfeng0@nuvoton.com>
[groeck: Dropped unnecessary variable initialization, and , after { }]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add bindings for the Nuvoton NCT7363Y Fan Controller
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Ban Feng <kcfeng0@nuvoton.com>
Message-ID: <20241022052905.4062682-2-kcfeng0@nuvoton.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Remove vicor,pli1209bc from trivial-devices as it requires additional
properties and does not fit into the trivial devices category.
Add new bindings for Vicor pli1209bc, a Digital Supervisor with
Isolation for use with BCM Bus Converter Modules.
VR rails are defined under regulator node as expected by pmbus driver.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Message-ID: <20241021123044.3648960-1-naresh.solanki@9elements.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Remove mps297x from trivial-devices as it requires
additional properties and does not fit into the trivial
devices category.
Add new bindings for MPS mp2971, mp2973 & mp2975.
It is Dual-Loop, Digital Multi-Phase Controller with PMBUS
interface
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Message-ID: <20241022103750.572677-1-naresh.solanki@9elements.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Per his request, remove Aleksandr Mezin as maintainer of the
NZXT-SMART2 hardware monitoring driver.
Cc: Aleksandr Mezin <mezin.alexander@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Boards such as
* Pro WS 665-ACE
* Pro WS 600M-CL
have got a nct6775 chip, but by default there's no use of it
because of resource conflict with WMI method.
Add affected boards to the WMI monitoring list.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Co-developed-by: Tommy Giesler <tommy.giesler@hetzner.com>
Signed-off-by: Tommy Giesler <tommy.giesler@hetzner.com>
Signed-off-by: Sarah Maedel <sarah.maedel@hetzner-cloud.de>
Message-ID: <20241018074611.358619-1-sarah.maedel@hetzner-cloud.de>
[groeck: Change commit message to imperative mood]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Driver for Renesas ISL28022 power monitor with I2C interface.
The device monitors voltage, current via shunt resistor
and calculated power.
Signed-off-by: Carsten Spieß <mail@carsten-spiess.de>
Signed-off-by: Yikai Tsai <yikai.tsai.wiwynn@gmail.com>
Message-ID: <20241002081133.13123-3-yikai.tsai.wiwynn@gmail.com>
[groeck: Fixed alignment issues, dropped noise at end of probe]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add dt-bindings for Renesas ISL28022 power monitor.
Signed-off-by: Carsten Spieß <mail@carsten-spiess.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Yikai Tsai <yikai.tsai.wiwynn@gmail.com>
Message-ID: <20241002081133.13123-2-yikai.tsai.wiwynn@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/hwmonto use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
While touching these files, make indention of the struct initializer
consistent in several files.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Message-ID: <20241017155900.137357-2-u.kleine-koenig@baylibre.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add support for manipulating the internal heater of sht4x devices.
Enabling the heater removes condensed water from the sensor surface
which disturbs the relative humidity measurements.
The heater can operate at three heating levels (20, 110 or 200
milliwatts). Also, two heating durations may be selected (0.1 or 1s).
Once the heating time elapses the heater is automatically switched off.
Changes since v3:
* struct sht4x_data: add heating_complete timestamp
* struct sht4x_data: add data_pending flag
* heater_enable_store: return -EINVAL if input != 1
* heater_enable_store: check for data->heating_complete and update it
* heater_enable_store: set data_pending flag after heating request
* sht4x_read_values: msleep if heating in progress
* sht4x_read_values: dont send measurement request if data_pending
* heater_enable attr: make it RW
* Documentation: update info about heater_enable attr
Changes since v2:
* heater_enable_store: remove unnecessary if
* Documentation: remove incorrect info about turning off the heater
* be more specific in the patch description
Changes since v1:
* explain the use case of the new attributes set
* heater_enable attr: make it write-only
* heater_enable_store: define cmd as u8 instead of u8*
* heater_enable_store: remove unreachable data path
* heater_enable_store: remove unnecessary lock
* heater_enable_store: call i2c_master_send only if status==true
* define attributes as DEVICE_ATTR_* instead of SENSOR_DEVICE_ATTR_*
Signed-off-by: Antoni Pokusinski <apokusinski01@gmail.com>
Message-ID: <20240930205346.2147-1-apokusinski01@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <1ac2be2d-df4f-455a-900d-821fc7bd12c4@gmail.com>
Acked-by: Jonas Malaco <jonas@protocubo.io>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <8ef99170-b37d-4c9a-b3bf-59f4ea76cf29@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <4e8893a1-b080-4676-97b9-a48ac9ead28a@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Message-ID: <c4b4568b-59f6-43ac-8281-536a82ecd6ab@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <bd909a2c-23ee-437d-9bd4-858119f6f266@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <5c26d8cf-d6dc-46c5-be7c-fd8207b3f177@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <d5d2570c-dfd9-4be5-ad9f-e721be477131@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Use new member visible of struct hwmon_ops to simplify specifying
the static attribute visibility.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <2b1f2778-1127-4979-b02d-f75e16497ad7@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Remove platform data & initialize with defaults
configuration & overwrite based on DT properties.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Message-ID: <20241007090426.811736-1-naresh.solanki@9elements.com>
[groeck: Dropped some unnecessary empty lines]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Several drivers return the same static value in their is_visible
callback, what results in code duplication. Therefore add an option
for drivers to specify a static visibility directly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Message-ID: <89690b81-2c73-47ae-9ae9-45c77b45ca0c@gmail.com>
groeck: Renamed hwmon_ops_is_visible -> hwmon_is_visible
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Below mentioned spelling errors reported by codesepll
were fixed:
respresents ==> represents
signifcant ==> significant
bandwitdh ==> bandwidth
Signed-off-by: Everest K.C. <everestkc@everestkc.com.np>
Message-ID: <20241001011521.80982-1-everestkc@everestkc.com.np>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Theobroma Systems Mule is an MCU that emulates a set of I2C devices,
among which is an amc6821 and other devices that are reachable through
an I2C-mux.
The devices on the mux can be selected by writing the appropriate device
number to an I2C config register (amc6821: reg 0xff)
Implement "tsd,mule" compatible to instantiate the I2C-mux platform device
when probing the amc6821.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Farouk Bouabid <farouk.bouabid@cherry.de>
Message-ID: <20240906-dev-mule-i2c-mux-v8-4-dbd28a150e41@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Add dt-bindings for amc6821 intelligent temperature monitor and
pulse-width modulation (PWM) fan controller.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Farouk Bouabid <farouk.bouabid@cherry.de>
Message-ID: <20240906-dev-mule-i2c-mux-v8-3-dbd28a150e41@cherry.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
To ensure code clarity and prevent potential errors, use ';' instead of
',' as a statement separator in the function mpq8785_identify.
Signed-off-by: Shen Lichuan <shenlichuan@vivo.com>
Message-ID: <20240919064939.3282-1-shenlichuan@vivo.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
