01:27 <Peng_Fan> marex, sjg1: I got a bit lost with xPL :)

01:36 <sjg1> marex: Yes UPL sounds better, although there is now a UPL in U-Boot (Universal Payload Specification)

02:30 <rpifan> hi

12:49 <clamor> Is there ofnode version of graph parsing helper? Like of_graph_get_endpoint_by_regs or similar

13:39 <marex> sjg1: that is UPS , another delivery company , no ?

13:40 <marex> Peng_Fan: yesterday I got OEI basically running, SM partly because it depends on ELE it seems, so ... how do I start the ELE via JTAG ?

15:07 <xypron> sjg1: bootdevs can appear and disappear during runtime. How does this go together with std->hunters_used |= BIT(seq); which blocks used hunters? We need to be able to hunt for new devices at any time.

15:07 <xypron> sjg1: uclass_find_first_device() is used quite a lot. Why is it in dm/uclass-internal.h? Given the usage shouldn't it be moved to dm/uclass.h?

15:16 <sjg1> xypron: If you want to start again, you would need to clear that. The current approach is to run the boot once, hunting for devices as we go, until something boots. But, yes, if you want to start again, you'll need to add a function to clear it

15:17 <xypron> Couldn't the boodev hunt command request clearing?

15:18 <sjg1> xypron: The normal case is to probe devices when they are found...it is quite tricky to get things right if a device is not probed. E.g. there is no priv data so it might crash. So I decided to hide away the tricky function

15:18 <sjg1> xypron: Yes, it could

15:19 <xypron> sjg1: We track if USB devices are added or removed. So this is a very real case.

15:22 <sjg1> xypron: Yes. Also the user could remove or insert the network cable, so when a new round of booting starts, resetting the hunters is reasonable. I suppose we need a new method in struct bootdev_hunter to actually shut USB down

15:24 <xypron> sjg1: Isn't USB watched by a cyclic?

15:26 <xypron> sandbox_defconfig has a cyclic function for MMC.

15:28 <sjg1> xypron: But calling usb_init() twice won't rescan; you must call usb_uninit() in between

16:44 <marex> xypron: doing USB ops using background thread would be something I would like to do very much, but ... time ... didn't get to it

16:44 <marex> and by background thread I mean cyclic, similar to SD card plug/unplug detection

16:46 <xypron> Thanks marex. So up to now it is only MMC.

17:55 <Tartarus> This is what got Jerome doing the cooperative multitasking thing I believe.

18:07 <apalos> Tartarus: partially yes

18:07 <apalos> and the tpm, which takes some cycles to respond over a spi bus

18:09 <marex> Tartarus: this is not cooperative multitasking though, that would have to have each thread call yeild()

18:09 <marex> Tartarus: here it is some opportunistic single threaded operation with hooks

18:10 <marex> maybe what we need is some sort of DM-specific poll (do you have work?) hook

18:10 <marex> like we have .probe/.remove/.bind/.unbind , maybe we need .poll there ?

18:10 <marex> and then let the cyclic framework iterate over those poll hooks ?

18:11 <marex> a subsystem can pace itself and do work in chunks somehow too ... which does become cooperative multitasking, yes