wiki: Add Core chatlog for 2020-06-11

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

1 files changed, 102 insertions, 0 deletions

diff --git a/wiki/Chat_log/20200611-core-chatlog b/wiki/Chat_log/20200611-core-chatlog
new file mode 100644
index 0000000..5d62837
--- /dev/null
+++ b/wiki/Chat_log/20200611-core-chatlog
@@ -0,0 +1,102 @@
+09:28 < geertu> Welcome to today's Core Group Chat Meeting!
+09:28 < geertu> Agenda:
+09:28 < geertu> 1. Status Updates
+09:28 < geertu> 2. Discussion Topics
+09:28 < geertu> Topic 1. Status updates
+09:28 < geertu> A) What have we done since last time:
+09:28 < geertu> Marek converted the U-Boot PCNET and EEPRO100 drivers to DM, added CI
+09:28 < geertu> tests for them, and synced the U-Boot Gen2 MSTP tables.
+09:28 < geertu> Morimoto-san worked on Renesas inside Paper Work, and updated his local
+09:28 < geertu> machine.
+09:28 < geertu> Shimoda-san submitted DT binding doc conversions ({rcar,usb}-dmac,
+09:28 < geertu> ipmmu) and fixes for IOMMU device node names.
+09:28 < geertu> Geert did more DT binding doc conversions (bsc, em,gio, rza1-irqc, cpg),
+09:28 < geertu> leading to more DTS and dt-schema fixes, reviewed lots of RZ/G1H
+09:28 < geertu> patches, and started looking into implementing QEMU gpiodev support as
+09:28 < geertu> an interface.
+09:29 < geertu> B) What we plan to do till next time:
+09:29 < geertu> Marek plans to convert the U-Boot dc2114x driver to DM and add CI tests
+09:29 < geertu> for it, and prepare for the 2020.07 release.
+09:29 < geertu> Shimoda-san plans to convert the iommu doc to json-schema, and add
+09:29 < geertu> r8a77961 support.
+09:29 < geertu> Geert plans to refactor the GPIO Aggregator parsing, do more DT binding
+09:29 < geertu> doc conversions, and will continue QEMU GPIO virtualization.
+09:29 < geertu> C) Problems we have currently:
+09:29 < geertu> Geert is struggling with describing multi-level sh-pfc subnodes in
+09:29 < geertu> json-schema.
+09:30 < geertu> ---EOL---
+09:30 < geertu> Anything I missed?
+09:31 < geertu> Topic 2. Discussion Topics
+09:31 < geertu> Please shoot your topics
+09:32 < kbingham> pm_runtime_put_idle()
+09:32  * kbingham ducks.
+09:32 < geertu> kbingham: I'm waiting for Rafael to chime in ;-)
+09:32 < kbingham> that topic is horrrrrrible.
+09:33 < wsa> what's the context?
+09:33 < kbingham> They're basically saying "Sure - thaat would be the right way to do it ... but I don't want to fix everything"
+09:33 < wsa> I know it from SDHI :/
+09:34 < geertu> wsa: The question is: what is the right pm_runtime_*() call to make when pm_runtime_get_sync() failed
+09:34 < Marex> kbingham: did I miss something ? there was a patch for PCI too
+09:34 < geertu> I've seen pm_runtime_put(), pm_runtime_put_idle(), pm_runtime_idle(), pm_runtime_put_noidle(), ...
+09:35 < kbingham> when pm_runtime_get_sync() fails, it doesn't leave the system in the same state as when the function was entered. i.e. it takes a refcount unconiditionally.
+09:35 < kbingham> how to clean up if it fails is a ... seemingly horrible mess.
+09:35 < wsa> and why does it increment the refcnt?
+09:35 < kbingham> And no one wants to fix the function to clean itself up - becasue tehre are also lots of code paths which rely on the get_sync() incrementing, because they later decrement.
+09:36 < kbingham> Which is ... stupid ...
+09:36 < kbingham> because if the get_sync() fails, then surely you cant rely on the code between the get and the put to work anyway!
+09:37 < wsa> yes, without knowing details, it seems right to me to fix the function itself
+09:37 < wsa> even if it is a lot of work
+09:37 < kbingham> I'm scared to reply to the  thread fearing what I'd get dragged into - but I'm surprised that no one else has said "Ugh ... that's wrong?"
+09:38 < wsa> maybe everone is scared?
+09:38 < wsa> i have patches for this in my I2C inbox but I was really wondering about them
+09:38 < wsa> it just feels wrong
+09:38 < geertu> wsa: http://lore.kernel.org/r/5127441.yGvM1JjtLk@kreacher
+09:38 < wsa> but I wanted to tackle it after I completed the merge window
+09:39 < kbingham> I'm going to have to add linux-pm to my lists aren't I :S
+09:39 < kbingham> at least it's easy to pull in with nntp support on lore.
+09:40 < geertu> pinchartl: So you think we should always handle pm_runtime_get_sync() failures?
+09:40 < shimoda> oops, about pm_runtime_get_sync(), i also got such a patch for rcar-pci, and i had submitted my R-b... Should I recall?
+09:40  * geertu admits not having looked in all its failure modes
+09:41 < kbingham> shimoda, techincally the patch is probably 'right' currently ... it's just the wrong way to do the real fixes.
+09:41 < geertu> shimoda: The bad thing is that these patches are sent out by copycats who don't know what they're changing.
+09:41 < kbingham> yup... looks like a big batch conversion finding matches with cocci
+09:41 < kbingham> which implies that the 'lot of work to fix the other paths' is ... just the same route - and thus entirely feasible ;-)
+09:42 < wsa> well, we could use coccinelle the same way to convert most of the drivers relying on the refcnt being increased
+09:42 < kbingham> precisely ;-)
+09:42 < wsa> I wonder if there is a reason why incrementing the refcnt makes sense
+09:43 < wsa> I will start another thread right away and ask Rafael; I will CC renesas-soc
+09:43 < kbingham> oops hit the wrong option, and now downloading 136475 headers from linux-pm :-(
+09:43 < wsa> yay, another item for my B) list
+09:44 < kbingham> Ok - so I think that finalises my discussion point ...
+09:44 < kbingham> Anything else?
+09:46 < wsa> next meeting?
+09:47 < geertu> Thursday, July 9?
+09:47 < wsa> I am very likely on holiday then, and the week after
+09:48 < wsa> July, 2nd?
+09:49 < shimoda> July, 2nd is OK to me
+09:49 < geertu> That's during ELC-NA ;-)
+09:49 < wsa> i see
+09:49 < geertu> However, I can handle
+09:50 < geertu> As everything is virtual these days
+09:50 < morimoto> geertu: Do you join ELC-NA ?
+09:50 < geertu> morimoto: Yes I will
+09:50 < morimoto> Is it by-F2F or by-net ?
+09:50 < geertu> Pay 750 USD less, and avoid ESTA/TSA, so why not? ;-)
+09:50 < geertu> morimoto: by-net, 50 USD only
+09:51 < pinchartl> geertu: I'm not sure we shoudl always handle them
+09:51 < morimoto> OK, nice to know :)
+09:51 < pinchartl> it was a real question, I don't know if there could be valid cases where the call fails
+09:51 < Marex> morimoto: you can always hang around this irc and socialize with everyone , for $0
+09:51 < wsa> I won't have internet during my holidays, so I'd like some wrap-up before I leave
+09:52 < morimoto> Marex: hehe $0 is nice :)
+09:52 < morimoto> Marex: without T-shot :(
+09:53 < wsa> so, if it does not collide too much with ELC, I'd like the July, 2nd
+09:53 < morimoto> s/T-shot/T-shirt
+09:53 < geertu> wsa: Are you allowed to move to no-Internet zones with covid-19 still around?
+09:54 < morimoto> July 2nd is OK for me, too
+09:54  * geertu thought t-shot was right, in a comment for Marex ;-)
+09:56 < wsa> geertu: we go canoeing, so we won't see much people (hopefully!) :)
+09:57 < geertu> Any other topics?
+09:58 < geertu> July 2nd it will be?
+09:59 < Marex> sounds good
+09:59 < geertu> Thanks for joining, and have a nice continued day!