00:17 <apritzel> Tartarus: any idea about the CI failure (ut lmb) I mentioned above? Seems to happen on origin/next, and blocks me from sending a PR for next ...

15:19 <sng> apritzel the fix for the issue that you mention is now in the next branch

15:45 <apritzel> sng: yes, thanks, I saw it this morning, after I rebased and my pipe magically returned as "fixed"

16:04 <calebccff> varada: so the reset command already has a flag for doing a "warm" reset.. but I think what would make the most sense would be to replace "enum sysreset_t" with a string, introduce a small "reboot mode" layer which handles parsing the "mode-..." DT properties and maintains the table of string -> magic number for each device that registers with it. Then update sysreset_walk() to call

16:04 <calebccff> reboot_mode_notify(mode) before requesting the reset

16:09 <calebccff> varada: then it will be necessary to refactor the button-qcom-pmic driver since it currently matches against the pon node for some reason. There should be a separate qcom-pon.c driver (in drivers/sysreset i guess) which would be closer to the Linux driver (and has .bind = dm_scan_fdt_dev in it's driver definition so the pwrkey/resin drivers get probed)

16:13 <calebccff> actually maybe it wouldn't be necessary to make sysreset_t a string, since the string is only needed to pass into the reboot_mode API. you could just add new variants of sysreset_walk() and sysreset_walk_halt() which take a string parameter, and just call reboot_mode_notify("normal") otherwise

18:06 <shadow> Tartarus: I sent a patch for some cleanup that should be considered for the coming stable release, it drops code and documentation of a visionfive2 board compatible, uh... board(s) Milk-V Mars CM and CM Lite; it doesn't do anything because we dropped support there anyway

18:06 <shadow> I thought it would be weird if a stable release gets shipped with phantom documentation and code for something that doesn't do anything

20:27 <calebccff> varada: oh there's already drivers/reboot-mode, but dm_reboot_mode_update() is a bit weird, i guess we'd want a new variant of that which doesn't take any arguments and iterates over UCLASS_REBOOT_MODE devices, and then to call that from sysreset_walk()

20:27 <calebccff> the reset command can also be updated to just set the reboot-mode environment variant if you give it an additional parameter

20:37 <Tartarus> shadow: Does it work in -next?

20:58 <marex> vagrantc: did you surely mean to merge the DHSOM stuff into debian u-boot port yet ?

20:58 <marex> vagrantc: I thought it didn't build correctly

21:01 <vagrantc> marex: it didn't. so i fixed it in the next patch. :)

21:02 <vagrantc> er, commit

21:02 <marex> vagrantc: uh ... sorry about that

21:02 <marex> vagrantc: I had it in my wall of todo, thanks

21:03 <vagrantc> marex: yeah, figured. I had a moment to poke at it and finish it off

21:04 <marex> vagrantc: I am still pondering how to deal with the arm64 packaging, with the firmware crap in it

21:04 <marex> vagrantc: the DRAM controller firmware is apocalyptic

21:05 <vagrantc> marex: no hyperbole there! :)

21:05 <marex> vagrantc: it's like a game over for upstreaming, sigh !

21:06 <vagrantc> marex: if the licensing is only marginally stupid, we could get it into non-free-firmware ... e.g. it looks like various bits for rockchip are plausible, but imx8* blobs are not

21:07 <vagrantc> debian opened those floodgates, and i am only waiting for it to make the u-boot packaging way more annoying

21:08 <marex> vagrantc: make u-boot depend on non-free firmware ? bah ...

21:08 <marex> vagrantc: I very much dislike that

21:09 <marex> Peng_Fan: would NXP be willing to improve the redistibution thingie when it comes the DRAM controller blobs for MX8M ?

21:09 <vagrantc> marex: with you, so much.

21:10 <marex> vagrantc: I stop here, else I will go on a violent rant about non-free software blobs infesting the bootloaderscape :(

21:10 <marex> and how we are slowly being moved into a virtual machine running on top of a pile of non-free garbage

21:10 <marex> grumb