09:08 <wens> it seems -next now complains that genpd->dev.release is NULL

12:11 <biju> net/netfilter/ipvs/ip_vs_conn.c:1498:8: note: in expansion of macro ‘clamp’

12:11 <biju> 1498 | max = clamp(max, min, max_avail);

12:11 <biju> same issue hit in today's next

12:11 <biju> ././include/linux/compiler_types.h:542:38: error: call to ‘__compiletime_assert_1052’ declared with attribute error: clamp() low limit min greater than high limit max_avail

12:11 <biju> 542 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

12:14 <biju> with arm gcc10 compiler

12:38 <arnd> biju: I think the extra checking just got added to clamp(), but I'm not sure if this is a real bug or a false positive. What is BITS_PER_LONG and PAGE_SIZE in your build?

12:46 <biju> CONFIG_64BIT=y

12:46 <biju> #define BITS_PER_LONG 64

12:47 <biju> from include/asm-generic/bitsperlong.h

13:04 <biju> with gcc12 arm compiler it builds ok.

13:04 <biju> Build issue happens with gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu

13:11 <geertu> biju: wrong argument order?

13:11 <geertu> - max = clamp(max, min, max_avail);

13:11 <geertu> + max = clamp(max_avil, min, max);

13:12 <geertu> arnd saw it last July ;-) 8111159a-c571-4c71-b731-184af56b5cb1@app.fastmail.com

13:14 <arnd> geertu: ah, it did feel familiar, I just couldn't find a patch I did before. I'm still confused over whether the arguments are actually in the wrong order or just named in an unfortunate way

13:15 <arnd> my reading earlier was that it actually tries to clamp the local variable named 'max' rather than trying to clamp the other one to that maximum

13:15 <geertu> arnd: there's a "clamp_val(ip_vs_conn_tab_bits, min, max)" on the enxt line

13:16 <geertu> so I guess min..max is the actual range

13:18 <arnd> I think it's trying to clamp ip_vs_conn_tab_bits to min(8, max_avail)...max(max_avail, 27)

13:20 <arnd> order_base_2(totalram_pages()) is a complex macro expansion, and it's possible that gcc splits that into two branches, with either constant-zero or variable values. In the constant-zero branch, 12-2-1-order_base_2(sizeof(struct ip_vs_conn)) is less than 8

13:21 <geertu> Actually clamp(max, min, max_avail) and clamp(max_avail, min, max) do the same thing

13:21 <robmur01> regardless of the intent, limiting a constant to a variable upper bound is a bit wacky, and indeed should still yield the same result the more sensible way round

13:22 <arnd> good point, so that would likely address the build failure and help readability

13:28 <robmur01> (that's "variable" in the context of the code logic, rather than compilation of course :))

13:43 <robmur01> oh, I missed totalram_pages(), that is actually variable

18:30 <macromorgan> might need some guidance... I found a regression in the 6.13 kernel that's likely a case of undefined behavior worked, now it doesn't. Long story short I need an efficient way of finding a child ADC device for an MFD when I have the parent device. Are there any helper macros I should be looking at?

18:31 <macromorgan> commit e37ec3218870 ("mfd: axp20x: Allow multiple regulators") breaks using CONFIG_AXP20X_ADC

18:32 <macromorgan> I suspect because maybe in the past the devid was always NONE it could find the child ADC channel if given the parent?

18:33 <macromorgan> is there an efficient way of saying "give me all drivers with this name" or "give me all drivers in the iio subsystem"? I know there is a subsystem one in U-Boot at least.

18:46 <robmur01> macromorgan: device_find_child()?

18:47 <macromorgan> right... device_find_child_by_name() might do the trick, let me try that thanks