09:48 <wens> make[6]: *** No rule to make target 'debian/linux-image-6.9.0-rc1-next-20240325-01275-g7b737b577d9a/usr/lib/linux-image-6.9.0-rc1-next-20240325-01275-g7b737b577d9a/freescale/imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtb', needed by '__dtbs_install'. Stop.

09:51 <wens> nevermind, it was something in my tree

11:44 <marc|gonzalez> Something in the way, mmm

11:44 <marc|gonzalez> Something in the way, yeah, mmm

14:56 <linusw__> ardb: here is my stab at CFI-safe cache flushes: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/commit/?h=b4/arm32-cfi&id=4c65b5257d3f8b2264b4b1c22d12f43127da740d

14:57 <linusw__> It's just "a little" invasive ...

15:00 <linusw__> Luckily I have a trove of hardware so I can actually test most of it, except the arm-102x stuff

15:03 <ardb> that looks rather straight-forward

15:03 <ardb> i suppose you could split this easily into several patches

15:03 <ardb> i.e., change the entry pieces first and the rest later

15:51 <marc|gonzalez> If I boot my kernel with maxcpus=1, it reboots in a loop, as if some kind of watchdog was biting (without any log anywhere). If I change to maxcpus=8, reboot loop disappears.

15:52 <marc|gonzalez> I also have CONFIG_PREEMPT_NONE=y for a weird test (might be relevant)

15:52 <marc|gonzalez> robmur01: would this be considered a bug, or an unsupported configuration, or both? :)

15:58 <mrutland> marc|gonzalez: which kernel version, which SoC / CPUs, do you have any watchdogs on your platform, etc?

15:59 <marc|gonzalez> mrutland: lack of details right. I'm toggling between 6.7 & 6.8, on a qcom msm8998 platform, and I don't know about the watchdogs, I have to check.

16:00 <marc|gonzalez> but I'm asking a more general question: if I booting a system works with maxcpus=8 and fails with maxcpus=1, would that be considered a bug or an unsupported configuration?

16:00 <mrutland> That'd be a bug

16:01 <marc|gonzalez> Okey, then I'll try to boot on 6.9-rc1 using the default defconfig to highlight the issue

16:27 <dmart> mrutland, maz: Can you remember anything about the inline SMCCC macros?

16:40 <mrutland> dmart: not much; I'd wanted to rework those and/or delete the bulk of them, they really only need to be inline in entry asm and hyp code IIUC

16:40 <mrutland> dmart: if you have a more specific question I can try to answer ?

16:42 <dmart> mrutland: Someone reported on the list that SMCCC clobbered regs are not taken into account, but it looks like they're referring to an old spec.

16:42 <mrutland> dmart: which thread?

16:43 <mrutland> IIRC the inline helpers are only for the newer versions that are guaranteed to save the regs, which I think aligns with what you're saying?

16:43 <dmart> mrutland: https://lore.kernel.org/linux-arm-kernel/DS7PR19MB4407C29AC8FF38BA192DCDFFE6362@DS7PR19MB4407.namprd19.prod.outlook.com/

16:44 <mrutland> dmart: cheers, lemme go check that and reply

16:46 <dmart> mrutland: ^ Yes, except that I don't understand what the logic is for choosing between inline and out-of-line versions for <SMCCCv1.1

16:48 <dmart> mrutland: Basically I'm wondering whether we check for SMCCCv1.1 or above before using the inline helpers (if so, I haven't figured out how it works yet)

16:48 <mrutland> The code using the inline things should only be for calls that are guaranteed to be SMCCCv1.1+

16:48 <mrutland> The core SMCCC code doesn't enforce that

16:48 <dmart> mrutland: Right, I wondered it was something like that. I guess we're probably OK then.

16:50 <dmart> mrutland: I have a strong suspicion that the inline asm explicit regs thing is not 100% safe however it's done, but I guess it hasn't blown up in our faces yet...

17:00 <mrutland> I don't like it (I think it's a premature optimization that's hard to maintain), but I'm not awre of it being unsafe

17:04 <dmart> mrutland: Well yes, I guess we ought to wait for actual evidence of that going wrong. Most, the GCC docs don't explain enough about the semantics of local register asm vars to show that this is safe; there's just a sketcy example without any precise guarantees.

17:05 <dmart> s/Most/whatever word I meant/