06:23 <arnd> krzk: I'll take care of it today if olofj hasn't already

06:24 <arnd> tlwoerner, broonie: I think it's even closer than v6/v7, since both architectures are still continuing

06:25 <arnd> the initial v9.0 is defined as v8.5 plus SVE2, and then v9.1 is v8.6 plus SVE2 etc

06:26 <arnd> later v9.x releases gain additional features that are not part of v8.x

07:28 <geertu> arnd: Can you please take the renesas-fixes PR, too? thx!

07:28 <geertu> broonie: Looks like several ASoC commits ended up on the spi/for-next branch

08:52 <mort> if I have a stack trace like the one in https://p.mort.coffee/2MZ, can I translate the function names + address into a source location somehow?

08:57 <punit> mort: The internet is your friend - https://serverfault.com/questions/605946/kernel-stack-trace-to-source-code-lines/606024

08:57 <punit> Assuming you had not figured this out already ;-)

09:03 <punit> Ah I spoke too soon - for what you're looking ./scripts/faddr2line (in the kernel source tree) is better

09:11 <mort> faddr2line looks ideal. I have to figure out where yocto puts a non-stripped kernel then

13:20 <broonie_> geertu: ack

14:21 <ukleinek> broonie: the spi-imx IP has some strange properties when the hardware-CS is used. One of the (few) advantages is that it could natively support SPI_CS_WORD. I assume I could do mode_bits |= SPI_CS_WORD if all CS are native and when some CS uses a GPIO don't advertise it. Is there a better option?

14:59 <broonie> ukleinek: Hrm, not really ATM. It's not like there's a software fallback you can turn on.

15:06 <arnd> tlwoerner: another follow-up: After I saw the SME spec being public today, I looked up the ARMv9 definition at https://developer.arm.com/documentation/ddi0608/latest, and it turns out that all ARMv9 features are optional, including SVE2

15:06 <arnd> The only hard requirements for something to be called ARMv9.0 instead of ARMv8.5 are:

15:07 <arnd> - there cannot be aarch32 mode in EL1 or higher

15:07 <arnd> - if an embedded trace thingy exists, it has to be the new ETE instead of the old but almost identical ETM

15:15 <tlwoerner> arnd: interesting. i was expecting a longer list ;-)

15:15 <tlwoerner> https://developer.arm.com/documentation/102378/0200/Armv8-x-and-Armv9-x-extensions-and-features

15:16 <arnd> that is the list of all the features that are common between the two, and again most of these are completely optional (I have not checked if anything is mandatory at all)

15:18 <arnd> If I interpret it right, it seems that the main thing is that you have to be compliant with the corresponding armv8.x spec to be allowed any of the armv9.x features

15:19 <arnd> while within armv8.x it appears that you can always mix and match these, by picking e.g. an armv8.5 feature into an armv8.2 core that is not armv8.3 compliant

15:24 <arnd> though I have no idea how that would be enforced in the end. E.g. if some architecture licensee wanted to have an armv8.5 core with aarch32-el1 and sve2, would arm stop them from shipping it, or would they just not be able to call it armv9?

15:24 <tlwoerner> Q: Secure virtualization was added in Armv8.4-A. Would an Armv8.1-A processor be allowed to implement it?

15:25 <tlwoerner> A: No. An Armv8.1 processor must implement the mandatory features of Armv8.1 and may implement features from Armv8.2-A. But it is not allowed to implement features from Armv8.3, Armv8.4, or later versions, unless a special concession has been made.

15:25 <tlwoerner> from https://developer.arm.com/documentation/102378/0200/Check-your-knowledge

15:27 <arnd> ah, that explains a lot. So a lot of CPU cores are based on "special concession" then, rather than following the architecture ;-)

15:32 <tlwoerner> also: "There is no field that reports whether a processor is Armv8.1-A. Instead, software reads the feature fields for the mandatory 8.1-A features, and if they all present, the processor is compliant with Armv8.1-A."

15:32 <tlwoerner> from: https://developer.arm.com/documentation/102378/0200/Which-extension-does-my-processor-implement-

15:33 <arnd> And I guess in case of Apple Silicon, the current generation declares itself as ARMv8.5, and it would actually be compliant with ARMv9.0 as well (since it has neither aarch32 nor etm, and none of the optional features of armv9), but it's also not actually compliant with v8 .5 or v9.0 because it lacks a couple of mandatory features like nVHE virtualization

15:35 <arnd> tlwoerner: it would be nice to have a table of feature bits listed as mandatory/optional/invalid per architecture level, but I don't think that exists. Have you seen that anywhere?

15:35 <tlwoerner> arnd: not yet

15:36 <arnd> or even better, a list of which features are actually present on each of the implementations we know of

16:50 <broonie> Given all the optional features I'm not sure how useful the ARMv8.x gradations are in practice. A matrix/database of features in chips would definitely be useful though.

17:45 <marex> robher: I am looking at this DT patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/xilinx/zynqmp.dtsi?h=linux-5.10.y&id=dfff9066e60ee8670424cfedf4269d3b51c5100f and the zynqmp.dtsi https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/xilinx/zynqmp.dtsi?h=linux-5.10.y#n20 here , so / has address and size cells = 2, and two

17:45 <marex> subnodes, /axi@0 and /axi , is that actually valid ?

17:46 <marex> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/xilinx/zynqmp.dtsi?h=linux-5.10.y#n185 this part here axi@0 and axi

17:49 <robher> marex: Valid? Yes. Logical? No

17:50 <marex> robher: do those two things represent the same bus then or not ?

17:51 <robher> marex: It seems unlikely that the gic is sitting in the middle of the address range of the

17:51 <robher> ... 'axi' bus.

17:52 <marex> robher: the reason I'm looking into it is because u-boot apparently treats a DT with /axi@0 and /axi as if they were the same node , which is a bug, I just don't know where yet, whether in u-boot, libfdt, or the DT

17:52 <marex> robher: so, I wanted to know whether the DT is valid, now I think I have my answer to that part

17:53 <robher> Though I vaguely remember that some GIC implementations with cores, have tie off signals for the address and that would be decoded before anything else.

17:53 <marex> robher: the zynqmp should be fairy standard arm64 machine, I dont expect anything weird like that, but I can ask Michal about it on Monday, that's fine

17:54 <robher> marex: I think axi@0 should be axi@f9010000 or axi@f9000000 to limit the overlap.

17:56 <marex> robher: ah, I think I know what the gic node might be all about, the zynqmp has 32bit cortexR in it too, so maybe that is why it is separate

17:57 <marex> robher: https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html more like 0xa0000000 , see VCU at the end

17:58 <marex> but renaming the axi to axi@something doesn't solve the problem I am after, it just hides one of the symptoms

18:58 <geertu> marex: Does the CR8 has its own GIC on zynq?

18:58 <marex> geertu: it is cr5

18:59 <marex> geertu: it probably has nvic though, hum