08:03 <Kwiboo> mmind00: Thanks! :-)

08:23 <naoki> lately I'm working for OpenWrt for Radxa boards, but one of my PR was rejected because I used not-yet-upstreamed kernel dts and u-boot defconfig.

08:24 <naoki> if ROCK 3B is merged for 6.11, when ROCK 3B for U-Boot is available(merged)? ;)

08:24 <naoki> I need to wait both are merged to make PR for OpenWrt lol

08:31 <diederik> Maybe they use the same policy as Debian, where the most important criteria is that it's accepted by the upstream maintainer?

08:46 <naoki> diederik: I think so. not bad, very good policy

08:47 <naoki> (but users want...)

08:48 <diederik> Yep, I like it too. It prevents you from (endlessly) adding random patches and stimulates others to upstream things

08:48 <arnd> mmind00: I've pulled the branch now, but got a little confused here. I already pulled your branch yesterday (though for some reason patchwork failed to detect this. I hope those get sent later though), and now saw a new pull request for the same tag. I've reworded the merge message now for the new version since it only adds the two boards

08:51 <mmind00> arnd: sorry about that ... I did send a v2 pull request yesterday as well https://patchwork.kernel.org/project/linux-soc/patch/2191200.GUh0CODmnK@diego/

08:52 <mmind00> arnd: and yeah I didn't see a bot response for previous one

08:53 <arnd> yes, that's what I meant. I had merged v1 (which failed to give you a notification), and then merged v2 on top. The contents are all fine as v2 could just as well have been a #3 v1

08:54 <mmind00> arnd: ok ... I guess I'll refrain from just doing "vX" in the future and just add stuff on top if needed ;-)

08:54 <qschulz> naoki: U-Boot wants upstreamed kernel dts before you can add support for the device. But you can cherry-pick the patches once they make it to the master branch (no need to wait for -rc or a kernel release)

08:56 <arnd> mmind00: If you send multiple PRs, I prefer to pull them in one at a time from separate tags, each with a description of the new contents. You can respin a pull request if you notice a mistake in it, but then it's better if you tell me about it separately in email or irc so I don't accidentally merge it twice

08:58 <mmind00> arnd: ok - will keep that in mind in the future :-) ... sorry for causing confusion

09:11 <naoki> qschulz: ah, yes, wait "patch is in mainline", not "next release"

09:12 <qschulz> naoki: there's a tool now to import dts from upstream in U-Boot so you don;t have much of a choice anyway, it needs to be in master for it to work I think

10:03 <Kwiboo> naoki: qschulz: as soon as v6.11-rc1-dts lands in https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ we can start picking commits from it and send U-Boot patches :-)

10:04 <naoki> hmm, I need to understand current work flow...

10:05 <Kwiboo> for my local u-boot tree I will probably just add a temp commit with a manual sync from linux-next until everything finally lands in devicetree-rebasing and can be picked

10:09 <Kwiboo> naoki: to answer your old question regarding slow microSD on 3B, I can confirm that I did not add the uhs props to DT, so it only reached non uhs speeds

10:10 <Kwiboo> there exist a io-domain vs mmc driver probe order issue that probably should be solved before adding uhs props

10:13 <Kwiboo> using uhs50 like some rk356x boards are doing could be done, but not sure that is good, as it may leave the io-domain voltage level at 3.3 during uhs mmc training

10:14 <Kwiboo> and that is what is causing issue with uhs104, the training is done with wrong io-domain config, and result in different tuning then when 1v8 would have been used

10:15 <Kwiboo> basically with uhs104 the card may not be detected at boot, because it gets one training value, if you however pull it out and plug it in after boot, it will work and training value is different because 1v8 is correctly used at that time

10:30 <mmind00> arnd: for the "Add Xunlong Orange Pi 3B" git.kernel.org claims that the commit is "not reachable from any branch" (https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?id=d79d713d602e8b32cf935ddfdf61769cb74ba1dc)

10:30 <mmind00> arnd: is this just git.kernel.org being slow or something else?

10:30 <arnd> no idea

10:32 <mmind00> arnd: it looks like it isn't part of the "for-next" branch ... it is listed in the "document merges" commit, but does not seem to be part of the branch

10:43 <arnd> mmind00: right, I was trying to merge and push one of the main branches at a time to see if that made a difference with the patchwork notification mails

10:43 <arnd> I pushed out the rest now, which should fix it.

10:45 <mmind00> arnd: looks like it, I see both the rockchip boards as well as the sophgo/dt commits in the soc/dt branch now :-)