06:55 <geertu> sboyd: thx!

07:05 <arnd> pulled everything I got for v6.1 now, the only thing that's missing is marcan's DT update

11:46 <mwalle> maz: if you have some spare minutes, could you have a look at https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/tree/drivers/pinctrl/pinctrl-ocelot.c#n1839 if there is something fishy going on?

11:47 <mwalle> maz: the controller just supports edge triggered interrupts (both edges only, just a simple pin change interrupt), but the driver wants to support level interrupts

12:07 <maz> mwalle: well, it will probably break badly in some edge cases.

12:24 <mvaittin> mwalle: maz I find this interesting. I believe the classic race for treating device which is designed to operate with level IRQs is a new IRQ firing between reading status and acking. This will traditionally cause the device to keep line asserted - and controller never sees another edge. By reading the code here it seems to me that controller overcomes this by checking the line-status after ack to ensure device has really released the line. I

12:24 <mvaittin> am interested in hearing if this actually works - or what are the corner-cases if it does not :) (I am not in any ways related to this code - just curious about the concept)

12:56 <mwalle> maz: mvaittin: what i'm seeing is that the irq count increases (much) more than there are actual irqs. E.g. I'm using this for a simple phy interrupt, and the count increases by about 20 for each interrupt

12:57 <mwalle> (irq count in /proc/interrupts)

12:57 <mvaittin> mwalle: Thanks :) Then it seems definitely not good :)

12:58 <mwalle> i tried to debug it, but honestly, i'm not very familiar with the whole low level irq handling in linux. i'm seeing repeated calls to ocelot_irq_mask() and ocelot_irq_unmask()

12:59 <mwalle> mvaittin: well, it doesn't happen with all the phys, some seem to work properly.. maybe its just the phy which doesn't play nice by not deasserting the interrupt line after reading its interrupt status register. but then i should see the actual call to the phy interrupt routine, which i don't. mh

13:03 <mwalle> maz: i'll debug it further. I thought that maybe you'd instantly say, this cannot work at all ;)

13:19 <prabhakarlad> Hi all, anyone given a shot to build the latest next (next-20220928) to build for arm64 (I am seeing build failures for defconfig)?

13:22 <ardb> maz: is it permitted to combine GICv3 with v2m MSI frames?

13:29 <mwalle> prabhakarlad: related to memblk_nr_poison_inc etc?

13:31 <mwalle> prabhakarlad: i've build todays next successfully for aarch64, although not the defconfig

13:41 <maz> ardb: not architectturally. there is an amazons-special hack for their not-quite v2m that is allowed by the driver, but that's about it.

13:42 <maz> mwalle: it can probably be made to work, but I really don't have time to look at this and debug it (specially not without the HW).

13:43 <maz> ardb: I recently saw some macOS emulator using HVF exposing this combo, and shouted at the authors... ;-)

13:44 <ardb> maz: yeah it seems it is popping up in other places as well

13:44 <ardb> and supposedly windows supports it :-(

13:45 <maz> that's pretty daft, as GICv3-MBI is designed for that.

13:45 <maz> well, windows does all sort of stupid things, including accessing PMUs that don't exist.

13:45 <ardb> that uses setspi/clrspi right?

13:45 <ardb> (or sth like that)

13:46 <ardb> or is that something else (i mean the thing qualcomm were using)

13:46 <maz> ardb: yup. GICv2m only has the SETSPI version (edge only), while GICv3-MBI has both set and clr.

13:46 <maz> allowing level as well.

13:50 <maz> ardb: to be honest, if they are using this for MSIs only, the programming interface is almost the same.

13:51 <ardb> maz: to the extent that one might cheat and describe MBI as a v2m ?

13:54 <maz> ardb: yeah, that could actually work.

13:54 <maz> you wouldn't get level MSI, but that's probably a good thing.

13:55 <ardb> you wouldn't need that for pci anyway

13:55 <maz> thankfully!

14:41 <prabhakarlad> mwalle: https://paste.debian.net/1255414/ (I couldn't paste the complete log)

15:07 <robmur01> ardb: annoyingly SBSA does call out the v3/v2m combination, but the intent is purely for GICv3-unaware hypervisors using it in compatibility mode

15:11 <robmur01> (so essentially it's valid in hardware, but still nonsensical to expose to software as such)

15:26 <nathanchance> prabhakarlad: I think https://lore.kernel.org/20220929081642.1932200-1-keescook@chromium.org/ should be the fix for that issue

15:28 <prabhakarlad> nathanchance: thanks, Ill give that a try.