1 files changed, 173 insertions, 0 deletions
diff --git a/wiki/Chat_log/20190606-io-chatlog b/wiki/Chat_log/20190606-io-chatlog
new file mode 100644
index 0000000..06a1875
--- /dev/null
+++ b/wiki/Chat_log/20190606-io-chatlog
@@ -0,0 +1,173 @@
+09:05 < wsa> So, let's start the IO meeting
+09:05 < morimoto> she can't talk anyway :)
+09:05 < neg> Swedish is easy, don't know what you are talking about
+09:05 < morimoto> geertu: thanks
+09:05 < wsa> as always, the collected reports, let me know if that needs fixing:
+09:05 < wsa> A - what have I done since last time
+09:05 < wsa> ------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : reduced delays in the MSIOF driver and looked into USB regression causing
+09:05 < wsa>   WARNING during second system suspend
+09:05 < wsa> Marek
+09:05 < wsa> : worked on and sent patch for Gen3 PCIe lockdep issue on root complex removal
+09:05 < wsa> Niklas
+09:05 < wsa> : got issues with "SDHI runtime PM enablement" resolved and patch was applied,
+09:05 < wsa>   assisted Wolfram with OOPS debugging
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : submitted patches to improve SDHI performance with IOMMU, PM and SPDX patches
+09:05 < wsa>   for PWM, removed unused features in USBHS, fix imbalance powered flag for
+09:05 < wsa>   USB2-PHY, and handled delays for the WDT, reviewed USB patches dealing with
+09:05 < wsa>   role switch support, researched removing the r8a66597-udc, and reported a bug
+09:05 < wsa>   about USB SSD with xHCI
+09:05 < wsa> Simon
+09:05 < wsa> : posted and merged v4 of Gen3 IPA support and dynamic power coefficient patches
+09:05 < wsa> Ulrich
+09:05 < wsa> : sent v2 of "ravb: implement MTU change while device is up"
+09:05 < wsa> Wolfram
+09:05 < wsa> : started to work on converting i2c_new_dummy users, worked on analyzing various
+09:05 < wsa>   OOPSes, sent out a series improving HS400 quirks, took over add. SDHI task from
+09:05 < wsa>   Niklas, assisted Shimoda-san with WDT delay cycles and SDHI IPMMU improvements,
+09:05 < wsa>   picked up "WDT handover after boot" topic again, reviewed RWDT, SDHI, i2c slave
+09:05 < wsa>   patches
+09:05 < wsa> B - what I want to do until next time
+09:05 < wsa> -------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : wants to look into SCIF TX DMA length of 0 issue
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : wants to continue to discuss SDHI driver with IOMMU, change memcpy() to
+09:05 < wsa>   assignments in USBHS driver, and investigate imbalance enable/disable
+09:05 < wsa>   in rcar-gen3-usb2 driver as well as USB SSD issue
+09:05 < wsa> Simon
+09:05 < wsa> : wants to follow up on RAVB on E3/D3 Errata
+09:05 < wsa> Wolfram
+09:05 < wsa> : wants to continue with i2c_new_dummy conversion, finalize HS400 quirks patch
+09:05 < wsa>   series, continue with add. SDHI task, ask for help regarding the workqueue
+09:05 < wsa>   related OOPS
+09:05 < wsa> C - problems I currently have
+09:05 < wsa> -----------------------------
+09:05 < wsa> Kaneko-san
+09:05 < wsa> : patch "rcar_gen3_thermal: Update calculation" is reviewed but stuck
+09:05 < wsa> Wolfram
+09:05 < wsa> : got no response from Guenter about the WDT handover topic, needs the
+09:05 < wsa>   information which Gen3 SoCs cannot do SDHI tap auto correction with HS400
+09:05 < wsa>   because this issue crashes M3N with current upstream kernels
+09:06 < wsa> about Kaneko-san's patches being stuck, maybe it would help if we add some Tested-by tags?
+09:06 < wsa> (I didn't see any in patchwork)
+09:07 < wsa> horms: neg: do you have some minutes to do that?
+09:08 < horms> wsa: I think I have done so. But perhaps I should repost with those tags?
+09:08 < neg> wsa: will do
+09:08 < wsa> uli_: David Miller nacked "ravb: implement MTU change while device is up". does his reply show a clear way forward?
+09:09 < wsa> horms: I also thought you did... but I couldn't find the tags
+09:09 < uli_> depends if i understand him correctly
+09:09 < horms> wsa: let me take a look and take some appropriate action
+09:09 < wsa> It may be good to resend with tags, and then Niklas can add his as well
+09:09 < wsa> horms: thanks
+09:09 < uli_> we could reset the mtu if the re-open fails, but then the device may still go down because of an mtu change
+09:09 < uli_> in theory...
+09:09 < geertu> uli_: I failed to parse his last sentence.
+09:10 < uli_> i think there is an if too many at the start
+09:10 < geertu> OK, so he wants to revert the MTU change on failure
+09:10 < uli_> that's how i read it
+09:11 < geertu> Fortunately netdev_update_features() cannot fail (at least it returns void ;-)
+09:11 < wsa> how are other drivers handling it?
+09:11 < uli_> they aren't, as far as i could tell :)
+09:11 < uli_> some implement mtu changes while the device is up, but that is somewhat complex
+09:11 < uli_> most just take the device down and up again
+09:12 < horms> I think that such a scheme would be an improvement over what we currently have
+09:12 < geertu> And, in theory, the ravb_open() after MTU revert might fail, too?
+09:12 < uli_> possibly
+09:13 < wsa> That sounds like a question for David?
+09:14 < uli_> i suppose so
+09:14 < wsa> can you take care of that?
+09:14 < uli_> i will
+09:14 < wsa> thanks!
+09:15 < horms> I wonder why a failure might occur and if there is any value in trying to unwind
+09:15 < wsa> shimoda: any news which SoCs have the issue with "SDHI tap autocorrection and HS400"?
+09:16 < geertu> horms: The device might not support the new MTU value?
+09:16 < wsa> (I suppose not, but I still wanted to ask :))
+09:16 < geertu> (e.g. too large)
+09:16 < wsa> Last time, Goda-san suggested to wait some time for confirmation from the HW team, I think
+09:16 < horms> geertu: sure. its possiible. but the driver should know the max mtu of the device
+09:17 < horms> geertu: anyway, I'm just thinking out loud
+09:17 < geertu> horms: .ndo_change_mtu() is passed the value from userspace?
+09:17 < uli_> i assumed that one if the various initializations may fail (dmac, clock, phy, whatever)
+09:17 < wsa> morimoto: I got a mail two weeks ago "peripelist | Access to project was granted". Is there a change in infrastructure? (Maybe I missed some information?)
+09:17 < geertu> without checking?
+09:18 < morimoto> wsa: I exchanged periject git repository access for periperi people. now all member can push. I guess it is for it ?
+09:19 < shimoda> wsa: unfortunately hw team is investigating this issue now
+09:19 < geertu> morimoto: I received the access email for peripelist and periupport
+09:19 < wsa> morimoto: the mails mentioned "peripelist" and "periupport", not "periject"
+09:20 < morimoto> wsa: Oops, "peripelist". I exchanged *not* to push it.
+09:20 < morimoto> "periject" : all member can push
+09:20 < wsa> shimoda: Ok, I will wait some more. Thanks for the heads up.
+09:20 < morimoto> peripelist / periupport : all member can't push
+09:21 < wsa> Ah, now I see
+09:21 < morimoto> wsa: geertu: I guess no more update for peripelist / periupport, right ?
+09:22 < geertu> morimoto: Indeed: GitLab: You are not allowed to push code to this project.
+09:22 < geertu> morimoto: Good, we we won't update those anymore ;-) periject rulez!
+09:22 < morimoto> I'm sorry I didn't mention
+09:22 < morimoto> mention about it
+09:22 < wsa> any open questions from your side?
+09:24 < horms> geertu: dev_set_mtu_ext() calls __dev_set_mtu() which in turn calls ndo_change_mtu(). dev_set_mtu_ext() also chacks dev->max_mtu
+09:24 < geertu> horms: So it's not expected to fail
+09:24 < wsa> horms: just to make sure, please drop the SDHI upport for Kaneko-san. We need the info from the HW team before we decide how to continue
+09:24 < horms> geertu: I can't say for sure. But that is my reasoning at this point
+09:24 < horms> wsa: ack
+09:25 < wsa> horms: I see you found some MM upporting tasks for him meanwhile :)
+09:25 < horms> geertu: I recall that this kind of helper is a relatively new invention to simplify driver code. So I think the assumption is the check prevents some failure modes.
+09:26 < horms> wsa: yes, pinchartl was very helpful
+09:28 < wsa> okay, then, I think we are done with this meeting
+09:28 < wsa> So, thank you all for your work!
+09:29 < pinchartl> regarding periupport, we're still missing support for an equivalent feature in periject...
+09:30 < wsa> you mean a visualization of which patch is already processed?
+09:30 < morimoto> pinchartl: which feature ??
+09:31 < pinchartl> visualization is one of them
+09:31 < pinchartl> but also a way to easily mark patches that we don't want to upstream
+09:31 < pinchartl> with a reason
+09:31 < pinchartl> in a nutshell, a BSP patch tracker
+09:31 < pinchartl> which is exactly what pariupport is
+09:31 < geertu> And I need to improve my YAML parsing skills, as my old bash scripts to auto-update upstreamed periupport commits can no longer be used
+09:31 < pinchartl> periject being a task tracker
+09:32 < morimoto> pinchartl: about visualization, you can merge "viewer" branch
+09:32 < morimoto> pinchartl: and do "make". you can find html file again :)
+09:33 < pinchartl> that doesn't bring me a list of MM patches from the BSP :-)
+09:34 < morimoto> I think it is "idea" issue, not "tool" issue ? How about to add "remain BSP patches" file
+09:35 < pinchartl> but BSP patches != tasks ...
+09:35 < pinchartl> I don't want to create a task titled "Do not port these BSP MM patches" that refers to BSP patches that I don't want to upport
+09:37 < pinchartl> I fully agree that for BSP patches that we want to upport we should create tasks
+09:37 < pinchartl> but it's the other ones that we have no good way to handle
+09:38 < wsa> The way I handle it: some topics get a dedicated task, like "SDHI: HS400 autocorrection". The leftovers get a task like "bsp395: upport SDHI patches". In there, I can comment on them to be not upported
+09:40 < pinchartl> I don't like that much :-(
+09:40 < pinchartl> to me periupport is similar to patchwork
+09:40 < pinchartl> it tracks commits
+09:40 < pinchartl> to make sure none of them gets forgotten
+09:40 < pinchartl> while periject is a task tracker
+09:42 < morimoto> I don't understand what is the issue ...
+09:42 < morimoto> How about this ?
+09:42 < morimoto> task name = "sort BSP patches"
+09:42 < morimoto> you can list up all remain patches.
+09:42 < morimoto> you can use comment or tag or something to mark up.
+09:42 < morimoto> pick up them if it could tasks.
+09:43 < geertu> Thigns become complicated when combining multiple commits in a single task, with different paths forward
+09:43 < pinchartl> that would be like replacing patchwork by a process that adds an entry in a bugzilla titled "Handle patches posted to the mailing list" and then using it to track the state of patches
+09:44 < pinchartl> we *could* do something like that, but it's quite a hack, and I don't think it would be very practical
+09:44 < wsa> pinchartl: send patches :)
+09:44 < pinchartl> wsa: for what ? :-)
+09:45 < shimoda> pinchartl: in other words, you'd like to maintain both periupport and periject?
+09:45 < wsa> pinchartl: whatever you like
+09:46 < pinchartl> shimoda: yes and no. I think the two tools handle different needs. but I also think we could integrate periupport in periject if we wanted to, but in that case we should have a ticket file similar to what we have today in periject
+09:46 < pinchartl> (possibly in a different format, we can standardize everything on yaml if we want, but the idea remains the same)
+09:47 < geertu> Hence new BSP commits start with being an individual new periject ticket, but may be absorbed/aggreated into a larger task?
+09:47 < geertu> s/ticket/task/
+09:47 < pinchartl> geertu: no, I don't think we should create a ticket for each BSP commit
+09:48 < pinchartl> BSP commits would be stored in a single file like we do in periupport, and we would create tasks out of them as we plan/perform the backporting
+09:48 < pinchartl> one ticket per BSP commit would soon become very, very impractical
+09:49 < pinchartl> but in any case I don't think I'll win this fight, as none of us will have time to specify how this would be handled, not even talking about implementing the tooling :-)
+09:49 < neg> How about a bsp-commit.txt file similar to periupport, in it one can nack a patch and give a reason. Then add some visualisation of the delta of patches that should be upported but are not listed in any task file ?
+09:49 < pinchartl> neg: I think that's what I meant by importing a periupport-style BSP commits file, yes
+09:50 < pinchartl> (again, could be in the same format as today, or we could use yaml if we wanted to store everything in yaml)
+09:51 < wsa> pinchartl: I don't think it is a fight. It is just about spending time on it as you mentioned
+09:52 < pinchartl> wsa: it was just a metaphor, but not the best choice of word, I agree
+09:54 < geertu> Time for Core chat?
+09:55 < wsa> i think so
+09:56 < geertu> ok