Core-chat-meeting-2017-06-20

10:06 < geertu> Welcome to today's Core Group Chat!
10:06 < dammsan> i've heard that issue before
10:06 < geertu> pinchartl: Does it happen on H3 ES2?
10:06 < dammsan> maybe m3-w don't recall
10:06 < pinchartl> geertu: haha, good joke :-)
10:06 < pinchartl> (I'll tell you when I'll have an H3 ES2.0 board...)
10:06 < geertu> pinchartl: Havenn't you played with H3 ES2 in Tokyo?
10:07 < pinchartl> geertu: not to the point where I could test this properly
10:07 < geertu> Agenda:
10:07 < geertu> 1. Status updates
10:07 < geertu> 2. Core additional tasks
10:07 < geertu> Topic 1. Status updates
10:07 < geertu> A) What have I done since last time
10:07 < geertu> B) What I plan to do till next time
10:07 < geertu> C) Problems I have currently
10:07 < pinchartl> dammsan: if anything comes back to your memory, please let me know
10:07 < dammsan> ok!
10:07 < pinchartl> (now I'll stop hijacking the meeting)
10:07 < dammsan> (same here)
10:07 < geertu> 'sort -R' tells me Niklas is first
10:08 < neg> A) Nothing
10:08 < neg> B) Nothing planed (Multimedia eats time...)
10:08 < neg> C) None
10:08 < neg> --eot--
10:09 < geertu> Thank you, Niklas!
10:09 < geertu> Next is Magnus
10:09 < dammsan> A) IPMMU update posted
10:10 < dammsan> B) resend IPMMU if I get enough feedback, need to review patches from Laurent
10:10 < dammsan> C) None
10:10 < geertu> Thank you, Magnus!
10:11 < geertu> Next is Shimoda-san
10:11 < shimoda> yes
10:11 < shimoda> A)
10:12 < shimoda>  - Nothing
10:12 < shimoda> B)
10:12 < shimoda>  - Get feedback about R-Car D3's CPG for Geert-san's questions
10:12 < shimoda> C)
10:12 < shimoda>  - Nothing
10:12 < shimoda> -- EOT --
10:12 < geertu> Thank you, Shimoda-san!
10:12 < geertu> Next is Geert
10:13 < geertu> A)
10:13 < geertu> - RFC for CPG/MSSR module clock restore during resume
10:13 < geertu> - Initial Salvator XS support
10:13 < geertu> B)
10:13 < geertu> - More suspend/resume for CPG/MSSR and PFC
10:13 < geertu> - Mark periupport priority < H commits that are in linux-next
10:13 < geertu> C)
10:13 < geertu> - None
10:13 < geertu> -- EOT --
10:13 < geertu> Next is Marek
10:14 < marex-cloud> Marek is broken
10:14 < marex-cloud> A) ULCB M3 U-Boot port is posted , but only tested by booting U-Boot from U-Boot
10:15 < marex-cloud> B) work on DT conversion of the U-Boot , so we can drop DT from Linux into U-Boot and create board ports that way instead
10:15 < marex-cloud> C) none
10:15 < marex-cloud> is U-Boot even part of the core group ?
10:16 < geertu> Good question!
10:16 < geertu> dammsan: It's not listed in my SoW ;-)
10:17 < geertu> But as it's part of basic infrastructure, it fits better in core than in any of the other groups
10:18 < geertu> Regarding B, that means we'll have to update U-Boot regularly, as we keep on adding more device support to the DTS?
10:18 < marex-cloud> that's a good question
10:19 < marex-cloud> usually you don't want to update your bootloader in a delivered product
10:19 < marex-cloud> on a devkit, that might be easier
10:19 < geertu> I guess if you TFTP a specific DTB, it will take precedence?
10:19 < marex-cloud> then again, while you're adding more devices to Linux, U-Boot will only support a subset of them (we don't need ie. any of the multimedia stuff in U-Boot, maybe video out, but that's about it)
10:20 < marex-cloud> geertu: for now, I'd like to keep bundling the DT with U-Boot just like we do on other boards
10:20 < geertu> Or is the DTB stored in a separate partition on FLASH, so it cane be updated easily?
10:20 < marex-cloud> geertu: we can unbundle that later, once things are a bit more fleshed out
10:20 < marex-cloud> geertu: also, we'd probably need to patch BL2/BL3 to load two files, U-Boot and DT
10:21 < pinchartl> marex-cloud: what "other boards" ?
10:21 < geertu> marex-cloud: IC, as U-Boot need the DT for its own initialization
10:22 < marex-cloud> pinchartl: other boards in U-Boot
10:22 < geertu> it cannot load it from FLASH later.
10:22 < geertu> s/need/needs/
10:22 < pinchartl> marex-cloud: don't break my TFTP + NFS workflow
10:22 < marex-cloud> geertu: there are ways around that if your flash is memory mapped, which I'm not sure the RPC supports
10:22 < geertu> BL2/BL3 can pass a minimal DTB, and U-Boot can load a more advanced one later, which we can update when needed?
10:22 < pinchartl> I'm fine if U-Boot needs some DT that I don't need to update more often than updating the boot loader itself
10:22 < marex-cloud> pinchartl: eh ? how would that break it ?
10:23 < marex-cloud> pinchartl: OK
10:23 < pinchartl> but I want to be able to load kernel + DT over TFTP and boot them regardless of what DT is bundled with U-Boot
10:23 < marex-cloud> pinchartl: ah, that's fine then
10:23 < marex-cloud> pinchartl: you can use separate DTs for both (although it would be preferred if you didnt :) )
10:24 < pinchartl> in particular, if U-Boot patches the DT (to set the DRAM size for instance), it has to patch the DT I load over TFTP
10:24 < marex-cloud> pinchartl: U-Boot does patch the DT passed to the kernel with RAM size and ethernet MAC
10:24 < marex-cloud> geertu: well, if that's the case already, we could use that to supply DT to U-Boot
10:25 < pinchartl> marex-cloud: if you want to use the same DT for U-Boot and Linux, then add TFTP support to BL3 :-)
10:25 < marex-cloud> geertu: but I'd rather like to start slow, get the DT support in at all first and then move on to fiddling with BL
10:26 < marex-cloud> geertu: I think these are two tasks which depend on one another, but getting the DT support into U-Boot with bundled DT is much easier then complicating it with passing DT from BL
10:27 < marex-cloud> pinchartl: just use U-Boot as your TFTP client ...
10:27 < geertu> marex-cloud: OK, bundling a (minimal) DT is fine.
10:28 < marex-cloud> geertu: I'd like to bundle the same DT as we use in linux, not a minimal one ...
10:29 < marex-cloud> geertu: the less we diverge with the DT, the better
10:29 < geertu> marex-cloud: OK, but we're still developing "the one in Linux"
10:29 < marex-cloud> geertu: you can sync the one in U-Boot with the one in Linux, that's OK
10:30 < marex-cloud> geertu: until Linux pulls out the DTs from it's codebase, we don't have much other options anyway ...
10:31 < geertu> OK
10:31 < geertu> Thank you, Marek!
10:31 < geertu> Next is Simon
10:33 < horms> Todo Update
10:33 < horms>    NULL
10:33 < horms> A) What have I done since last time
10:33 < horms> B) What I plan to do till next time
10:33 < horms>    No Core task at this time
10:33 < horms> C) Problems I have currently
10:33 < horms> D) Posted/Accepted bugfix patch
10:33 < horms>    None
10:33 < horms> -- end --
10:33 < geertu> Thank you, Simon!
10:33 < geertu> Next is Laurent
10:34 < pinchartl> nothing on my side
10:34 < pinchartl> as usual :-)
10:34 < geertu> Thank you, Laurent!
10:34 < geertu> Next is Jacopo
10:35 < jmondi> yep
10:35 < jmondi> A) RZ pinctrl: sent v6 off-line to collect feedback on how to handle pinmux flags inside the driver
10:36 < jmondi> A) pinconf generic: sent patch to add output-enable, on which the RZ pinctrl depends on
10:36 < jmondi> B) Keep working on this (mostly background due to high latencies in receiving feedbacks from gpio people)
10:36 < jmondi> C) Null
10:36 < jmondi> --eot--
10:37 < geertu> Thank you, Jacopo!
10:38 < geertu> Topic 2. Core additional tasks
10:39 < geertu> Is anyone interested in doing a core additional task in Q3 (targets middle of August and middle of September)?
10:39 < geertu> Topics to consider:
10:40 < geertu>   - Taking over R-Car Gen3 CPUFreq support
10:40 < geertu>   - Salvator-XS board support
10:40 < geertu>   - R-Car D3 and Draak board support
10:40 < geertu>   - DMA (as usual ;-)
10:40 < geertu>   - As v4.14 will be the next LTS, I think it would be good to tackle the
10:40 < geertu>     missing DT description tasks by then.
10:40 < geertu>     Whether these are done in the context of base or additional contracts is
10:40 < geertu>     TBD.
10:40 < geertu>   - H3 ES2.0 PFC tasks
10:40 < geertu>   - Emergency shutdown
10:40 < geertu>       - Detection = I/O
10:40 < geertu>       - Handling = core
10:41 < horms> What is involved in the first two?
10:41 < neg> As previusly indicated I'm interested in Emergency shutdown :-)
10:42 < geertu> horms: Khiem posted a first version last year.  It received some review comments, but they were never adressed.
10:43 < geertu> IIRC, the framework itself has seen some changes too, so the patches need to be updated.
10:43 < horms> Ok, I'd be happy to look at that loose end.
10:43 < geertu> The task is
10:43 < geertu> CPUFreq,v4.13,public,khiem,R-Car Gen3 CPUFreq support
10:43 < geertu> There's a related task
10:43 < geertu> DevFreq,?,noplan,?,GPU needs DevFreq, as DVFS is shared between CPU and GPU
10:44 < geertu> but that's more complicated, as we don't support the GPU in upstream
10:45 < geertu> so it may be more appropriate to consider the latter as a separate task
10:45 < jmondi> geertu: pinchartl: I only have 1 additional task for Q3 and I'm not sure where it will be allocated, but generally speaking I would be interested in looking in cpufreq.. Maybe I can help Simon on this in Q4?
10:46 < geertu> jmondi: It's a bit too early for Q4. And we'll have to see how it goes first.
10:46 < geertu> For D3/Draak one important question is: when will hardware be available?
10:46 < pinchartl> jmondi: if you have time for multimedia in Q3, I'd like you to continue the work on the max9286 and rdacm20 drivers
10:47 < jmondi> pinchartl: that will be most of my base time, on top of which there will be an additional task tbd
10:47 < dammsan> geertu: i think remote access for D3 may be possible for first batch
10:47 < shimoda> geertu: i will get D3 boards in early July. but i doubt it though... :)
10:48 < geertu> dammsan: Good to hear that!
10:48 < dammsan> shimoda: any other boards available? =)
10:48 < geertu> Japanese "I doubt it" == "No way!"? ;-)
10:48 < dammsan> "Maybe" == "No way"
10:48 < dammsan> =)
10:48 < shimoda> anyway I negotiate someone we must need a board at least :)
10:48 < marex-cloud> geertu: since when do japanese speak english ? :)
10:49 < shimoda> dammsan: :)
10:49 < geertu> Do other D3 boards exist?
10:50 < dammsan> Not sure
10:50 < shimoda> I don't know
10:50 < horms> I think there is a schrodinger board
10:50 < dammsan> shimoda: how about other SoC? =)
10:51 < shimoda> but, i heard some option boards exist for D3
10:51 < pinchartl> dammsan: speaking of boards, is there a plan to send H3ULCBs to team members ?
10:51 < geertu> shimoda: The MCU-board for CN50?
10:52 < shimoda> dammsan: about V3M board, i'm asking board team when we can buy it
10:52  * marex-cloud would be interested in M3ULCB , since they're not in stock anywhere :-/
10:52 < dammsan> pinchartl: i think ULCBs should be purchased from within EU
10:52 < marex-cloud> also, what about the RPC driver ? Can we do something about that ?
10:52 < shimoda> geertu: sorry i don't know the detail
10:52 < dammsan> however it might be wise to wait with H3 to get ES2+
10:53 < pinchartl> dammsan: that's fine with me
10:53 < marex-cloud> dammsan: I tried, they're not in stock, more available in ~1 month ; digikey cannot ship them from US due to restrictions
10:53 < dammsan> shipito.com =)
10:54 < pinchartl> dammsan: have you used that to work around export restrictions ?
10:54 < dammsan> (they can fill in the customs declaration for you if you pay them)
10:54 < dammsan> i use them to get stuff from the US to JP all the time
10:54 < marex-cloud> dammsan: ooooooh :-)
10:55 < marex-cloud> dammsan: thanks
10:55 < pinchartl> https://www.shipito.com/en/help/faq#restricted
10:55 < dammsan> but i fill in my papers by myself
10:57 < marex-cloud> or maybe it's worth waiting for the ULCB to become available in EU again ?
10:57 < dammsan> no stress from my side
10:59  * marex-cloud really wants to test U-Boot on it :-)
10:59 < marex-cloud> dammsan: any opinion on the RPC driver ?
11:00 < pinchartl> (unrelated question as everybody seems idle: should I add comments such as "Under development" to the periupport file, or should I just leave the non-upported commits untouched ?)
11:01 < horms> <2c>seems useful to me </2c>
11:01 < pinchartl> horms: thanks
11:01 < dammsan> marex-cloud: sorry no time to look into things yet
11:02 < marex-cloud> dammsan: no stress :-)
11:05 < pinchartl> horms: another related question, are commit IDs in your arm64-dt-for-v4.13 branch stable ? can I use them in periupport, or will the commits be cherry-picked/rewritten when going upstream ?
11:06 < horms> simple answer: yes
11:06 < pinchartl> horms: thanks
11:06 < pinchartl> (unless something bad happens I assume, but that's ok)
11:06 < geertu> horms: Unless Olof is in a bad mood ;-)
11:06 < horms> That branch has been merged into ARM-SoC and is closed
11:06 < horms> Olof was a bit grumpy but pulled them anyway
11:07 < horms> However, before things are pulled they may change
11:07 < pinchartl> horms: how so ?
11:08 < horms> well for one things I make errors and fix things
11:08 < horms> for another people ask me to drop patches
11:08 < horms> and lastly the ARM-SoC maintainers ask for changes from time to time
11:09 < geertu> Anyone else interested in doing a core additional task?
11:09 < geertu> Well, you can still email me after the meeting.
11:09 < marex-cloud> geertu: what's missing on the XS ?
11:09 < pinchartl> horms: of course. fair enough. I was mostly interested in knowing whether the process involves modifying commits as part of the normal workflow
11:09 < geertu> Salvator-XS,?,plan,marek,VersaClock 5P49V6901A clock generator driver
11:10 < horms> pinchartl: no, its just for exceptions
11:10 < geertu> marex-cloud: I assume you're already looking into that?
11:10 < dammsan> geertu: at some point i would like to tackle the "multiple-devices" per pin issue we have with DT and PFC
11:10 < geertu> Plus Salvator-XS has H3 ES2.0, which has very limited PFC support for now.
11:11 < marex-cloud> geertu: patches are available, I sent them to dammsan to get an OK from him to submit to linux-clk ; will CC renesas-soc once cleared
11:11 < geertu> But lots of pins/functions/groups can be mined from the BSP. They just need review/testing.
11:11 < marex-cloud> geertu: speaking of that, dammsan , do I need to ask for clearance to submit patches from you always or shall I just submit ?
11:11 < marex-cloud> dammsan: which way do you prefer to handle this ?
11:12 < dammsan> good question
11:12 < dammsan> i think stuff ordered directly from my is good to handle the existing way
11:12 < marex-cloud> dammsan: if I ask for clearance every time, you have more control, but it introduces delays
11:12 < dammsan> however for your base task time there is no need to check with me
11:12 < geertu> Should all patches follow the reverse money path? ;-)
11:13 < dammsan> so if you have a strict contract then talk to me
11:13 < dammsan> otherwise ignore me
11:13 < dammsan> makes sense?
11:13 < dammsan> i expect everyone to coordinate with the group leaders anyway
11:14 < pinchartl> dammsan: just curious, is there any reason to hold off by default on posting patches ?
11:14 < dammsan> not really
11:14 < geertu> Most H3 ES2.0 PFC work needed is small things, not worth a full additional task. So I'd recommend just doing it when scratching an itch...
11:15 < dammsan> geertu: i noticed that ULCB has a SCIF1 as secondary debug port
11:15 < geertu> dammsan: What's the "multiple-devices" per pin issue again?
11:15 < dammsan> (that may not be populated on the board)
11:15 < geertu> dammsan: Salvator-X has, too?
11:16 < marex-cloud> dammsan: I don't quite get it, so I might just ask for your clearance until I see the pattern
11:16 < dammsan> on those two pins for RX and TX we can chose between SCIF and HSCIF
11:16 < dammsan> marex-cloud: thats fine
11:16 < dammsan> geertu: so the hardware allows us to select either SCIF or HSCIF
11:17 < dammsan> but can we do that with current DT?
11:17 < marex-cloud> dammsan: thank you
11:17 < dammsan> (without setting sofware policy)
11:17 < dammsan> that's what i mean by "multiple devices" per pin
11:18 < dammsan> i want to describe the hardware in DT =)
11:19 < geertu> dammsan: DT overlay? (modulo aliases, for which I have a hackish patch)
11:19  * pinchartl will have to leave soon
11:20 < pinchartl> I'd like to briefly discuss meeting schedules if that's fine
11:20 < marex-cloud> dammsan: is that what ie. IMX does now ? Each peripheral has a list of per-pin settings instead of what we have on RCar3 PFC ?
11:20 < pinchartl> dammsan: you expressed the desire to group multiple meetings in the same day
11:20 < dammsan> yes
11:20 < pinchartl> for this week it's too late, I'll send the invitation for the multimedia meeting for tomorrow
11:20 < dammsan> i would prefer that if possible
11:20 < dammsan> sure
11:20 < pinchartl> but for the next one, how would you like to handle this ?
11:20 < dammsan> not sure what other people think
11:21 < dammsan> i like to group together meetings and paperwork into a single day if possible
11:21 < geertu> You want to have Core, I/O, and MultiMedia meetings on the same day?
11:21 < dammsan> not sure what is the best way to deal with things
11:21 < geertu> Or on the same day of week? And switch to tri-weekly?
11:22 < dammsan> i just know that several meetings per week starting in the afternoon kind of kills the evening schedule pretty good
11:23 < geertu> With all meetings on a single day, it may be difficult to meet timezone constraints.
11:23 < dammsan> yeah there is that for sure
11:23 < pinchartl> we shouldn't start earlier than 8:00 British time
11:23 < dammsan> i would like to know if the other japanese guys have some opinion about schedule
11:24 < pinchartl> that's 16:00 Japanese time
11:24 < pinchartl> if we have three one-hour meetings, that's up to 19:00 in Japan
11:24 < pinchartl> 08:00-11:00 in the UK
11:24 < pinchartl> 09:00-12:00 in central Europe
11:24 < pinchartl> and 10:00-13:00 in Finland
11:25 < geertu> In Summer
11:25 < pinchartl> yes
11:25 < pinchartl> we'd have to strictly cap every meeting to one hour though
11:25 < dammsan> for me, i'd rather spend one day and continue after EU lunch time instead of two days
11:25 < pinchartl> which should be enough for status reporting
11:26 < pinchartl> but might be short if we need to start discussing issues
11:26 < pinchartl> or maybe 3x 1.5h meetings then ?
11:26 < neg> Maybe status reporting can be moved to email, as done for the IO group and only talk about points of interesst during the meeting?
11:26 < dammsan> with 2 group meetings on tue + wed and two days in the renesas office that kind of kills 4 nights without any chance for code output
11:27 < dammsan> if we could do it before EU lunch time then that would be very nice IMO
11:27 < pinchartl> neg: we already do status reporting through e-mail. I think it's useful to copy&paste it here, as it gives me (and others) a chance to ask questions
11:29 < neg> pinchartl: There is no call for A/B/C updates for the Core meeting by mail, but I agree that pasting it here is usefull
11:29 < dammsan> alternatively do brief 30 minutes per group before lunch, and schedule afternoon on-demand
11:29 < dammsan> but do that on a single day for all groups
11:30 < dammsan> perhaps that would make the situation worse for you guys
11:30 < pinchartl> I don't mind personally
11:30 < pinchartl> it would be nice if the meetings didn't overlap lunch time though
11:31 < dammsan> it is good with dinner break at this side of the world too
11:31  * marex-cloud doesn't mind either way
11:32 < dammsan> how about restricting to only A/B/C before lunch EU time
11:32 < dammsan> and propose afternoon topics on the fly
11:32 < dammsan> then have a lunch/dinner break
11:32 < dammsan> and get back to it
11:32 < jmondi> it's fine for me as well, but generally speaking, 1 day of just meetings it's really bad :)
11:33 < jmondi> but I understand the timezone thing...
11:33 < dammsan> yeah coming home at 21:00+ several days in a row with no code output kind of sucks
11:33 < pinchartl> another idea
11:33 < pinchartl> if it's just A/B/C in the morning
11:33 < pinchartl> and if we have the three groups on the same morning
11:33 < pinchartl> do we need to split the meeting between groups ?
11:34 < pinchartl> we could have a combined A/B/C
11:34 < dammsan> sounds good to me
11:34 < neg> I like that idea as well
11:34 < pinchartl> but then who will be responsible for writing reports ? :-)
11:35 < pinchartl> we could take turns I suppose
11:35 < dammsan> perhaps the group leaders need to bid on each patch =)
11:35 < pinchartl> I have to go now I'm afraid
11:36 < pinchartl> I'll let you continue the discussion and read the result after lunch
11:36 < dammsan> sure
11:36 < dammsan> bon apetit
11:36 < dammsan> !
11:36 < pinchartl> (oh, and schedule-wise, Tuesday is probably the worst day for me, as that's the day of my weekly Linux developers lunch in Helsinki)
11:36 < dammsan> geertu: what is your opinion about meeting schedule?
11:37 < geertu> dammsan: We could move the A/B/C to email, and use the meeting for questions/discussions
11:37 < pinchartl> dammsan: if you're still at the office, could you check with Morimoto-san about the Salvator-XS shipping issues ? in particular I'd like to know whether a permanent import is fine, as explained in my last e-mail
11:38 < geertu> That frees up some time
11:38 < pinchartl> geertu: I'd still like to copy&paste the status report here, as it often leads to questions (at least for me)
11:38 < dammsan> pinchartl: i'm not in the renesas office. i will setup a H3 ES2 board for your remote access
11:38 < pinchartl> copy & paste shouldn't be long
11:38 < pinchartl> dammsan: thank you
11:38 < pinchartl> now I really have to go
11:38  * pinchartl is gone
11:39 < dammsan> geertu: that sounds good to me
11:39 < geertu> I'd prefer not to split the meeting in before/after lunch/dinner
11:39 < dammsan> same here ideally
11:39 < geertu> Just have 1 hour for each group? And each group leader is responsible for the report for his group, as is currently done
11:40 < dammsan> that seems pretty straightforward and good to me
11:40 < geertu> Round-robin reporting of a huge 3 hour meeting with topics you may not be interested in is a killer
11:40 < dammsan> yeah for sure
11:40 < dammsan> just want to avoid having that multiple days in a row =)
11:41 < geertu> So it's all about making effective use of the limited time (1 hour/topic)
11:41 < dammsan> i agree
11:41 < geertu> s@topic@group@
11:41 < dammsan> geertu: can we improve how we handle SCIF/HSCIF in DT somehow?
11:42 < geertu> Or do we need a different split in 4 submeetings: Core. I/O, MultiMedia, Common?
11:43 < dammsan> as long as they are on the same day i'm happy =)
11:43 < geertu> I/O is usually a short meeting
11:43 < geertu> MM is usually long?
11:43 < dammsan> similar to core i think
11:43 < geertu> dammsan: pinctrl-0 and pinctrl-1, cfr. SDHI?
11:43 < neg> yes I think MM tends to be a bit longer then Core
11:45 < jmondi> a bit longer, yes
11:45 < dammsan> geertu: that's for two states within same device, no?
11:46 < geertu> dammsan: I know. As SCIF and HSCIF are handled by the same driver, we could hack in something?
11:46 < dammsan> hacking is possible for sure
11:47 < dammsan> maybe this is similar to the I2C master switch topic
11:47 < marex-cloud> dammsan: do you need to switch between those two at runtime ?
11:47 < geertu> In some sense all pinctrl is "software policy"
11:47 < geertu> have you looked at Pantelis' connector work?
11:48 < dammsan> i saw a talk from him
11:48 < marex-cloud> geertu: did that make it to mainline ? :)
11:48 < geertu> I think it would allow to describe a serial port the way we wwant
11:48 < dammsan> marex-cloud: i want to separate hardware description and software policy
11:48 < geertu> marex-cloud: No, just like DT overlays
11:49 < dammsan> if we can use both SCIF and HSCIF on pins then our DT should represent that somehow
11:49 < marex-cloud> geertu: DTOs are in mainline, I think the missing part is the configfs interface for loading them
11:49 < geertu> For the hungry people: shall we conclude the Core meeting itself? We can keep on chatting, of course.
11:49 < dammsan> geertu: good point
11:49 < geertu> marex-cloud: Right, that's the part I mean
11:55 < geertu> Thanks for joinin, and have a nice continued day!