* [PATCH v4 1/1] regmap: Synchronize cache for the page selector @ 2026-02-18 7:46 ` Andy Shevchenko 2026-02-18 8:30 ` Marek Szyprowski 0 siblings, 1 reply; 6+ messages in thread From: Andy Shevchenko @ 2026-02-18 7:46 UTC (permalink / raw) To: Andy Shevchenko, linux-kernel Cc: Mark Brown, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Dmitry Baryshkov, Marek Szyprowski If the selector register is represented in each page, its value according to the debugfs is stale because it gets synchronized only after the real page switch happens. Hence the regmap cache initialisation from the HW inherits outdated data in the selector register. Synchronize cache for the page selector just in time. Before (offset followed by hexdump, the first byte is selector): // Real registers 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 ... // Virtual (per port) 40: 05 ff 00 00 e0 e0 00 00 00 00 00 1f 50: 00 ff 00 00 e0 e0 00 00 00 00 00 1f 60: 01 ff 00 00 ff ff 00 00 00 00 00 00 70: 02 ff 00 00 cf f3 00 00 00 00 00 0c 80: 03 ff 00 00 00 00 00 00 00 00 00 ff 90: 04 ff 00 00 ff 0f 00 00 f0 00 00 00 After: // Real registers 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 ... // Virtual (per port) 40: 00 ff 00 00 e0 e0 00 00 00 00 00 1f 50: 01 ff 00 00 e0 e0 00 00 00 00 00 1f 60: 02 ff 00 00 ff ff 00 00 00 00 00 00 70: 03 ff 00 00 cf f3 00 00 00 00 00 0c 80: 04 ff 00 00 00 00 00 00 00 00 00 ff 90: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 Fixes: 6863ca622759 ("regmap: Add support for register indirect addressing.") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- v4: reworked the approach completely Marek, Dmitry, Please, test on your HW to be sure this will have no side effects in your case with LT9611. drivers/base/regmap/regmap.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index 5d5a3e115022..1b90f00a5005 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -1525,10 +1525,18 @@ static int _regmap_select_page(struct regmap *map, unsigned int *reg, return -EINVAL; } - /* It is possible to have selector register inside data window. - In that case, selector register is located on every page and - it needs no page switching, when accessed alone. */ + /* + * It is possible to have selector register inside data window. + * In that case, selector register is located on every page and it + * needs no page switching, when accessed alone. + * + * Nevertheless we should synchronize the cache values for it. + * This can't be properly achieved if the selector register is + * the first and the only one to be read inside the data window. + * That's why we update it in that case as well. + */ if (val_num > 1 || + in_range(range->selector_reg, range->window_start, range->window_len) || range->window_start + win_offset != range->selector_reg) { /* Use separate work_buf during page switching */ orig_work_buf = map->work_buf; -- 2.50.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] regmap: Synchronize cache for the page selector 2026-02-18 7:46 ` [PATCH v4 1/1] regmap: Synchronize cache for the page selector Andy Shevchenko @ 2026-02-18 8:30 ` Marek Szyprowski 2026-02-18 9:57 ` Andy Shevchenko 0 siblings, 1 reply; 6+ messages in thread From: Marek Szyprowski @ 2026-02-18 8:30 UTC (permalink / raw) To: Andy Shevchenko, linux-kernel Cc: Mark Brown, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Dmitry Baryshkov On 18.02.2026 08:46, Andy Shevchenko wrote: > If the selector register is represented in each page, its value > according to the debugfs is stale because it gets synchronized > only after the real page switch happens. Hence the regmap cache > initialisation from the HW inherits outdated data in the selector > register. > > Synchronize cache for the page selector just in time. > > Before (offset followed by hexdump, the first byte is selector): > > // Real registers > 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 > ... > // Virtual (per port) > 40: 05 ff 00 00 e0 e0 00 00 00 00 00 1f > 50: 00 ff 00 00 e0 e0 00 00 00 00 00 1f > 60: 01 ff 00 00 ff ff 00 00 00 00 00 00 > 70: 02 ff 00 00 cf f3 00 00 00 00 00 0c > 80: 03 ff 00 00 00 00 00 00 00 00 00 ff > 90: 04 ff 00 00 ff 0f 00 00 f0 00 00 00 > > After: > > // Real registers > 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 > ... > // Virtual (per port) > 40: 00 ff 00 00 e0 e0 00 00 00 00 00 1f > 50: 01 ff 00 00 e0 e0 00 00 00 00 00 1f > 60: 02 ff 00 00 ff ff 00 00 00 00 00 00 > 70: 03 ff 00 00 cf f3 00 00 00 00 00 0c > 80: 04 ff 00 00 00 00 00 00 00 00 00 ff > 90: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 > > Fixes: 6863ca622759 ("regmap: Add support for register indirect addressing.") > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > v4: reworked the approach completely > > Marek, Dmitry, > Please, test on your HW to be sure this will have no side effects > in your case with LT9611. It looks that it ends in infinite recurrent calls after this patch: Insufficient stack space to handle exception! ESR: 0x0000000096000047 -- DABT (current EL) FAR: 0xffff8000859bffe0 Task stack: [0xffff8000859c0000..0xffff8000859c4000] IRQ stack: [0xffff800080030000..0xffff800080034000] Overflow stack: [0xffff0001fef36140..0xffff0001fef37140] CPU: 6 UID: 0 PID: 341 Comm: (udev-worker) Not tainted 6.19.0-next-20260217+ #12215 PREEMPT Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _regmap_select_page+0x4/0x120 lr : _regmap_raw_read+0x240/0x340 ... Kernel panic - not syncing: kernel stack overflow CPU: 6 UID: 0 PID: 341 Comm: (udev-worker) Not tainted 6.19.0-next-20260217+ #12215 PREEMPT Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x38/0xd0 dump_stack+0x18/0x24 vpanic+0x4f8/0x4fc do_panic_on_target_cpu+0x0/0x1c add_taint+0x0/0xbc panic_bad_stack+0x104/0x124 __sdei_handler+0x0/0x2c4 __bad_stack+0x80/0x84 _regmap_select_page+0x4/0x120 (P) _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_read+0x240/0x340 _regmap_bus_read+0x44/0x7c _regmap_read+0x64/0x1f0 _regmap_update_bits+0xec/0x134 _regmap_select_page+0x9c/0x120 _regmap_raw_write_impl+0x414/0x7b8 _regmap_bus_raw_write+0x60/0x7c _regmap_write+0x60/0x1b8 regmap_write+0x4c/0x78 lt9611uxc_probe+0x208/0x684 [lontium_lt9611uxc] i2c_device_probe+0x154/0x344 really_probe+0xbc/0x298 __driver_probe_device+0x78/0x12c driver_probe_device+0x40/0x164 __driver_attach+0xe4/0x224 bus_for_each_dev+0x74/0xd0 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x60/0x128 i2c_register_driver+0x48/0xd0 lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x64/0x504 do_init_module+0x58/0x23c load_module+0x1b48/0x1e64 init_module_from_file+0xd4/0xec idempotent_init_module+0x188/0x280 __arm64_sys_finit_module+0x68/0xac invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x50/0x2e8 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c SMP: stopping secondary CPUs > drivers/base/regmap/regmap.c | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c > index 5d5a3e115022..1b90f00a5005 100644 > --- a/drivers/base/regmap/regmap.c > +++ b/drivers/base/regmap/regmap.c > @@ -1525,10 +1525,18 @@ static int _regmap_select_page(struct regmap *map, unsigned int *reg, > return -EINVAL; > } > > - /* It is possible to have selector register inside data window. > - In that case, selector register is located on every page and > - it needs no page switching, when accessed alone. */ > + /* > + * It is possible to have selector register inside data window. > + * In that case, selector register is located on every page and it > + * needs no page switching, when accessed alone. > + * > + * Nevertheless we should synchronize the cache values for it. > + * This can't be properly achieved if the selector register is > + * the first and the only one to be read inside the data window. > + * That's why we update it in that case as well. > + */ > if (val_num > 1 || > + in_range(range->selector_reg, range->window_start, range->window_len) || > range->window_start + win_offset != range->selector_reg) { > /* Use separate work_buf during page switching */ > orig_work_buf = map->work_buf; Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] regmap: Synchronize cache for the page selector 2026-02-18 8:30 ` Marek Szyprowski @ 2026-02-18 9:57 ` Andy Shevchenko 2026-02-18 10:56 ` Marek Szyprowski [not found] ` <c7913aea-3b20-48c6-b555-4c43d8e28422@samsung.com> 0 siblings, 2 replies; 6+ messages in thread From: Andy Shevchenko @ 2026-02-18 9:57 UTC (permalink / raw) To: Marek Szyprowski Cc: linux-kernel, Mark Brown, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Dmitry Baryshkov On Wed, Feb 18, 2026 at 09:30:41AM +0100, Marek Szyprowski wrote: > On 18.02.2026 08:46, Andy Shevchenko wrote: > > If the selector register is represented in each page, its value > > according to the debugfs is stale because it gets synchronized > > only after the real page switch happens. Hence the regmap cache > > initialisation from the HW inherits outdated data in the selector > > register. > > > > Synchronize cache for the page selector just in time. > > > > Before (offset followed by hexdump, the first byte is selector): > > > > // Real registers > > 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 > > ... > > // Virtual (per port) > > 40: 05 ff 00 00 e0 e0 00 00 00 00 00 1f > > 50: 00 ff 00 00 e0 e0 00 00 00 00 00 1f > > 60: 01 ff 00 00 ff ff 00 00 00 00 00 00 > > 70: 02 ff 00 00 cf f3 00 00 00 00 00 0c > > 80: 03 ff 00 00 00 00 00 00 00 00 00 ff > > 90: 04 ff 00 00 ff 0f 00 00 f0 00 00 00 > > > > After: > > > > // Real registers > > 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 > > ... > > // Virtual (per port) > > 40: 00 ff 00 00 e0 e0 00 00 00 00 00 1f > > 50: 01 ff 00 00 e0 e0 00 00 00 00 00 1f > > 60: 02 ff 00 00 ff ff 00 00 00 00 00 00 > > 70: 03 ff 00 00 cf f3 00 00 00 00 00 0c > > 80: 04 ff 00 00 00 00 00 00 00 00 00 ff > > 90: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 > > > > Fixes: 6863ca622759 ("regmap: Add support for register indirect addressing.") > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > --- > > v4: reworked the approach completely > > > > Marek, Dmitry, > > Please, test on your HW to be sure this will have no side effects > > in your case with LT9611. > > It looks that it ends in infinite recurrent calls after this patch: Thank you for the prompt testing! Can you also _add_ the patch on top from https://lore.kernel.org/all/Z4ppo8wV3nicOfAQ@smile.fi.intel.com/ ? > Insufficient stack space to handle exception! > ESR: 0x0000000096000047 -- DABT (current EL) > FAR: 0xffff8000859bffe0 > Task stack: [0xffff8000859c0000..0xffff8000859c4000] > IRQ stack: [0xffff800080030000..0xffff800080034000] > Overflow stack: [0xffff0001fef36140..0xffff0001fef37140] > CPU: 6 UID: 0 PID: 341 Comm: (udev-worker) Not tainted > 6.19.0-next-20260217+ #12215 PREEMPT > Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) > pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : _regmap_select_page+0x4/0x120 > lr : _regmap_raw_read+0x240/0x340 -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] regmap: Synchronize cache for the page selector 2026-02-18 9:57 ` Andy Shevchenko @ 2026-02-18 10:56 ` Marek Szyprowski 2026-02-18 11:30 ` Andy Shevchenko [not found] ` <c7913aea-3b20-48c6-b555-4c43d8e28422@samsung.com> 1 sibling, 1 reply; 6+ messages in thread From: Marek Szyprowski @ 2026-02-18 10:56 UTC (permalink / raw) To: Andy Shevchenko Cc: linux-kernel, Mark Brown, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Dmitry Baryshkov On 18.02.2026 10:57, Andy Shevchenko wrote: > On Wed, Feb 18, 2026 at 09:30:41AM +0100, Marek Szyprowski wrote: >> On 18.02.2026 08:46, Andy Shevchenko wrote: >>> If the selector register is represented in each page, its value >>> according to the debugfs is stale because it gets synchronized >>> only after the real page switch happens. Hence the regmap cache >>> initialisation from the HW inherits outdated data in the selector >>> register. >>> >>> Synchronize cache for the page selector just in time. >>> >>> Before (offset followed by hexdump, the first byte is selector): >>> >>> // Real registers >>> 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 >>> ... >>> // Virtual (per port) >>> 40: 05 ff 00 00 e0 e0 00 00 00 00 00 1f >>> 50: 00 ff 00 00 e0 e0 00 00 00 00 00 1f >>> 60: 01 ff 00 00 ff ff 00 00 00 00 00 00 >>> 70: 02 ff 00 00 cf f3 00 00 00 00 00 0c >>> 80: 03 ff 00 00 00 00 00 00 00 00 00 ff >>> 90: 04 ff 00 00 ff 0f 00 00 f0 00 00 00 >>> >>> After: >>> >>> // Real registers >>> 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 >>> ... >>> // Virtual (per port) >>> 40: 00 ff 00 00 e0 e0 00 00 00 00 00 1f >>> 50: 01 ff 00 00 e0 e0 00 00 00 00 00 1f >>> 60: 02 ff 00 00 ff ff 00 00 00 00 00 00 >>> 70: 03 ff 00 00 cf f3 00 00 00 00 00 0c >>> 80: 04 ff 00 00 00 00 00 00 00 00 00 ff >>> 90: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 >>> >>> Fixes: 6863ca622759 ("regmap: Add support for register indirect addressing.") >>> Signed-off-by: Andy Shevchenko<andriy.shevchenko@linux.intel.com> >>> --- >>> v4: reworked the approach completely >>> >>> Marek, Dmitry, >>> Please, test on your HW to be sure this will have no side effects >>> in your case with LT9611. >> It looks that it ends in infinite recurrent calls after this patch: > Thank you for the prompt testing! Can you also _add_ the patch on top from > https://lore.kernel.org/all/Z4ppo8wV3nicOfAQ@smile.fi.intel.com/ ? I've applied that change and the driver fails with the following messages: # dmesg | grep lt96 lt9611uxc 5-002b: LT9611 revision: 0x00.00.00 lt9611uxc 5-002b: LT9611 version: 0x00 lt9611uxc 5-002b: FW version 0, enforcing firmware update lt9611uxc 5-002b: Direct firmware load for lt9611uxc_fw.bin failed with error -2 lt9611uxc 5-002b: probe with driver lt9611uxc failed with error -2 Maybe this driver simply doesn't use this regmap feature properly and there is no point trying to fix regmap? >> Insufficient stack space to handle exception! >> ESR: 0x0000000096000047 -- DABT (current EL) >> FAR: 0xffff8000859bffe0 >> Task stack: [0xffff8000859c0000..0xffff8000859c4000] >> IRQ stack: [0xffff800080030000..0xffff800080034000] >> Overflow stack: [0xffff0001fef36140..0xffff0001fef37140] >> CPU: 6 UID: 0 PID: 341 Comm: (udev-worker) Not tainted >> 6.19.0-next-20260217+ #12215 PREEMPT >> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) >> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) >> pc : _regmap_select_page+0x4/0x120 >> lr : _regmap_raw_read+0x240/0x340 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/1] regmap: Synchronize cache for the page selector 2026-02-18 10:56 ` Marek Szyprowski @ 2026-02-18 11:30 ` Andy Shevchenko 0 siblings, 0 replies; 6+ messages in thread From: Andy Shevchenko @ 2026-02-18 11:30 UTC (permalink / raw) To: Marek Szyprowski Cc: linux-kernel, Mark Brown, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Dmitry Baryshkov On Wed, Feb 18, 2026 at 11:56:08AM +0100, Marek Szyprowski wrote: > On 18.02.2026 10:57, Andy Shevchenko wrote: ... > Maybe this driver simply doesn't use this regmap feature properly and > there is no point trying to fix regmap? Btw, may I send you privately some stuff for further experiments to avoid noise in ML? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <c7913aea-3b20-48c6-b555-4c43d8e28422@samsung.com>]
* Re: [PATCH v4 1/1] regmap: Synchronize cache for the page selector [not found] ` <c7913aea-3b20-48c6-b555-4c43d8e28422@samsung.com> @ 2026-02-18 10:59 ` Andy Shevchenko 0 siblings, 0 replies; 6+ messages in thread From: Andy Shevchenko @ 2026-02-18 10:59 UTC (permalink / raw) To: Marek Szyprowski Cc: linux-kernel, Mark Brown, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Dmitry Baryshkov On Wed, Feb 18, 2026 at 11:50:03AM +0100, Marek Szyprowski wrote: > On 18.02.2026 10:57, Andy Shevchenko wrote: > > On Wed, Feb 18, 2026 at 09:30:41AM +0100, Marek Szyprowski wrote: > >> On 18.02.2026 08:46, Andy Shevchenko wrote: ... > >>> --- > >>> v4: reworked the approach completely > >>> > >>> Marek, Dmitry, > >>> Please, test on your HW to be sure this will have no side effects > >>> in your case with LT9611. > >> It looks that it ends in infinite recurrent calls after this patch: > > Thank you for the prompt testing! Can you also _add_ the patch on top from > > https://lore.kernel.org/all/Z4ppo8wV3nicOfAQ@smile.fi.intel.com/ ? > > I've applied that change and the driver fails with the following messages: At least I see that nothing changed in the LT9611 driver. > # dmesg | grep lt96 > lt9611uxc 5-002b: LT9611 revision: 0x00.00.00 > lt9611uxc 5-002b: LT9611 version: 0x00 > lt9611uxc 5-002b: FW version 0, enforcing firmware update > lt9611uxc 5-002b: Direct firmware load for lt9611uxc_fw.bin failed with > error -2 > lt9611uxc 5-002b: probe with driver lt9611uxc failed with error -2 > > Maybe this driver simply doesn't use this regmap feature properly and > there is no point trying to fix regmap? regmap definitely missed that detail, needs to be fixed, but the driver for sure abuses the regmap ranges. Okay, thank you very much for testing (it's a pity I have no such HW to test the driver, I will think more about lt9611 driver and next time come up with something done there as well). > >> Insufficient stack space to handle exception! > >> ESR: 0x0000000096000047 -- DABT (current EL) > >> FAR: 0xffff8000859bffe0 > >> Task stack: [0xffff8000859c0000..0xffff8000859c4000] > >> IRQ stack: [0xffff800080030000..0xffff800080034000] > >> Overflow stack: [0xffff0001fef36140..0xffff0001fef37140] > >> CPU: 6 UID: 0 PID: 341 Comm: (udev-worker) Not tainted > >> 6.19.0-next-20260217+ #12215 PREEMPT > >> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) > >> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > >> pc : _regmap_select_page+0x4/0x120 > >> lr : _regmap_raw_read+0x240/0x340 -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-02-18 11:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CGME20260218074952eucas1p2fb09d58aec2392e8f21f4b66a6163230@eucas1p2.samsung.com>
2026-02-18 7:46 ` [PATCH v4 1/1] regmap: Synchronize cache for the page selector Andy Shevchenko
2026-02-18 8:30 ` Marek Szyprowski
2026-02-18 9:57 ` Andy Shevchenko
2026-02-18 10:56 ` Marek Szyprowski
2026-02-18 11:30 ` Andy Shevchenko
[not found] ` <c7913aea-3b20-48c6-b555-4c43d8e28422@samsung.com>
2026-02-18 10:59 ` Andy Shevchenko
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.