08:02 <arnd> geertu: I build-tested yesterday's linux-next for all architectures and came across a regression for m68k: "drivers/nubus/proc.c:112:20: error: called object 'pde_data' is not a function or function pointer", apparently from c28198889c15 ("proc: remove PDE_DATA() completely")

08:10 <geertu> arnd: https://lore.kernel.org/all/20211125083808.82560-1-geert@linux-m68k.org/

08:11 <arnd> geertu: ok, I thought you probably knew about it, was just making sure ;-)

08:12 <geertu> arnd: noreply@ellerman.id.au told me, so I fixed it.

11:10 <ajb-linaro> so I want to track how often QEMU has to flush it's TLBs to deal with different ASIDs - which instructions could I track for that? We seem to do it on context_idr changes but you don't usually see those

11:15 <ajb-linaro> will it just be whenever ttbr[01]_el1 is tweaked?

12:20 <maz> ardb: what is the base commit for your IRQ stacks series? I've just revived the netwinder...

12:22 <maz> and the series doesn't seem to apply on -rc3

12:31 <maz> ardb: arm-up-ti-in-task-v3 seems to have what I need...

13:19 <ardb> maz: thanks!

13:20 <ardb> yes that is the exact branch i posted

13:26 <ardb> maz: did your config have CONFIG_VMAP_STACK=y ?

13:27 <ardb> (it should be enabled by default now if supported)

13:40 <maz> ardb: yup, it was enabled.

13:56 <ardb> excellent

14:05 <rfs613> maz: netwinder eh? how's the beast running?

14:06 <maz> rfs613: slowly, as you'd expect!

14:06 <rfs613> well yes :-)

14:07 <broonie> "running"

14:07 <rfs613> last time I booted mine was probably 5 years ago...

14:08 <maz> that's about the time it was last booted. still running stretch, and unable to update. it will probably take a couple of days to update to bullseye...

14:08 <maz> but hey, I revived the BX emulation patches, so it wasn't a complete waste of time.

14:09 <rfs613> still not officially supported, presumaly, so you have to rebuild all binaries?

14:09 <maz> only the kernel.

14:11 <maz> unless Debian has dropped v4t support altogether, in which case this is the end of the road.

14:12 <maz> ah, they have.

14:13 <rfs613> "From Debian 10 (buster), 4T is no longer supported and the armel baseline was updated to 5T"

14:14 <maz> yeah, too bad. I'll survive.

14:17 <broonie> I fired up my cubietruck the other day, IIRC it was running Jessie. Sadly it didn't reboot at some point ni the upgrade cycle (I think it was the bullseye upgrade) so I need to get round to figuring out a serial console again :(

14:18 <maz> I could implement support for BLX. On the other hand, LDR, LDM and POP are not emulatable.

14:20 <ardb> 4t has no LDR ???

14:20 <maz> it has. which is the problem. LDR PC will not undef, so I can't fix the thunb interworking in the kernel.

14:21 <maz> thumb*

14:21 <ardb> ah right

14:23 <ardb> so it's v4 or v4t ?

14:24 <ardb> are you saying ldr pc is an interworking branch in v5t but not in v4t?

14:24 <ardb> that would be insane, so it must be true

14:33 <rfs613> iirc, the problem with 'ldr pc' in thumb mode is that it won't set the bottom bit, and so upon return you'll switch back to arm mode.

14:34 <rfs613> but it's been a loooon time so i might have forgotten the details...

14:52 <maz> ardb: StrongARM is pure v4. But the only missing instruction to be able to use v4t userspace code is BX. I have patches to emulate this in the kernel.

14:53 <maz> ardb: and indeed, v5t is the first version of the architecture that alows a load to PC to perform ARM/Thumb interworking.

14:55 <maz> ardb: anyway, I hope one day we can cull the 32bit port all the way to v6K.

14:55 <ardb> maz: can't you just rebuild libdl so it handles the R_ARM_V4BX thing correctly?

14:56 <ardb> maz: +1

14:56 <ardb> the v6-nonK+v7 SMP multiplatform kernels are a real pain

14:58 <maz> ardb: I could probably do that, but that'd be equivalent to my BX kernel patches.

15:02 <rfs613> maz: are you trapping BX and then emulating it?

15:04 <maz> rfs613: yup. I can also write back to userspace.

15:04 <maz> not exactly elegant, which is why I never tried to upstream this.

15:04 <maz> some distros have shipped with these patches though!

15:06 <rfs613> maz: interesting...

15:06 <ardb> maz: riscpc already requires an older gcc to build (gcc 6/7/8) as armv3 is no longer supported

15:06 <ardb> (and AIUI, GCC 5 broke armv3 by accident but nobody ever noticed)

15:07 <ardb> so we are definitely getting to a point where it is simply not feasible anymore to keep supporting this

15:07 <maz> I don't think we should even try.

15:07 <ardb> agreed

15:08 <maz> hardly anyone uses these machines, and those whodo won't update.

15:09 <ardb> once the minimum GCC version advances past 8, we'll have to drop riscpc in any case, which will make it a bit easier to start dropping other ones as well, i reckon

19:39 <robher> krzk: For samsung,s5m8767, is op_mode in BUCK* valid? It's only defined for LDOs, but used in BUCK nodes too.