06:42 <mvaittin> broonie: You acked 11/14 and 13/14. I wonder if you noticed the 7/14 and 9/14 were also regulator changes? https://lore.kernel.org/all/2d18b7bc-7d94-4e45-8c7d-9a8acf4089eb@gmail.com/

11:46 <broonie> mvaittin: I'm probably just binning the series since I've acked bits of it, these endless resends of MFD serieses are just noise.

11:51 <mvaittin> broonie: Ok. I was afraid some of the patches didn't catch your attention.

11:51 <mvaittin> The last statement from Lee is that the MFD parts should be Ok but I need to re-spin (at least once) though, because I have bug in one of the regulator voltages.

11:55 <mvaittin> There is this 'soft dependency' between 6/14 and 7/14 because I renamed the IRQ resources :/

11:57 <mvaittin> Hence it may make sense to have everything applied in immutable branch(?)

11:57 <mvaittin> but there's no rush, we're at rc1. As I said, I was just wondering if you missed some of the changes.

12:44 <broonie> That's more of a general complaint about how painful all the MFD serieses are than something with this particular one.

12:48 <javierm> mvaittin, broonie: another option if the series can wait a little bit is to split by kernel releases

12:48 <javierm> since the regulator driver will depend on the mfd one anyways, it should be safe to apply the former

12:49 <broonie> The problem is the huge number of resends of large serieses.

12:49 <broonie> Linus moaned about things getting applied before the MFD at some point, I used to just apply things which helped a lot.

12:49 <broonie> arnd: I'm seeing a lot of ICEs on allmodconfig with GCC 13 and 14 in -rc1, looks to be struct randomisation.

12:51 <javierm> broonie: I see

12:51 <arnd> broonie: do you see them across architectures or just one? I don't build with gcc plugins enabled because my own toolchains don't do that, so I probably had this problem

12:52 <mvaittin> javierm: Problem in this case is, that the series adds new ICs to existing drivers. Hence, the changes like renaming resources can break existing drivers if regulator and MFD changes don't end up in same release. Also the Kconfig options are there already.

12:52 <broonie> arnd: I'm only doing x86_64 allmodconfigs so not checked other architectures.

12:54 <javierm> mvaittin: got it

12:54 <arnd> broonie: Do you see it without CONFIG_X86_NATIVE_CPU? ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'") was merged into linux-next and may have started to exercise some new code paths in the compiler

12:54 <arnd> not sure if that is turned on with allmodconfig

12:56 <broonie> arnd: I’m literally just doing allmodconfig builds here. It’s also happening with Linus’ tree, it’s not just -next. It’s possible a toolchain update started triggering things and I was just lucky up till now.

13:02 <broonie> arnd: Not seeing that option in the generated configs

13:04 <arnd> broonie: I assume these are native x86 compilers are from Debian Testing? I'm still on bookworm, which only has gcc-12, so I'm trying this on 6.15-rc1 allmodconfig now with plugins enabled. So far it seems fine.

13:04 <broonie> arnd: It's containers derived from the tuxmake ones.

13:05 <broonie> They may or may not be native, I'm building on a mix of arm64 and x86_64 hosts.

13:05 <arnd> got this with x86-64-linux-gnu-gcc-12 from Bookworm now while cross-compiling x86-64 allmodconfig on arm64 ../security/landlock/fs.c:1745:61: internal compiler error: in count_type_elements, at expr.cc:6407

13:06 <broonie> Yeah, that's one of them.

13:06 <broonie> I think I've seen other similar glitches (and some builds have passed).

13:08 <arnd> 6.14 is fine, starting a 'git bisect run'

13:08 <broonie> Thanks.

13:09 <arnd> c56f649646ecec3dd1a2e400e6e5ec83439d940f is the first bad commit

13:10 <broonie> That was fast!

13:10 <arnd> it was only 6500 commits

13:21 <arnd> broonie: either of these two changes fixes it:

13:22 <arnd> https://www.irccloud.com/pastebin/Cnc4g2mX/

13:32 <geertu> arnd: Is it randomizing the layout differently each time the file is included?

14:45 <broonie> arnd: Will you submit one/both of those?

14:57 <arnd> broonie: the second one is clearly wrong, the first one makes randstruct slightly less useful (one of 72 such annotations removed), so I'm not sure it's actually a good idea.

14:57 <arnd> The ICE is likely caused by a bug in the plugin itself, so the real fix should be there, but I have no idea how to even try to debug that

15:01 <broonie> Yeah, they’re not ideal but OTOH allmodconfig blowing up is an emergency.

15:03 <arnd> we could do 'config GCC_PLUGINS depends on !COMPILE_TEST', which is both an emergency workaround, and helps with build speed

15:03 <broonie> It’d be a lot easier if pinhead hadn’t insisted on -Werror.

15:04 <broonie> Yeah, that’d work.

15:04 <broonie> I can send a patch?

15:05 <arnd> I wonder how close we are getting to killing off gcc plugins entirely. GCC_PLUGIN_SANCOV is obsolete with gcc-6 (and can go away if my gcc-8 minimum version change makes it in). CC_HAVE_STACKPROTECTOR_TLS seems to be obsolete with gcc-12 or higher, ardb could decide that's close enough

15:06 <arnd> broonie: yes, please do

15:21 <arnd> GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is also gcc-12+. The remaining ones are randstruct, stackleak and latent_entropy

15:27 <arnd> Any idea who actually uses gcc plugins in production? According to https://github.com/nyrahul/linux-kernel-configs, only one of 48 distros enables any at all: Talos 1.9.1 uses latent_entropy and stackleak. No idea how accurate that collection is though

15:48 <ardb> arnd: no objections to removing that plugin

17:05 <rfs613> ardb: FWIW the only one i've ever encountered in production is stack-protector

18:44 <TuningYourCode> Hi all, i'm currently playing around with an "ancient" nas which has an realtek rtd 1195 soc. Luckily the mainline kernel has some basic support for that SoC already. Durring various kernels being compiled and tested i got quiet often "undefined instruction" in u-boot while booting the kernel. I found out that adding padding with 'dd' and/or 'mkimage -p' to the kernel usually fixed the issue to get it booting. Here my

18:44 <TuningYourCode> script: https://pastebin.com/DLL1s0q9 Sadly it's not a 100% fix sometimes i still get kernels which don't want to boot (with different modules compiled in) - does any body know issues like that (probably with other SoCs) or has some things i can try to increase my success rate of booting kernels? (sorry if the question is not 100% on channel topic)

19:08 <arnd> TuningYourCode: this is the right channel, but I don't expect anyone to have the answer to this. Maybe send an email to the linux-realtek-soc@lists.infradead.org mailing list, with Andreas on Cc.

19:36 <TuningYourCode> arnd: ok, thanks :) i already kind of think that might be something soc related as my googlefu didn't find anything that i'm missing something important.