[00:38] *** paulk-leonov has quit IRC (Ping timeout: 268 seconds)
[08:00] *** ebarretto has quit IRC (Ping timeout: 272 seconds)
[12:32] <ezequielg> hverkuil: hi there \o
[12:32] <ezequielg> are we good to merge the API on 5.11?
[12:46] <hverkuil> ezequielg: I'll likely look at this tomorrow.
[12:47] <ezequielg> Keep in mind we will need another iteration already. So far, very minor. See my reply to patch 07/13.
[12:48] <hverkuil> first thing tomorrow morning :-)
[13:28] <paulk-leonov> I'll try to look at test on cedrus in the next days
[13:29] <paulk-leonov> and get up to speed on the status of per-slice mode
[14:06] <djrscally> pinchartl: got a second?
[14:10] <pinchartl> djrscally: I can try :-)
[14:13] <djrscally> I'm hoping it will be a second anyway, if not maybe better on the list; so you suggested setting adev->fwnode.secondary in the cio2-bridge code instead of waiting for the i2c device to be initialised. This works fine, but the i2c dev then takes a reference to that fwnode, and drops a symlink into /sys/kernel/software_nodes/< sensor _HID>
[14:13] <djrscally> That outstanding reference means I can't kfree() the bridge cleanly, because it'll delete the memory for that software_node
[14:16] <djrscally> Which is only really a problem if we want to reload ipu3-cio2
[14:17] <djrscally> But yeah, anyway; I think it's safe if I allocate each sensor individually with devm_kzalloc(&adev->dev...) - even if the module is reloaded the memory wouldn't be freed, so it should be alright. Does that sound sensible?
[14:20] <pinchartl> isn't the initialization performed by cio2-bridge something that should really be a one-off init ?
[14:20] <pinchartl> cleaning it up on module unload and redoing it on module reload is neat, but is it worth the additional complexity ?
[14:21] <pinchartl> we're really looking at a process that "patches" the devices in the system
[14:21] <djrscally> I'm happy with that answer, but ipu3-cio2 does have a .remove() function which in effect won't work if we leave it as-is
[14:22] <djrscally> Or well, it'll work, but re-inserting the module won't
[14:23] <pinchartl> could we move cio2-bridge to a module that can't be unloaded ?
[14:23] <pinchartl> with the ipu3-cio2 module depending on it
[14:25] <djrscally> Yeah sure, that was pretty much the original route
[14:26] <pinchartl> that way it wouldn't need to be built-in
[14:26] <djrscally> And I guess just have cio2_pci_probe() check for an endpoint and request_module() if it doesn't find one
[14:27] <pinchartl> that, or you can export a dummy function from cio2-bridge and call it in ipu3-cio2. the kernel will then automatically load cio2-bridge before ipu3-cio2. it's easier
[14:29] <djrscally> Works for me
[14:29] <djrscally> Alright, thanks :)
[14:30] <pinchartl> you're welcome
[14:30] <pinchartl> sailus: does that work for you ?
[14:59] <djrscally> Actually; can it be as easy as not providing cio2_bridge_clean()? ipu3-cio2 won't try to init it twice if we don't call clean() on unload, because when it loads again the endpoint will still be there so the whole thing will be skipped
[15:05] <pinchartl> that should work too
[15:06] <sailus> pinchartl: I'm in a meeting now but I'll try to look into this later today or tomorrow.
[15:13] *** b-rad has quit IRC (Ping timeout: 256 seconds)
[20:58] *** sailus has quit IRC (Ping timeout: 272 seconds)