path: root/wiki/Chat_log/20190606-io-chatlog

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