18:05 <minecrell> arnd: Did you accidentally make the "defconfig-5.17" tag on an older commit? I just noticed that several defconfig changes are missing in 5.17, and now suddenly in linux-next as well

18:06 <minecrell> You can see it here: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=arm/defconfig, note how the defconfig-5.17 tag is on the older Samsung I2C commit

18:06 <minecrell> ah you tagged before doing the other merges

18:09 <minecrell> Can we get them back into linux-next somehow? (I guess 5.17 is too late now)

18:12 <bamse> minecrell: seems like i never got a reply from olof and failed to follow up

18:13 <bamse> arnd: https://lore.kernel.org/all/CAOCOHw43DC5P0p0U+C57JHo1YCicWA37y+gbEMEuJwsZB0NC=Q@mail.gmail.com/ <- do you have any specific suggestion?

18:14 <minecrell> I just remember that we discussed it here and arnd actually manually picked up my multi_v7_defconfig patch for DB410c

18:14 <bamse> arnd: do you want to just merge the 5.17 pull request for 5.18, or would you like me to move the patches onto my 5.18 pull request?

18:14 <arnd> bamse: up to you, whatever works best on your end

18:15 <bamse> minecrell: ahh, and i didn't understand until now that while we patches up the arm-defconfig, arm64-defconfig suffered from the same problem

18:17 <bamse> arnd: okay, i'll merge the 5.17 branch into my 5.18 branch and give you an updated pull request then...that way i'll not cause merge conflicts between my two pull requests

18:20 <arnd> Sounds good

18:21 <arnd> minecrell: the for_next branch still had the contents that were queued for 5.17 but didn't make it in the merge window

18:26 <minecrell> bamse: it looks like Olof did merge qcom-arm64-defconfig into "arm/late" in January, but I guess nothing happened with that branch

18:27 <bamse> arnd: will you discard that content (for_next and arm/late) then?

18:29 <arnd> Yes, the for_next is already gone I think, after I pushed the fixes branch there. I only kept the arm/late branch as a reference for myself

18:32 <bamse> okay

18:32 <bamse> minecrell: thanks for reminding me, i've picked up the missing arm64 patches...and i believe the arm content was good already?

18:34 <minecrell> bamse: There was just this patch for ARM32 defconfig in 5.17: https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=defconfig-for-5.17&id=7495af9308354b37a3557518d0d04f4cdb2a7837

18:36 <bamse> minecrell: right, just wanted to double check

18:37 <minecrell> bamse: I'm a bit confused by the "arm content was good already", if I understand it correctly what you're doing you'd need to pick it up in defconfig-for-5.18 :)

18:38 <bamse> minecrell: didn't arnd pick the one arm defconfig patch into v5.17-rc1? and hence it's already in defconfig-for-5.18?

18:40 <minecrell> bamse: arnd did pick it up (and also merged your qcom-arm64-defconfig pull) but it didn't end up in 5.17 as far as I understand

18:50 <minecrell> bamse: I'm quite confused by the branching here but it's definitely missing in 5.17 and linux-next so you should probably pick it up again as well

21:00 <bamse> minecrell: you're correct...v5.17-rc1 does not contain the db410c arm32 patch...

21:02 <bamse> minecrell: now it's part of for-next and will be sent again for 5.18

21:04 <minecrell> bamse: thanks :) (actually it won't be sent *again* but for the first time since you forgot last time :D)

21:08 <Mis012[m]> minecrell: if the dt binding check fails because it has a dependency on another patch in the series, do I need to reply pointing that out?

21:11 <minecrell> Mis012[m]: I suppose the question is if the clock stuff will land through a different tree than the bus stuff. In that case it's a bit unfortunate to have failing checks

21:13 <bamse> minecrell: well, ahh right... :)

21:17 <Mis012[m]> minecrell: well... I guess, but there's not really much I can do now

21:18 <minecrell> Mis012[m]: If the bot does weird stuff it's probably a good idea to make that clear in a reply (or alternatively you could do that as comment below --- when sending new versions)

21:19 <Mis012[m]> should probably send the reply right now then, but the laziness in me really wants to make it a tomorrow problem :/