ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
prabhakarlad has quit [Quit: Client closed]
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
apritzel has quit [Ping timeout: 264 seconds]
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #armlinux
heat has joined #armlinux
heat_ has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 264 seconds]
cbeznea_ has joined #armlinux
mvaittin has joined #armlinux
monstr has joined #armlinux
gclement has joined #armlinux
luispm has joined #armlinux
luispm has quit [Ping timeout: 268 seconds]
luispm has joined #armlinux
rgallaispou has joined #armlinux
tambarus has joined #armlinux
tambarus_ has joined #armlinux
Lucanis has quit [Ping timeout: 272 seconds]
frieder has joined #armlinux
nsaenz has quit [Remote host closed the connection]
sukrutb has joined #armlinux
sukrutb has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
Lucanis has joined #armlinux
prabhakar has quit [Ping timeout: 264 seconds]
prabhakar has joined #armlinux
prabhakarlad has joined #armlinux
ezulian has joined #armlinux
nsaenz has quit [Ping timeout: 264 seconds]
nsaenz has joined #armlinux
headless has joined #armlinux
ezulian has quit [Quit: ezulian]
ezulian has joined #armlinux
sszy has joined #armlinux
luispm has quit [Quit: Leaving]
<maz>
geertu: mind if I Cc you on my reply to 20240214052050.1966439-1-yoshihiro.shimoda.uh@renesas.com ? I really think they could use some guidance.
<geertu>
maz: I don't mind. BTW, I'm on linux-renesas-soc, which is already in CC.
headless has quit [Quit: Konversation terminated!]
apritzel has joined #armlinux
luispm has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
apritzel has quit [Ping timeout: 268 seconds]
<maz>
geertu: thanks.
psydroid has joined #armlinux
Amit_T has joined #armlinux
shoragan has quit [Read error: Connection reset by peer]
a3f has quit [Read error: Connection reset by peer]
shoragan has joined #armlinux
a3f has joined #armlinux
shoragan has quit [Read error: Connection reset by peer]
a3f has quit [Read error: Connection reset by peer]
a3f has joined #armlinux
hanetzer has quit [Ping timeout: 255 seconds]
shoragan has joined #armlinux
hanetzer has joined #armlinux
Lockesmith has quit [Ping timeout: 255 seconds]
Lockesmith has joined #armlinux
prabhakar92 has joined #armlinux
prabhakarlad62 has joined #armlinux
prabhakarlad62 has quit [Client Quit]
prabhakar has quit [Ping timeout: 256 seconds]
prabhakarlad81 has joined #armlinux
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar92 has quit [Client Quit]
prabhakar has joined #armlinux
prabhakarlad81 has quit [Client Quit]
prabhakarlad has joined #armlinux
monstr has quit [Ping timeout: 252 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
ezulian_ has joined #armlinux
ezulian has quit [Ping timeout: 255 seconds]
mvaittin has quit [Ping timeout: 256 seconds]
heat has joined #armlinux
* geertu
wonders if we will run out of 32-bit CVE number space before Y2038
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
headless has joined #armlinux
matthias_bgg has quit [Quit: Leaving]
monstr has joined #armlinux
haritzondo has joined #armlinux
haritz has quit [Ping timeout: 264 seconds]
gclement has quit [Ping timeout: 252 seconds]
prabhakar has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
mgonzalez has joined #armlinux
<mgonzalez>
robher: in a DTSO fragment, I overwrote the compatible prop to add a more specific string. narmstrong shrewdly pointed out that perhaps an overlay isn't supposed to tweak the compatible prop. What do you say?
luispm has quit [Quit: Leaving]
<mgonzalez>
In fact, I'm not sure what happens if we compose orthogonal overlays. The last one to be applied would "win" and have its compatible prop visible, making order of overlays matter...
monstr has quit [Remote host closed the connection]
<mgonzalez>
This would argue for not changing the compatible prop in overlays, if order should not matter.
Lockesmith has quit [Ping timeout: 255 seconds]
Lockesmith has joined #armlinux
Lockesmith has quit [Remote host closed the connection]
Lockesmith has joined #armlinux
prabhakar has joined #armlinux
prabhakarlad has joined #armlinux
tambarus_ has quit [Ping timeout: 255 seconds]
tambarus has quit [Ping timeout: 255 seconds]
kgdrenefort has quit [Quit: WeeChat 3.0]
<robher>
mgonzalez: Considering overlays can transform dtb A into dtb B for any value of A and B, there's a lot of policies to define. We've pretty much defined none of them.
<ukleinek>
robher: doesn't work for any value of A and B last time I checked?! (An overlay cannot remove a property, can it?)
<robher>
mgonzalez: A case for changing the top-level compatibles actually came up recently. If we use it to determine which dtb a bootloader should use, then it needs to be unique and with multiple overlays it may not be unique.
kgdrenefort has joined #armlinux
kgdrenefort has quit [Client Quit]
<ukleinek>
mgonzalez: if the first overlay changed the compatible from E to F and the second from E to G, the second doesn't win, but doesn't apply on top of the first?!
<mgonzalez>
ukleinek: right now we have base DT with compatible = A, then overlay 1 with compatible = B,A ... if overlay 2 has compatible C,A then depending on if we apply overlay 1 or 2 first, the live compatible string would differ, I think