08:58 <ukleinek> broonie: just noticed by chance the link in commit 4ccf359849ce709f4bf0214b4b5b8b6891d38770 yields a 404

09:06 <geertu> ukleinek: works for me?

09:06 <geertu> Something truncated/wrapped the long Link: tag?

09:08 <ukleinek> geertu: indeed, double-checking shows I omitted ".org" from the link, sorry for the noise

11:23 <arnd> ardb: on today's linux-next, I get this randconfig link failure: "ld.lld: error: undefined symbol: __aeabi_read_tp".

11:24 <arnd> So far, only one instance out of ~100 builds, but I never saw it with yesterday's linux-next or before

11:24 <arnd> I think it's from __builtin_thread_pointer() in your commit 50596b7559bf ("ARM: smp: Store current pointer in TPIDRURO register if available")

11:25 <arnd> this is a thumb2-enabled kernel

11:51 <arnd> I see it happen with clang-13 and clang-14 but not gcc-11, may be a clang bug

19:25 <amstan> Hello arnd , I was wondering about https://lore.kernel.org/linux-arm-kernel/CAK8P3a0g82DoivaADueeOcKOjNVDiutZLAAWAROzgvuYt83Z3w@mail.gmail.com/

19:25 <amstan> I was the one that suggested we keep the aliases in the dtsi file

19:27 <amstan> I know that each board might pick and choose their aliases, but the hardware has certain names for i2c blocks, eg: i2c0 is ffc02200

19:27 <amstan> it seems weird for a board to rename i2c1 to i2c0

19:28 <amstan> There's also prior art for the dtsi declaring all the possible aliases: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288.dtsi

19:34 <arnd> we should probably fix the rk3288 one as well

19:37 <amstan> awww, that's going to result in a lot of boards declaring those

19:38 <dianders> arnd: you didn't respond to my arguments about this at <https://lore.kernel.org/r/CAD=FV=Wi9xTnWTPbakSnf9rKkiT+4AT=3db-uwhww1bdLKjv9g@mail.gmail.com/>. I take it you still disagree with my point of view on this?

19:45 <arnd> yes, I don't see there is any point expecting the device naming in user space to be correlated with naming in SoC specifications, there are just too many layers between the two, and the aliases to me are just a way for the OS to get stable naming across boots, not necessarily the naming that a hardware person dreamed up

19:51 <dianders> > there are just too many layers between the two

19:51 <dianders> Hrm. I'm just not sure I see all the layers. ...and it seems to work fine so I guess I don't see the things that would make this difficult to keep working?

19:51 <dianders> In any case, would you object to me putting all the exact same aliases in the board .dts file if they are removed from the .dtsi file (ideally, even the "disabled" ones so that the dynamic ones start later?). It will mean a bunch of duplication between dts files but <shrug>. It would really be a pain to go back to do a lookup each time I look at dmesg to figure out what i2c bus it's talking about again.

19:53 <arnd> I'd prefer not to have any aliases for disabled nodes, that just seems silly

19:53 <dianders> ...but it has the advantage of forcing the "dynamic" numbering to start later, which is nice.

19:54 <arnd> why not assign an alias for each bus then?

19:55 <arnd> I mean each bus that is in the system, to make sure the off-soc ones also have stable names

19:55 <dianders> LOL, I seem to remember getting yelled at for that type of thing before. Someone saying that the static numbering only made sense for well-defined numbers in the SoC. I'll see if I can dig it up.

19:56 <arnd> that sounds very wrong, the whole point of the stable numbers is to make the naming stable regardless of the probe order or which driver gets loaded first

19:57 <ukleinek> ideally however nothing would depend on the actual numbering

19:58 <amstan> It certainly makes things more complicated if one has to worry about both the alias and enabling of the device. I don't see when it would be ever a good idea to have differing numbers in the dts vs userspace.

20:02 <dianders> > that sounds very wrong, the whole point of the stable numbers is to make the naming stable regardless of the probe order or which driver gets loaded first

20:02 <dianders> I couldn't find anything, so possibly I dreamed it. OK, I'm happy to do it like this if it makes people happy. I still would prefer the approach of it being in the .dtsi file but I agree that it's not too hard to put it in board .dts files and if it makes everyone happy then it's fine.

20:04 <dianders> > ideally however nothing would depend on the actual numbering

20:04 <dianders> Yeah, production code shouldn't deal with it. ...but during bringup / support of hardware, it's handy that when the EE says "OK, the device should be on i2c-4" that I can more easily find i2c-4 and I can easily find error messages in dmesg relating to i2c-4.

20:37 <amstan> if i were writing a kernel from scratch that was using a dt, i would prefer if userspace exposed my ports with the exact name the dt used

20:38 <amstan> so this is why this aliases business confused me

20:38 <amstan> but i expect in linux it's due to historical reasons

20:44 <arnd> amstan: I think the unit-names with the hexadecimal addresses would be rather confusing if you try to use them to match the chardev device numbers. Historically those could only be 8-bit numbers, I think we can do 32-bit device nodes now (or close to that), but not 64-bit

20:44 <arnd> so you'd need some form of mapping anyway

20:46 <arnd> and if you are thinking of the labels in the DT, those are not really meant to be interpreted, they are just syntactic sugar to avoid spelling out the whole device path every time you refer to a node in dts

23:56 <mmind00> arnd: at least for i2c there are things like i2cdetect as well ... as dianders noted having busses that are labeled on the soc-side (i2c2 etc) named completely different in aliases might produce strange effects

23:57 <mmind00> arnd: i.e. amateur developer wants to add a yet unsuported i2c device, finds it on i2c2 without realising that there is that alias in between which actually makes that i2c5 on the soc