diff options
| -rw-r--r-- | wiki/Chat_log/20200611-core-chatlog | 102 |
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! |