<kallisti5[m]>
xypron: that's the rub though.. they're all 8250 compatible. Having cases for each individual uart implementation seems like overkill. The fdt is literally right there
<kallisti5[m]>
The only difference is the reg-shift
hanetzer has joined #u-boot
<Tartarus>
kallisti5: I think in sum, getting someone from another OS to speak up about the oddity of this binding might be helpful
<Tartarus>
I swore that initially reg-shift was if not required heavily used
<Tartarus>
and then it got changed
<kallisti5[m]>
Tom Rini: What gets me is the reg-shift concept is really clear
<kallisti5[m]>
this "on some architectures with this uart compat string, you need to blah blah blah"
<kallisti5[m]>
is weird
<kallisti5[m]>
Tom Rini: where would I speak up about that stuff? It's such a wide-reaching thing
<sjg1>
apalos: Not on probe, needs to be on 'init'. Also remember that each firmware phase needs to be aware of what has happened before (maybe not for your use case, but is needed for Chrome OS)
<sjg1>
Tartarus: I see the DM tag series is assigned to me. I plan to send a v2 to add the schema. But any thoughts on when it should be applied? I worry that if we do it soon it might interfere with pending patches (i.e. people need to rework them)
prabhakarlad has quit [Quit: Client closed]
<sjg1>
Tartarus: So, perhaps either do it at rc2, if we are in a hurry, or -next when it opens?
<sjg1>
Tartarus: (hmmm, perhaps they are the same thing)
<apalos>
'apalos | probe = not on DM probe, but the first time the device is opened
<apalos>
that's what I was planning to do, the only init call I can find on DM, is the uclass init
___nick___ has joined #u-boot
<apalos>
and I am not sure what exactly you need on Chrome OS, but if the TPM is already started properly, there's a distinct return code from the hardware
<apalos>
So all we have to do, is run the startup and if the hardware returns "I already did that", don't treat it as an error
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
<Tartarus>
sjg1: I think the hard part of the transition is going to be platforms that are in the middle of merging, yes, and don't get changed, and it's not obvious. Can you add a CI test to catch instances of the old nodes?
goliath has quit [Quit: SIGSEGV]
___nick___ has quit [Ping timeout: 252 seconds]
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<sjg1>
Tartarus: ah yes good idea, will do
<sjg1>
apalos: Yes, understood, but we cannot have complex setup in the probe() method. I think it is tpm_open() that should do this. There is a parameter to be passed as well
alpernebbi has quit [Read error: Connection reset by peer]
alpernebbi has joined #u-boot
hanetzer has quit [Read error: Connection reset by peer]
hanetzer has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
<sjg1>
Tartarus: Speaking of transition, I'd quite like to get rid of the difference between CONFIG_IS_ENABLED() / IS_ENABLED() as well as drop the SPL_TPL_ macros, etc. I had a crack a year ago and spent a bit of time recently looking at it. Quite tricky but it would be a big clean-up
mmu_man has joined #u-boot
<Tartarus>
Yeah, I'm not sure on the right order to do some of that in
<Tartarus>
esp given some of the other messes that've been introduced by favoring if(CONFIG_IS_ENABLED(..)) over #ifdef
<Tartarus>
(When CONFIG_B logically only makes sense with CONFIG_A enabled, we cannot do if(CONFIG_IS_ENABLED(CONFIG_A)) {int foo = CONFIG_B;} and so have run in to various wrong work-arounds for that problem)
<sjg1>
Tartarus: I favour doing a reasonable first-pass conversion so that everything builds, then dealing with the run-time breakages. That in itself is a big undertaking. If we do it at the start of -next it provides a lot of time to fix things
<sjg1>
Tartarus: Honestly it is borderlnie infeasible :-(
<Tartarus>
Which?
<Tartarus>
I think my biggest feedback / issue with dropping SPL_/TPL_/VPL_ is how do we configure and build things?
<sjg1>
Basically we have separate autoconf for each phase, but generated from the same Kconfig
<sjg1>
The ~infeasible bit is dealing with the conflicting use of the macros. E.g. if we use IS_ENABLED() in one place and CONFIG_IS_ENABLED() in another, is the option SPL-dependent, or not?
<sjg1>
But when we get there is will be very nice and easy
<Tartarus>
Ah. Yeah, I just worry how we
<Tartarus>
'll deal with the legitimate differences cases
<Tartarus>
I don't know off-hand that the mmc quirks one is right
vagrantc has quit [Quit: leaving]
<sjg1>
Tartarus: Neither do I. Once we get over the hump we will select the setting for each option in SPL, TPL, Proper, etc., with suitable defaults so that it mostly works (e.g. some we will enable by default in SPL if enabled in Proper)
<sjg1>
One question is whether we want to update the Kconfig language to support this better!!
<Tartarus>
I think this gets back to Yamada-san being right, way back when. We kinda-sorta need fooboard_defconfig, fooboard_spl_defconfig, etc, and then build + combine things