11:52 <tmlind> arnd: maybe pick these two patches into your omap1-multiplatform branch? [PATCH] omap1: htc_herald: fix typos in comments, [PATCH] ARM: OMAP1: fix typos in comments

12:36 <arnd> tmlind: ok, just applied them, and also the MAINTAINERS patch

12:38 <arnd> tmlind: unless there is something else you are waiting for, I'd merge it into my arm/multiplatform branch for 5.19 then, on top of the ep93xx/iop32x/ixp4xx/dove changes

12:39 <arnd> I wonder how long I should wait for feedback on the pxa patches, my feeling is that Robert Jarzmik is the last one who cares about the platform, and he doesn't do that much on it either

12:41 <tmlind> arnd: hmm i just pushed out a maintainers branch with two patches in it

12:41 <arnd> tmlind: that's fine as well, I'll just drop it from my tree and merge your branch into the 5.18 fixes then

12:42 <tmlind> arnd: ok, looks like i could easily drop it too if needed, it's the top patch

12:43 <tmlind> arnd: as far as i'm concerned, the debug_ll issues was the last one i was worried about

12:43 <arnd> krzk: regarding your mach-s3c deprecation patch, do you want that in 5.18 or 5.19? I think there is a trivial conflict against my multiplatform patch, so adding it into arm/multiplatform would be slightly easier for me

12:44 <arnd> tmlind: ok, perfect

12:45 <krzk> arnd: having it faster (in current release) would be a bit better, more time to warn users, but it is not strictly a fix and it causes a pragma message which might annoy someone, so considering the conflict - maybe take it for next?

12:48 <arnd> krzk: ok, thanks, I'll put it into the arm/multiplatform branch then. Good point about the #pragma, there is definitely a risk that this breaks some build bots in a way that I would not want in a bugfix commit without some testing in linux-next first

12:49 <krzk> exactly, already kbuild robot found it as a new warning

12:50 <arnd> hmm, maybe I should not add a S-o-b then to avoid getting cc'd on the future "this is still broken" emails ;-)

12:50 <krzk> This is why I sent it as a patch, not as pull :)

12:52 <arnd> I have previously suggested to the 0day folks to only build with CONFIG_COMPILE_TEST enabled, but I suppose that was only for randconfig builds, not the defconfigs

12:52 <arnd> or maybe they just don't send /me/ the reports with COMPILE_TEST=n any more

14:13 <marex> maz: all right, stm32 power consumption when the pinctrl block clock are kept on changed by ... 0 ...

14:14 <marex> maz: I sent out the patch to keep it active if LEVEL IRQ is requested, now let's see if those patches will go in

14:27 <maz> marex: I'll have a look. hopefully the ST folks will chime in.

14:41 <marex> maz: thanks !

15:11 <maz> marex: well, Linus picked it up at the speed of light! :D

15:24 <marex> maz: I think Linus picked up the first patch, the optimization one, not the one I sent today

15:24 <marex> maz: Linus is a nice maintainer btw

15:32 <maz> marex: ah, indeed.

15:40 <arnd> krzk: I was curious to see if patchwork would behave differently with your new email address and automatically mark your pull requests as merged when I pick them up, as it does for most other submitters. It appears that it does not, though it does work for separate patch emails you send.

15:42 <arnd> it did not notice the s3c-deprecation patch, but I think that is because it was not a clean merge

19:37 <gpiccoli> Hi folks, have a questions about interrupts on kdump, arm32 - I'm working in a panic refactor, and noticed that there is 2 routines to disable CPUs in panic path. A regular routine [smp_send_stop()], which leads to ipi_cpu_stop(). This latter function disables local irq and fiq (whatever that is) in the CPU being shut off...which makes sense.

19:38 <gpiccoli> But the kdump version leads to machine_crash_nonpanic_core() [through crash_smp_send_stop()], and one of the major differences I see is that this latter function *does not* disables irqs/fiq before spinning in cpu_relax()

19:38 <gpiccoli> So...what would be a possible reason for that? In my head, it makes sense to disable irqs/fiq (fast interrupts?) in the crash cpus disabling as well...

19:40 <gpiccoli> I might plumb a patch for this, but since I'm no expert in arm CPUs (far from it!), I'd like to check with the interrupt experts

19:40 <gpiccoli> Tnx in advance!