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

09:05 < wsa> welcome to the last IO meeting this year
09:05 -!- horms [~horms@2400:2650:39e2:a000:c685:8ff:fe7c:9971] has joined #periperi
09:05 < wsa> here are the status updates:
09:05 < wsa> Status updates
09:05 < wsa> ==============
09:05 < wsa> A - what have I done since last time
09:05 < wsa> ------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : resubmitted fixes for fallback to PIO in the sh-sci driver
09:05 < wsa> Kaneko-san
09:05 < wsa> : got r8a77990 I2C SYS-DMAC enablement merged
09:05 < wsa> Marek
09:05 < wsa> : adjusted the thermal API to handle per-driver parameters and converted drivers
09:05 < wsa>   to use it, also reposted PCA953x PM patches
09:05 < wsa> Niklas
09:05 < wsa> : got all HS400 patches in an upstream tree merged (except for the final DT patch)
09:05 < wsa> Shimoda-san
09:05 < wsa> : investigate the PWM backlight issues and submitted a workaround patches,
09:05 < wsa>   submitted an explanation of USB virtualization for eLinux, reviewed RZ/G2E USB
09:05 < wsa>   related patches, investigating an issue that USB3 peripheral's transfer stops
09:05 < wsa>   unexpectedly if g_ether/g_ncm is used, and investigate an issue that SCIF5 on
09:05 < wsa>   R-Car E3 doesn't work with SYS-DMAC
09:05 < wsa> Simon
09:05 < wsa> : posted RAVB phy-mode and no-link patches for Ebisu and posted an RFC to fix
09:05 < wsa>   the RAVB rx csum VLAN issue
09:05 < wsa> Wolfram
09:05 < wsa> : sent out two new series for I2C core suspend handling, implemented two scripts
09:05 < wsa>   to convert data to periject, further discussed and reached agreement about
09:05 < wsa>   watchdog suspend/resume handling and documented it properly, review of various
09:05 < wsa>   patches including Marek's thermal series, looking for and sending out
09:05 < wsa>   stalled 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 resubmit final patch for fallback to PIO in the sh-sci driver
09:05 < wsa> Kaneko-san
09:05 < wsa> : wants to
09:05 < wsa> Marek
09:05 < wsa> : wants to handle the thermal patchset feedback
09:05 < wsa> Shimoda-san
09:05 < wsa> : wants to ping the PWM maintainer if needed and continue to investigate
09:05 < wsa>   the USB3 peripheral + g_ther/g_ncm issues
09:05 < wsa> Simon
09:05 < wsa> : wants to follow-up on RAVB rx csum for VLAN patch
09:05 < wsa> Wolfram
09:05 < wsa> : wants to keep at the I2C core suspend handling series, check upstream SDHI bug
09:05 < wsa>   report about accessing large files, work on known IIC issues, upport I2C/SDHI
09:05 < wsa>   patches
09:05 < wsa> C - problems I currently have
09:05 < wsa> -----------------------------
09:05 < wsa> Simon
09:05 < wsa> : needs testing for his RAVB rx csum for VLAN patch
09:05 < wsa> Wolfram
09:05 < wsa> : got no response for my bsp-ticket-file to periject converter and no response to
09:05 < wsa>   the mail I sent to the MM team about GMSL
09:06 < wsa> Kaneko-san's B) is still open because I wondered about the PWM on E3 (c.f. my mail)
09:06 < wsa> horms: you are waiting for the tests from the BSP team, right?
09:07 < horms> Yes. I can push the patch without such tests. But I'd rather not
09:08 < wsa> I agree
09:09 < wsa> shimoda: can you gently ping BSP team and/or Jinzo to test this patch?
09:10 < wsa> Marex: when do you think will the PCIe ATF code be upstream?
09:10 < shimoda> wsa: sorry, about what?
09:10 < wsa> shimoda: about the patch simon created for "[periperi] Cannot receive a Q-Tag VLAN flame on the ravb driver (#194782)"
09:11 < wsa> Marex: any rough estimate?
09:11 < Marex> wsa: as soon as I rework the patch on top of upstream ATF EA changes
09:11 < Marex> wsa: and then there's gonna be discussion for sure, since it's a bit controversial ... February-ish ?
09:12 < wsa> Marex: okay, thanx!
09:12 < shimoda> wsa: Jinso test team already tested the patch, so I believe he can submit Tested-by. So, I'll ask him. Also, I'll ask BSP team when they can test it.
09:12 < wsa> shimoda: ah, good news :)
09:12 < Marex> wsa: my understanding is that syncing upstream ATF with renesas ATF has higher prio, which is what I'm working on now
09:13 < wsa> Marex: I see, makes sense
09:13 < wsa> jmondi is not here now, so I'll skip the GMSL question for now
09:14 < wsa> geertu: about TDSEL, latest news look like we can implement initializing TDSEL for early ES versions. D'accord?
09:15 < geertu> wsa: Yeah, looks like that
09:15 < wsa> So, I could resend those with proper soc_device_match()?
09:15 < geertu> Yes please
09:15 < wsa> cool
09:15 < Marex> wsa: btw there's another ATF topic where upstream is concerned about renesas stuff -- whether the ATF code is properly locked out and cannot be read by later stages -- I need to check that
09:15 < horms> shimoda: thanks!
09:16 < wsa> Marex: yes. but that's more core stuff, or?
09:17 < wsa> any more IO related questions from your side? my next questions deal with periject, so I'd like to have technical discussions before that
09:17 < Marex> wsa: ask geertu :)
09:17 < wsa> :D
09:17 < Marex> wsa: I have a feeling U-Boot and ATF is kinda on the side and outside of the usual split :S
09:19 < wsa> kbingham: you there?
09:19 < wsa> pinchartl: and you?
09:19 < pinchartl> wsa: I am
09:20 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit Ping timeout: 250 seconds
09:20 < wsa> so, I wrote those two scripts. the second one needing a bugfix, still
09:20 < wsa> but in general, was it that what was desired?
09:21 < wsa> what are the next periject steps if so?
09:21 < pinchartl> I still need to check the second script
09:22 < pinchartl> regarding next steps
09:22 < pinchartl> we likely need a query tool
09:22 < pinchartl> but I think that can be developed as we go
09:22 < pinchartl> what I think is needed is proper integration of validation in the git commit hook
09:22 < pinchartl> and probably on the server side too
09:23 < pinchartl> I think it was Simon who raised the issue that uuids are not very usable (and I believe we pretty much all agree)
09:23 < pinchartl> so I think we should also try to replace that with a global ID at commit/push time
09:24 < pinchartl> I'm not sure if that can be done on the server side or just on the local side
09:24 < pinchartl> apart from that, I think we're ready to give it a try
09:24 < horms> (I don't think it was me)
09:25 < pinchartl> ok, could have been someone else :-)
09:25 < wsa> yes, i recall consensus that the unique-key should be generated at push-time
09:25 < pinchartl> one option would be this
09:25 < pinchartl> we create a file in the root directory of the git tree
09:26 < pinchartl> containing the next ID
09:26 < pinchartl> at commit time, a git hook could
09:26 < pinchartl> - fetch the latest version
09:26 < pinchartl> - increase the ID to reserve as many IDs as needed
09:26 < pinchartl> - push with non-fast-forward denied
09:27 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
09:27 < pinchartl> - patch the content locally to replace uuids with ids
09:27 < pinchartl> - push
09:27 < pinchartl> that wouldn't require server-side hooks
09:27 < geertu> And if the push fails, retry?
09:27  * kbingham[m] just woke up...
09:28 < pinchartl> geertu: if the push fails it means there was a race, so retry
09:29 < wsa> why can't we use the sha from the commit?
09:30 < kbingham> I can't believe a uuid is any less unique than a sha1?
09:30 < pinchartl> wsa: it's not about unicity, it's about
09:31 < pinchartl> "can you look at ticket 37 ? I think it duplicates 31"
09:31 < pinchartl> vs.
09:31 < wsa> i see
09:31 < pinchartl> "can you look at ticket e2ebc538-9ca3-4cab-ac9f-70563fb95b40 ? I think it duplicates 97a5e041-7835-4a20-ab53-3d16c10081e3"
09:32 < kbingham> Oh - those ids :)
09:34 < wsa> but we all should be used to sha1 with abbrev 14?
09:34 < wsa> :)
09:34 < Marex> wsa: git will soon switch to sha256, so that might be a good idea :)
09:34 < geertu> They're as easy to remember as recent Renesas SoC part numbers ;)
09:35 < horms> I believe a key requirement of the project, which lead us to develop it rather than reuse an existing system, was for offline access. Thus the attraction of a sha, uuid, or similar
09:35 < wsa> morimoto: do you know when/if there will be a new ticket file? ticket file is "bsp370" but latest bsp is 3.9.2
09:35 < geertu> We could start with sha1s, and run (atomically) a script to replace them by generated numbers at mdnight?
09:36 < pinchartl> horms: I think combining guids and global ids would be a good way to ensure both usability and offline access
09:36 < kbingham> Would that rewrite history ? or just do some magic to append a commit on top giving the id a number?
09:36 < pinchartl> we start with guids for anything new created locally
09:36 < geertu> So you can work offline, and once in a while the new commits get assigned an simpler ticket number (mapping file)
09:36 < kbingham> And if it's just a commit on top - couldn't that already 'just work' ?
09:36 < pinchartl> and they're replaced with ids when you push (which implies that you're online)
09:37 < pinchartl> kbingham: it could apply a commit on top
09:37 < pinchartl> or, as I explained, patch locally before pushing, in a local git hook
09:37 < pinchartl> I don't know if we can get access to server-side hooks
09:37 < geertu> When using a sha1, it would refer to the the sha1 of the original ticket at creation time anyway, while the ticket file itself can change later, right?
09:37 < pinchartl> or even whether server-side hooks would actually work best for what we're trying to do
09:37 < horms> pinchartl: fine, so long as there isn't a requirement to refer to gloabl ids before they are available - e.g. latency when using the debian bugtracker (maybe fixed by now)
09:38 < pinchartl> horms: I don't think we'll refer to guids in a shared environment anyway. if the guids are used locally and then patched when you push, you will have an id available as soon as the content is available to others
09:38 < geertu> I.e. all references can be to <sha1>|<Tn>, with <sha1> replaced by <Tn> over time
09:39 < pinchartl> so you would only need to use the guid during discussions if you want to refer to a ticket that hasn't been pushed yet
09:39 < pinchartl> which would cause the other party to have trouble looking at it anyway :-)
09:39 < horms> makes sense
09:40 < wsa> :)
09:40 < geertu> s/sha1/uuid/ to your liking
09:40 < pinchartl> geertu: or s/uuid/sha1/
09:41 < geertu> "s" stands for symmetry ;-)
09:41 < pinchartl> :-)
09:41 < pinchartl> the issue with using sha1 is that they're not available before you coommit
09:41 < pinchartl> commit
09:41 < pinchartl> so if you want to commit two new tickets in one go, that refer to each other, it won't be possible with a git sha1
09:42 < pinchartl> (whether we want to allow that is another question, but there could be other similar valid use cases)
09:42 < geertu> Do you need to have the sha1 of the ticket file before you add he ticket file? Or are all references added later?
09:42 < pinchartl> that's why we went for guid instead
09:42 < geertu> OK
09:42 < pinchartl> but if they're patched as soon as you push, I don't think that's a bit problem
09:42 < pinchartl> it will be very temporary
09:42 < morimoto> wsa: sorry for my late response. I don't know. I will ask to BSP team
09:42  * geertu discovers R-Car M3-W+
09:42 < pinchartl> we could actually make it even simpler
09:42 < pinchartl> - have a serial number file containing the next ID
09:43 < pinchartl> - create tickets, allocate IDs from that file
09:43 < pinchartl> - at push time, fetch first, then compute the diff between local ID and server ID
09:43 < pinchartl> - increase all new local IDs by the diff
09:43 < pinchartl> (patching new tickets)
09:43 < pinchartl> - push
09:43 < pinchartl> something like that
09:43 < pinchartl> so we wouldn't need guids
09:44 < pinchartl> but the ids would only become meaningful globally when we push
09:44 < pinchartl> using guids as temporary ids makes it clear that they're temporary
09:44 < pinchartl> so it might be better
09:44 < geertu> That would be an additional commit on top, or an ammendment of the existing commits?
09:44 < pinchartl> (although we could prefix temporary numerical ids without something to make that clear too)
09:44 < geertu> The former makes it confusing if you look at history (oh, this old reference to #4 is now actually #7)
09:45 < pinchartl> if we run all this process on the client side, it would be nice if the scripts could rewrite the history
09:45 < geertu> The latter makes it impossible to share early with a team member (non-rebasing policy)
09:45 < pinchartl> if we run hooks on the server side it would likely need to be commits on top
09:46 < geertu> So there needs to be a clear distincation between temporary and final IDs
09:46 < geertu> (e.g. uuid or Tn for temporary, #n for final)
09:47 < pinchartl> it could be as simple as using T#n vs. #n, yes
09:47 < geertu> s/distincation/distinction
09:47 < pinchartl> or ~n, or whatever
09:49 < pinchartl> does this make sense ?
09:49 < geertu> yes, it does to me
09:49 < kbingham> pinchartl, We're looking forwards to the prototype :)
09:50 < geertu> Be prepared to discover bugs in the git hook implementation? ;-)
09:50 < pinchartl> I guess it's fair to assign it to me this time :-)
09:51 < pinchartl> I won't have time before the holidays though
09:51 < wsa> i'll update my second script before the holidays
09:51 < kbingham> It doesn't sound like it would take /too/ long to sketch out.
09:52 < pinchartl> kbingham: no, it shouldn't take /too/long
09:55 < wsa> so, we can conclude this io/periject meeting?
09:55 < pinchartl> I think so
09:55 < wsa> me too
09:56 < wsa> thank you everyone!