1 files changed, 143 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180419-io-chatlog b/wiki/Chat_log/20180419-io-chatlog
new file mode 100644
index 0000000..edb82a5
--- /dev/null
+++ b/wiki/Chat_log/20180419-io-chatlog
@@ -0,0 +1,143 @@
+09:02 < wsa_> Welcome!
+09:03 < jmondi> 'morning!
+09:03 < wsa_> I will start with the collected status updates (which need a bit more lines because of markdown, but hopefully they are better readable, too)
+09:03 < wsa_> Status updates
+09:03 < wsa_> ==============
+09:03 < wsa_> A - what have I done since last time
+09:03 < wsa_> ------------------------------------
+09:03 < wsa_> Geert
+09:03 < wsa_> : has nothing to report this time
+09:03 < wsa_> Jacopo
+09:03 < wsa_> : tested Kaneko-san patches for thermal on D3
+09:03 < wsa_> Kaneko-san
+09:03 < wsa_> : sent out new version of D3 thermal patches
+09:03 < wsa_> Marek
+09:03 < wsa_> : kept upstreaming PCIe patches
+09:03 < wsa_> Niklas
+09:03 < wsa_> : sent out some thermal patches and had no luck finding thermal fuses on M3-N
+09:03 < wsa_> Shimoda-san
+09:03 < wsa_> : reviewed SDHI old ES workaround and added support for USB role switch
+09:03 < wsa_> Simon
+09:03 < wsa_> : sent out new version of SDHI HS400 support and upported RAVB patches
+09:03 < wsa_> Ulrich
+09:03 < wsa_> : is on holiday
+09:03 < wsa_> Wolfram
+09:03 < wsa_> : upported SDHI & watchdog patches, made SDHI upporting master plan, did various upporting reviews & list updates,
+09:03 < wsa_>   created tree-wide series to fix clumsy platform_device handling, discussed with the syzkaller-author about QEMU
+09:03 < wsa_>   I2C abstraction, and did this new meeting minute report system
+09:04 < wsa_> B - what I want to do until next time
+09:04 < wsa_> -------------------------------------
+09:04 < wsa_> Kaneko-san
+09:04 < wsa_> : wants to address review comments of D3 thermal patches
+09:04 < wsa_> Niklas
+09:04 < wsa_> : wants to start looking into SDHI tuning patches
+09:04 < wsa_> Shimoda-san
+09:04 < wsa_> : wants to continue with USB role switch, investigate usb2.0 host suspend/resume issue, support PHY GPIO support for E3, and check QEMU with USB
+09:04 < wsa_> Simon
+09:04 < wsa_> : wants to continue with HS400 and RAVB upporting and also to update his QEMU host/guest networking comparison report
+09:04 < wsa_> Wolfram
+09:04 < wsa_> : wants to start I2C upporting, review Simon's new HS400 patches, get a first sketch of a new QEMU I2C
+09:04 < wsa_>   pass-through mechanism
+09:04 < wsa_> C - problems I currently have
+09:04 < wsa_> -----------------------------
+09:04 < wsa_> Kaneko-san
+09:04 < wsa_> : is looking for small tasks
+09:04 < wsa_> Niklas
+09:04 < wsa_> : needs someone with access to a board with thermal fuses set
+09:04 < wsa_> Simon
+09:04 < wsa_> : may need to contact RAVB patch authors directly?
+09:04 < wsa_> Wolfram
+09:04 < wsa_> : needs a way to handle (get rid of?) need of a-priori knowledge for QEMU I2C pass-through 
+09:04 < wsa_>   (to determine if a message is to be terminated with STOP or REPEATED_START)
+09:04 < wsa_> vaishali: how are things on your side?
+09:04 < pinchartl> hello
+09:05 < wsa_> and are there further comments to the status updates?
+09:06 < vaishali> wsa_ I'm almost there. Should be able to at least send RFC by tonight/tomorrow morning.
+09:06 < wsa_> nice!
+09:07 < wsa_> I will add this to the report
+09:07 < vaishali> wsa_: Thanks.
+09:08 < wsa_> horms: do you think RAVB patch authors will answer mails directly?
+09:09 < horms> I have had successful correspondence with Mizuguchi-san before, so in that case yes
+09:09 < wsa_> cool!
+09:09 < horms> It was really a question for Shimoda-san to see if he would like to handle things a different way from the past
+09:09 < wsa_> you have some language advantage there
+09:09 < horms> As I haven't made any such contact for some time
+09:09 < horms> it may or may not be an advantage :^)
+09:10 < horms> I think these issues are not pressing
+09:10 < horms> so how about I try to contact the developers directly
+09:10 < horms> and report on progress or lack thereof?
+09:10 < wsa_> sounds good to me
+09:10 < wsa_> shimoda: are you fine with that?
+09:10 < horms> It might have been better if I made such contact before posting the patches
+09:10 < shimoda> horms: i would like to be interface guy to Mizuguchi-san and Nagai-san
+09:11 < horms> shimoda: ok, sure
+09:11 < horms> I'll seend you a summary of my questions
+09:11 < shimoda> horms: i got it!
+09:12 < wsa_> the other topic I have is somehow close to that
+09:12 < wsa_> and not really new
+09:12 < wsa_> for upporting "high"-priority I2C patches, I'd mostly always need a test case
+09:13 < wsa_> how is this for you?
+09:13 < wsa_> or are the patches more straightforward there
+09:14 < wsa_> ?
+09:15 < horms> wsa_: who is this question for?
+09:15 < wsa_> open
+09:15 < wsa_> throw in your experiences :)
+09:15 < horms> Well, I think its better if there is a test case. But I also think that its possible that the patches are obviously correct.
+09:16 < horms> Depending on their contents, of course.
+09:16 < horms> My experience from RAVB
+09:16 < horms> is that I was a bit to motivated to flush out the patches for admin/reporting/... reasons
+09:16 < horms> and should have paid more attention to upstream requirements - motivation for the patch, relevance to current upstream code, etc...
+09:17 < dammsan> horms: glass is half full there =)
+09:17 < shimoda> i can ask bsp team about your questions.
+09:17 < horms> Yes, then suddenly it was half empty :)
+09:18 < dammsan> i would say 50% correct =)
+09:18 < shimoda> wsa_: all patches need a test case?
+09:18 < dammsan> but i guess it is case by case
+09:19 < wsa_> shimoda: this is what I wanted to find out if every patch needs a test case?
+09:19 < wsa_> shimoda: so I wanted to know if I2C and SDHI are special or not
+09:19 < wsa_> but it seems really case by case
+09:20 < wsa_> but in general: the more test-cases (or ways to reproduce) the better
+09:21 < wsa_> even if it is just to make sure the issue was not only fixed in the BSP kernel but also in the upstream kernel
+09:22 < wsa_> I guess we will see how it goes
+09:23 < horms> Right, especially if the patch was made against a v4.9 based BSP, which is rather old by now
+09:23 < wsa_> And I need to improve how to ask open questions ;)
+09:23 < wsa_> I don't have any other topic
+09:24 < wsa_> we don't have add. tasks this quarter and people are busy upporting
+09:24 < dammsan> wsa_: why would I2C and SDHI be special?
+09:24 < wsa_> no reason
+09:24 < wsa_> that's why I asked
+09:24 < wsa_> how other ppl would handle this
+09:25 < dammsan> i think it is important to take target platform into consideration
+09:25 < dammsan> my gut feeling is that BSP folks are focusing on solving the issue in front of them
+09:25 < dammsan> and perhaps not thinking how it affects other generatiosn / sooooooooooocs
+09:25 < shimoda> about test cases, bsp team described them in internal redmine tickets, but I don't know why but they don't describe into the commit log...
+09:26 < shimoda> sometimes i could find the tickets, but
+09:26 < shimoda> sometimes i asked bsp team
+09:26 < wsa_> shimoda: are they described in Japanese or English?
+09:26 < shimoda> of course Japanese :)
+09:26 < wsa_> :D
+09:27 < wsa_> maybe they could at least add the ticket number to the patch?
+09:27 < wsa_> not much to type, but still helpful
+09:28 < dammsan> horms: how did you handle things when you felt information was lacking?
+09:28 < shimoda> I'm not sure about adding the ticket number.
+09:28 < shimoda> anyway I'll ask them.
+09:28 < geertu> wsa_: Under the ---, upstream doesn't like private ticket numbers in public commit messages
+09:29 < dammsan> geertu: including not-yet-disclosed CVE? =)
+09:29 < dammsan> (perhaps thats a different thing)
+09:30 < wsa_> geertu: I would consider this part of the upporting work to remove them
+09:30 < horms> dammsan: my usual approach is to try to work out what the BSP developer was trying to achieve with a patch. If I can fill in gaps with documentation or some creative testing then I try to do so. But if there are gaps - particularly if I think they have some inside information (f.e. this bit changed meaning between ES versions) then I try to ask specific questions of that nature.
+09:30 < dammsan> makes sense
+09:30 < wsa_> but for internal bsp patches, this could be nice? we will see what the BSP team thinks
+09:31 < wsa_> thanks, shimoda-san!
+09:31 < wsa_> horms: yes, that's what I am trying to do as well
+09:33 < wsa_> but for quite some patches, it would speed up things a lot if test cases were available
+09:34 < horms> of course
+09:34 < wsa_> anyhow, i think we are aligned here
+09:34 < wsa_> any other topics left?
+09:34 < horms> but I think the BSP team is more receptive to specific rather than general requests
+09:35 < wsa_> ok
+09:35 < wsa_> then we can handover to core?
+09:35 < wsa_> geertu: are you ready?
+09:35 < geertu> wsa_: I am
+09:35 < wsa_> good
+09:35 < wsa_> thanks for this meeting!