Re: [PATCH 1/4] i2c: pasemi: Add registers bits and switch to BIT()
Thu, Mar 20, 2025 at 01:23:25AM +0100, Andi Shyti kirjoitti: > Hi Sven, > > On Sat, Feb 22, 2025 at 01:38:33PM +, Sven Peter via B4 Relay wrote: > > From: Sven Peter > > > > Add the missing register bits to the defines and also switch > > those to use the BIT macro which is much more readable than > > using hardcoded masks > > > > Co-developed-by: Hector Martin > > Signed-off-by: Hector Martin > > Signed-off-by: Sven Peter > > Just this patch merged to i2c/i2c-host. This needs an update as well. The proper header for BIT() et al. is bits.h. bitfield.h is for FIELD_*() et al. -- With Best Regards, Andy Shevchenko
Re: [PATCH 2/4] i2c: pasemi: Improve error recovery
Hi Andi,
Thanks for the review! Will send a v2 after -rc1 is out.
On Thu, Mar 20, 2025, at 01:17, Andi Shyti wrote:
> Hi Sven,
>
> On Sat, Feb 22, 2025 at 01:38:34PM +, Sven Peter via B4 Relay wrote:
>> The hardware (supposedly) has a 25ms timeout for clock stretching
>> and the driver uses 100ms which should be plenty.
>
> Can we add this lines as a comment to the define you are adding?
Sure.
>
>> The error
>> reocvery itself is however lacking.
>
> ...
>
>> -static void pasemi_smb_clear(struct pasemi_smbus *smbus)
>> +static int pasemi_smb_clear(struct pasemi_smbus *smbus)
>> {
>> unsigned int status;
>> +int timeout = TRANSFER_TIMEOUT_MS;
>>
>> status = reg_read(smbus, REG_SMSTA);
>> +
>> +/* First wait for the bus to go idle */
>> +while ((status & (SMSTA_XIP | SMSTA_JAM)) && timeout--) {
>> +msleep(1);
>
> Please, use usleep_range for 1 millisecond timeout.
Ack.
>
>> +status = reg_read(smbus, REG_SMSTA);
>> +}
>
> You could use here readx_poll_timeout() here.
Yup, that should work.
>
>> +
>> +if (timeout < 0) {
>> +dev_warn(smbus->dev, "Bus is still stuck (status 0x%08x)\n",
>> status);
>
> if it's an error, please use an error.
Ack.
>
>> +return -EIO;
>> +}
>> +
>> +/* If any badness happened or there is data in the FIFOs, reset the
>> FIFOs */
>> +if ((status & (SMSTA_MRNE | SMSTA_JMD | SMSTA_MTO | SMSTA_TOM |
>> SMSTA_MTN | SMSTA_MTA)) ||
>> +!(status & SMSTA_MTE))
>
> Please, fixe the alignment here.
Ok.
>
>> +pasemi_reset(smbus);
>> +
>> +/* Clear the flags */
>> reg_write(smbus, REG_SMSTA, status);
>> +
>> +return 0;
>> }
>>
>> static int pasemi_smb_waitready(struct pasemi_smbus *smbus)
>> {
>> -int timeout = 100;
>> +int timeout = TRANSFER_TIMEOUT_MS;
>> unsigned int status;
>>
>> if (smbus->use_irq) {
>> reinit_completion(&smbus->irq_completion);
>> -reg_write(smbus, REG_IMASK, SMSTA_XEN | SMSTA_MTN);
>> -wait_for_completion_timeout(&smbus->irq_completion,
>> msecs_to_jiffies(100));
>> +/* XEN should be set when a transaction terminates, whether due
>> to error or not */
>> +reg_write(smbus, REG_IMASK, SMSTA_XEN);
>> +wait_for_completion_timeout(&smbus->irq_completion,
>> msecs_to_jiffies(timeout));
>
> what happens if the timeout expires?
I think that can only happen if the hardware is seriously broken because
it's always supposed to set XEN. I'll make sure to catch that case in v2
though and print a separate error message similar to how the polling case
below is taken care of right now.
>
>> reg_write(smbus, REG_IMASK, 0);
>> status = reg_read(smbus, REG_SMSTA);
>> } else {
>
> ...
>
>> struct pasemi_smbus *smbus = adapter->algo_data;
>> int ret, i;
>>
>> -pasemi_smb_clear(smbus);
>> +if (pasemi_smb_clear(smbus))
>> +return -EIO;
>
> Can we use
>
> ret = ...
> if (ret)
> return ret;
>
> This way we return whatever comes from pasemi_smb_clear().
>
>>
>> ret = 0;
>
> This way we can remove this line, as well.
Sure, will do both for v2.
Thanks,
Sven
Re: [PATCH] tools/perf/arch/powerpc/util: Fix is_compat_mode build break in ppc64
> On 21 Mar 2025, at 3:37 PM, Likhitha Korrapati wrote:
>
> Commit 54f9aa1092457 ("tools/perf/powerpc/util: Add support to
> handle compatible mode PVR for perf json events") introduced
> to select proper JSON events in case of compat mode using
> auxiliary vector. But this caused a compilation error in ppc64
> Big Endian.
>
> arch/powerpc/util/header.c: In function 'is_compat_mode':
> arch/powerpc/util/header.c:20:21: error: cast to pointer from
> integer of different size [-Werror=int-to-pointer-cast]
> 20 | if (!strcmp((char *)platform, (char *)base_platform))
> | ^
> arch/powerpc/util/header.c:20:39: error: cast to pointer from
> integer of different size [-Werror=int-to-pointer-cast]
> 20 | if (!strcmp((char *)platform, (char *)base_platform))
> |
>
> Commit saved the getauxval(AT_BASE_PLATFORM) and getauxval(AT_PLATFORM)
> return values in u64 which causes the compilation error.
>
> Patch fixes this issue by changing u64 to "unsigned long".
>
> Fixes: 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle
> compatible mode PVR for perf json events")
> Signed-off-by: Likhitha Korrapati
Hi Likhitha,
Thanks for the fix.
Reviewed-by: Athira Rajeev
Thanks
Athira
> ---
> tools/perf/arch/powerpc/util/header.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/arch/powerpc/util/header.c
> b/tools/perf/arch/powerpc/util/header.c
> index c7df534dbf8f..0be74f048f96 100644
> --- a/tools/perf/arch/powerpc/util/header.c
> +++ b/tools/perf/arch/powerpc/util/header.c
> @@ -14,8 +14,8 @@
>
> static bool is_compat_mode(void)
> {
> - u64 base_platform = getauxval(AT_BASE_PLATFORM);
> - u64 platform = getauxval(AT_PLATFORM);
> + unsigned long base_platform = getauxval(AT_BASE_PLATFORM);
> + unsigned long platform = getauxval(AT_PLATFORM);
>
> if (!strcmp((char *)platform, (char *)base_platform))
> return false;
> --
> 2.43.5
>
Re: [linux-next-20250320][btrfs] Kernel OOPs while running btrfs/108
On 22/03/25 2:48 am, Qu Wenruo wrote: 在 2025/3/22 02:26, Ritesh Harjani (IBM) 写道: +linux-btrfs Venkat Rao Bagalkote writes: Greetings!!! I am observing Kernel oops while running brtfs/108 TC on IBM Power System. Repo: Linux-Next (next-20250320) Looks like this next tag had many btrfs related changes - https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/fs/btrfs?h=next-20250320 Traces: [ 418.392604] run fstests btrfs/108 at 2025-03-21 05:11:21 [ 418.560137] Kernel attempted to read user page (0) - exploit attempt? (uid: 0) [ 418.560156] BUG: Kernel NULL pointer dereference on read at 0x NULL pointer dereference... [ 418.560161] Faulting instruction address: 0xc10ef8b0 [ 418.560166] Oops: Kernel access of bad area, sig: 11 [#1] [ 418.560169] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries [ 418.560174] Modules linked in: btrfs blake2b_generic xor raid6_pq zstd_compress loop nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 bonding nf_defrag_ipv4 tls rfkill ip_set nf_tables nfnetlink sunrpc pseries_rng vmx_crypto fuse ext4 mbcache jbd2 sd_mod sg ibmvscsi scsi_transport_srp ibmveth [ 418.560212] CPU: 1 UID: 0 PID: 37583 Comm: rm Kdump: loaded Not tainted 6.14.0-rc7-next-20250320 #1 VOLUNTARY [ 418.560218] Hardware name: IBM,9080-HEX Power11 [ 418.560223] NIP: c10ef8b0 LR: c0080bb190ac CTR: c10ef888 [ 418.560227] REGS: c000a252f5a0 TRAP: 0300 Not tainted (6.14.0-rc7-next-20250320) [ 418.560232] MSR: 80009033 CR: 44008444 XER: 2004 [ 418.560240] CFAR: c0080bc1df84 DAR: DSISR: 4000 IRQMASK: 1 [ 418.560240] GPR00: c0080bb190ac c000a252f840 c16a8100 [ 418.560240] GPR04: 0001 fffe [ 418.560240] GPR08: c0010724aad8 0003 1000 c0080bc1df70 [ 418.560240] GPR12: c10ef888 c00adb00 [ 418.560240] GPR16: [ 418.560240] GPR20: c000777a8000 c0006a9c9000 c0010724a950 c000777a8000 [ 418.560240] GPR24: fffe c0010724aad8 0001 00a0 [ 418.560240] GPR28: 0001 c00c0048c3c0 [ 418.560287] NIP [c10ef8b0] _raw_spin_lock_irq+0x28/0x98 [ 418.560294] LR [c0080bb190ac] wait_subpage_spinlock+0x64/0xd0 [btrfs] btrfs is working on subpage size support for a while now. Adding +linux-btrfs, in case if they are already aware of this problem. I am not that familiar with btrfs code. But does this look like that the subpage (folio->private became NULL here) somehow? The for-next branch seems to have some conflicts, IIRC the following two commits are no longer in our tree anymore: btrfs: kill EXTENT_FOLIO_PRIVATE btrfs: add mapping_set_release_always to inode's mapping I believe those two may be the cause. Mind to test with the our current for-next branch? Where that's all of our development happening, and I run daily subpage fstests on it to make sure at least that branch is safe: https://github.com/btrfs/linux/tree/for-next And appreciate if you can verify if the NULL pointer dereference is still there on that branch. I verified with the for-next repo, and I dont see the issue. btrfs/108 passes. ./check btrfs/108 RECREATING -- btrfs on /dev/loop0 FSTYP -- btrfs PLATFORM -- Linux/ppc64le ltcden8-lp1 6.14.0-rc7-g88d324e69ea9 #1 SMP Sat Mar 22 07:47:48 CDT 2025 MKFS_OPTIONS -- -f -s 4096 -n 4096 /dev/loop1 MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/loop1 /mnt/scratch btrfs/108 1s Ran: btrfs/108 Passed all 1 tests Repo: https://github.com/btrfs/linux/tree/for-next Regards, Venkat. Thanks, Qu -ritesh [ 418.560339] Call Trace: [ 418.560342] [c000a252f870] [c0080bb205dc] btrfs_invalidate_folio+0xa8/0x4f0 [btrfs] [ 418.560384] [c000a252f930] [c04cbcdc] truncate_cleanup_folio+0x110/0x14c [ 418.560391] [c000a252f960] [c04ccc7c] truncate_inode_pages_range+0x100/0x4dc [ 418.560397] [c000a252fbd0] [c0080bb20ba8] btrfs_evict_inode+0x74/0x510 [btrfs] [ 418.560437] [c000a252fc90] [c065c71c] evict+0x164/0x334 [ 418.560443] [c000a252fd30] [c0647c9c] do_unlinkat+0x2f4/0x3a4 [ 418.560449] [c000a252fde0] [c0647da0] sys_unlinkat+0x54/0xac [ 418.560454] [c000a252fe10] [c0033498] system_call_exception+0x138/0x330 [ 418.560461] [c000a252fe50] [c000d05c] system_call_vectored_common+0x15c/0x2ec [ 418.560468] --- interrupt: 3000 at 0x7fffb1b366bc [ 418.560471] NIP: 7fffb1b366bc LR: 7fffb1b366bc CTR: [ 418.560475
Re: [PATCH v2 08/12] lib/crc_kunit.c: add KUnit test suite for CRC library functions
Hi, On Sun, Dec 01, 2024 at 05:20:52PM -0800, Eric Biggers wrote: > From: Eric Biggers > > Add a KUnit test suite for the crc16, crc_t10dif, crc32_le, crc32_be, > crc32c, and crc64_be library functions. It avoids code duplication by > sharing most logic among all CRC variants. The test suite includes: > > - Differential fuzz test of each CRC function against a simple > bit-at-a-time reference implementation. > - Test for CRC combination, when implemented by a CRC variant. > - Optional benchmark of each CRC function with various data lengths. > > This is intended as a replacement for crc32test and crc16_kunit, as well > as a new test for CRC variants which didn't previously have a test. > > Reviewed-by: Ard Biesheuvel > Reviewed-by: Martin K. Petersen > Cc: Vinicius Peixoto > Signed-off-by: Eric Biggers > --- ... > + > + nosimd = rand32() % 8 == 0; > + > + /* > + * Compute the CRC, and verify that it equals the CRC computed > + * by a simple bit-at-a-time reference implementation. > + */ > + expected_crc = crc_ref(v, init_crc, &test_buffer[offset], len); > + if (nosimd) > + local_irq_disable(); > + actual_crc = v->func(init_crc, &test_buffer[offset], len); > + if (nosimd) > + local_irq_enable(); This triggers a traceback on some arm systems. [7.81] ok 2 crc16_benchmark # SKIP not enabled [7.81] [ cut here ] [7.81] WARNING: CPU: 0 PID: 1145 at kernel/softirq.c:369 __local_bh_enable_ip+0x118/0x194 [7.81] Modules linked in: [7.81] CPU: 0 UID: 0 PID: 1145 Comm: kunit_try_catch Tainted: G N 6.14.0-rc7-00196-g88d324e69ea9 #1 [7.81] Tainted: [N]=TEST [7.81] Hardware name: NPCM7XX Chip family [7.81] Call trace: [7.81] unwind_backtrace from show_stack+0x10/0x14 [7.81] show_stack from dump_stack_lvl+0x7c/0xac [7.81] dump_stack_lvl from __warn+0x7c/0x1b8 [7.81] __warn from warn_slowpath_fmt+0x19c/0x1a4 [7.81] warn_slowpath_fmt from __local_bh_enable_ip+0x118/0x194 [7.81] __local_bh_enable_ip from crc_t10dif_arch+0xd4/0xe8 [7.81] crc_t10dif_arch from crc_t10dif_wrapper+0x14/0x1c [7.81] crc_t10dif_wrapper from crc_main_test+0x178/0x360 [7.81] crc_main_test from kunit_try_run_case+0x78/0x1e0 [7.81] kunit_try_run_case from kunit_generic_run_threadfn_adapter+0x1c/0x34 [7.81] kunit_generic_run_threadfn_adapter from kthread+0x118/0x254 [7.81] kthread from ret_from_fork+0x14/0x28 [7.81] Exception stack(0xe3651fb0 to 0xe3651ff8) [7.81] 1fa0: [7.81] 1fc0: [7.81] 1fe0: 0013 [7.81] irq event stamp: 29 [7.81] hardirqs last enabled at (27): [] __local_bh_enable_ip+0xb4/0x194 [7.81] hardirqs last disabled at (28): [] crc_main_test+0x2e4/0x360 [7.81] softirqs last enabled at (26): [] kernel_neon_end+0x0/0x1c [7.81] softirqs last disabled at (29): [] kernel_neon_begin+0x0/0x70 [7.81] ---[ end trace ]--- [8.05] # crc_t10dif_test: pass:1 fail:0 skip:0 total:1 kernel_neon_end() calls local_bh_enable() which apparently conflicts with the local_irq_disable() in above code. Guenter
