<sjg1>
Tartarus: Just for the record, it was a driver model change without a dm: tag. It did not get properly reviewed (I was not copied) it went through the Marvell tree but affects all boards. It is quite the wrong approach
<sjg1>
Tartarus: For now, how about I apply it to -next and we can deal with it there?
<Tartarus>
sjg1: Since it was in 2022.07 and .10, yes, I suppose revert + poking Pali and Robert to fix it properly, in -next, is suitable, thanks.
<sjg1>
Tartarus: OK, yes I missed that point, sorry
<Tartarus>
marex: I mean, things that have been in for one or two releases already make me doubt another week would help
cottsay has quit [Quit: TTFN]
cottsay has joined #u-boot
<marex>
Tartarus: we have like 3 nasty issues still open, I think it would
<marex>
Tartarus: the breakage from Pali is new in this release and I am really worried there
<marex>
Tartarus: the amlogic bug should likely be fixed too if we wait a bit
<marex>
Tartarus: dtto for the mvebu
<Tartarus>
OK, you're right, I thought 777aaaa706b was in v2022.10, given git describe, but it's not
<Tartarus>
So that's easier to just revert and push back on
<Tartarus>
The EFI (not amlogic, amlogic was just unlucky) issue is on if xypron wants to push that out to me now, or not
<marex>
Tartarus: do you want revert of 777aaaa or will you revert it ? Feel free to add my AB ... still, it might be good to give Pali extra week to explain why he sent that patch in the first place
<marex>
the explanation seems lacking so far
<marex>
I somehow suspect it has something to do with turris omnia, but that's pure conjecture
<kallisti5[m]>
why do no arm / arm64 uart's seem to mention reg-shift's ?
<marex>
bbiab, food
<kallisti5[m]>
(in dts)
<Tartarus>
I posted a revert of 777aaa and Pali replied, but hasn't said he can confirm my idea that would limit those changes to just 36bit PPC
<Tartarus>
kallisti5: Binding fun, iirc
<kallisti5[m]>
every arm device seems to want to register * sizeof(uint32) for the UART's
<kallisti5[m]>
couldn't that just be a reg-shift in the dts?
<kallisti5[m]>
(like every other architecture's uart)
<xypron>
Tartarus: do want a pull request for the LMB series?
<Tartarus>
kallisti5: This makes me think of some uart binding change from years back, as to why it is the way it is
<Tartarus>
Unless I'm mistaken, or things changed again.
<Tartarus>
xypron: If you're happy enough with it, yes
<kallisti5[m]>
Tom Rini: I'm just frustrated lol. Thought i did some awesome code cleanup implementing reg + reg-shift parsing in Haiku's UART dts probing code.
<kallisti5[m]>
I even removed some BASE + (reg * sizeof(uint32)) stuff thinking there was a shift in the dts
<kallisti5[m]>
(converting to BASE + (reg << shift) ) vs a one-off #ifdef __ARM__ check
<Tartarus>
So Documentation/devicetree/bindings/serial/8250.yaml has reg-shift
<Tartarus>
But, lets see..
<kallisti5[m]>
I did a dump of the qemu arm + arm64 device trees. Just some reg's, no reg-shift's
prabhakarlad has quit [Quit: Client closed]
<kallisti5[m]>
I checked the linux code, they even check for a "reg-offset" which is added to the register base. No such thing. as far as I can tell.. most code for arm must do the "reg * sizeof(uint32)" in all cases on their In8/Out8 calls
<Tartarus>
I swear reg-shift got removed for some reason
<vagrantc>
xypron: is v2 the most recent for the LBM series?
<Tartarus>
Due to Linux not using it
<Tartarus>
and we had some grumbling
<vagrantc>
er, LMB
<Tartarus>
But it was ages ago
* vagrantc
will try to test on odroid-c2
<kallisti5[m]>
funny enough.. linux has a reg-shift check
<kallisti5[m]>
well... at least this does: ../linux/arch/powerpc/boot/ns16550.c
<kallisti5[m]>
guess I should check arm
<cambrian_invader>
the linux dt folks don't like putting register layout in dt
<cambrian_invader>
since it's their opinion that you should get it from the compatible
<cambrian_invader>
that said, ns16550 is exceptional because it is old
<kallisti5[m]>
sure, but if we can do it the same way, lets do it the same way and use the device tree
<kallisti5[m]>
reg-shift works in almost all cases
<cambrian_invader>
it's not my opinion, it's theirs
<kallisti5[m]>
sure 😆
<kallisti5[m]>
so.. arm uart PL011, 8250 should assume a reg-shift of 2?
<kallisti5[m]>
... if dts says 0
<kallisti5[m]>
😥
<kallisti5[m]>
(i'm saying 8250 for the ns16550 because we're lazy and use 8250 code on individual 16550 uarts)