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 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!