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!