wiki: add IO chatlog from 20210218

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

1 files changed, 160 insertions, 225 deletions

diff --git a/wiki/Chat_log/20210218-io-chatlog b/wiki/Chat_log/20210218-io-chatlog
index 8ba74c7..5b0f075 100644
--- a/wiki/Chat_log/20210218-io-chatlog
+++ b/wiki/Chat_log/20210218-io-chatlog
@@ -1,225 +1,160 @@
-<wsa> so, welcome to the io meeting and here are the status updates:    [16:54]
-<jmondi> 'morning everyone
-*** damm (~damm@l193216.ppp.asahi-net.or.jp) has joined channel #periperi
-<wsa> A - what have I done since last time
-<wsa> ------------------------------------
-<wsa> Geert
-<wsa> : fixed PHY Runtime PM in SH-ETH and related improvements for SMSC911X,
-      added Falcon I2C EEPROM support
-<wsa> Niklas
-<wsa> : resent Gen3 timer patches, discussed V3U timer support
-<wsa> Shimoda-san
-<wsa> : added mmc aliases to Gen2/3 board files, investigated RPC-IF driver
-      issues with BSP team, got some information about Gen3e
-<wsa> Ulrich
-<wsa> : sent atomic xfer support for i2c-rcar
-<wsa> Wolfram
-<wsa> : upstreamed V3U support for WDT, I2C, AVB0, SDHI, (H)SCIF for 5.12,
-      investigated issues of AVB1-5 and RPC-IF on the V3U Falcon board, sent
-      I2C core preparations for extended RECV_LEN sizes, improved I2C testunit
-      with RECV_LEN testcase, moved already rejected patches from new BSP list
-      to the non-target list, enabled WAIT_WHILE_BUSY and removed
-      NON_REMOVABLE workaround for SDHI
-<wsa> B - what I want to do until next time
-<wsa> -------------------------------------
-<wsa> Geert
-<wsa> : wants to revise Falcon I2C EEPROM support
-<wsa> Niklas
-<wsa> : wants to figure out number of TSC nodes on V3U
-<wsa> Shimoda-san
-<wsa> : wants to continue to investigate SDHI driver's issues, collect more
-      information about R-Car Gen3e, continue to develop R-Car S4 Ethernet
-      driver							        [16:55]
-<wsa> Wolfram
-<wsa> : wants to pick up "logic analyzer via isolated CPU" work again,
-      upstream CMT and TMU support for V3U, continue with extended RECV_LEN
-      and its R-Car support, keep working on SDHI issues
-<wsa> C - problems I currently have
-<wsa> -----------------------------
-<wsa> None reported.
-<wsa> uli__: is this audio task a big one? Because I wanted to talk about a
-      (hopefully) small RAVB task and am curious when I can get back to you?
-<uli__> that's not a problem
-<wsa> marex: what can we do to push the PCI L1 issue? Resend the patch?
-								        [16:56]
-<marex> wsa: probably disable L1 altogether
-<wsa> uli__: okay. so, i'll send you a mail with the details later.     [16:57]
-<marex> wsa: and if someone needs it in the BSP, then there can be a
-	downstream BSP patch which enables it for special cases where it might
-	work OK
-<wsa> unconditionally? or just for some devices?
-<uli__> ok, thx
-<marex> wsa: but it seems for the generic case, which maintainers seems to
-	care about, L1 is unusable
-<wsa> caring for the generic case sounds OK to me		        [16:58]
-<wsa> so we should disable it?
-<marex> the question is whether it is OK to just disable L1 altogether  [16:59]
-<marex> right
-<marex> I guess we are out of options anyway
-<geertu> FTR, I got the interupt crash during PCIe resume on M3-W again
-	 earlier this week
-<wsa> shimoday: do you want to discuss this with the BSP team?	        [17:00]
-<marex> geertu: with what PCIe card and on which CPU core ?
-<geertu> As it's not easy to reproduce, it might be hard to see if disabling
-	 L1 helps
-<wsa> shimoday: if we should disable L1 on PCIe upstream because that's what
-      the maintainers prefer
-<wsa> geertu: neg: thanks for testing the SDHI workaround removal patch. Much
-      appreciated!						        [17:01]
-<geertu> marex: e1000e: Intel(R) PRO/1000 Network Driver
-<neg> I'm happy to see that quirk gone ;-)
-<wsa> neg: hopefully it will stay "gone" this time		        [17:02]
-<marex> wsa: BSP team can keep the patch which handles the link resume  [17:03]
-<geertu> marex: No idea which CPU core
-<marex> wsa: although maybe it is just safer to turn off the L1 states in the
-	BSP too
-<marex> geertu: do you have the backtrace ?
-<wsa> marex: exactly, maybe they want to support the generic case, too ;)
-								        [17:04]
-<wsa> okay, are there questions / comments from your side?
-<shimoday> wsa: i think we don't need to discus with BSP team because it's the
-	   maintainers prefer so BSP team will have no objection, i guess
-<wsa> i have one periject topic but I want this last
-<wsa> marex: can you prepare a patch then?			        [17:05]
-<marex> shimoday: do you happen to have customers that might need L1 link
-	states ?
-<marex> for whatever reason
-<moriperi> geertu: sorry for my late response. Haha :) it is interesting way
-	   to increase for me :)				        [17:06]
-<geertu> marex: It's the same/similar one as
-	 https://lore.kernel.org/linux-pci/CAMuHMdX_ksY_AnaGyL0Z4HjUv72ndRM7XsRHkSKaBP7J-xmN1A@mail.gmail.com/
-								        [17:08]
-<marex> geertu: makes me wonder whether the spinlock in atf doesn't quite
-	lock, uh						        [17:09]
-<geertu> marex: oh right, could be a bug in atf ;-)
-<marex> the entire gen3 L1->L0 code should be serialized
-<geertu> or better :-(
-<marex> hopefully not in such fundamental primitives		        [17:10]
-<shimoday> marex: hmm, it's a difficut thing. I don't have any idea how way is
-	   better for now...
-<wsa> I guess, at least for upstream, we should disable L1	        [17:12]
-<wsa> BSP team then can decide if they want to pick it
-<wsa> so, for my periject topic					        [17:13]
-<shimoday> wsa: i agree
-<marex> wsa: I guess we have no other options anyway
-<wsa> let's wake some MM members first: kbingham[m] jmondi pinchartl neg :)
-<marex> and if BSP team needs the patch, it was posted		        [17:14]
-<kbingham> wsa, Hey I felt that
-<kbingham> :-)
-<wsa> some ppl said they want to add patches to the new "non-target" list
-<wsa> kbingham: good \o/
-<neg> zZzZ ;-)							        [17:15]
-<wsa> I propose that we add the reason in brackets '()' for now
-<wsa> Otherwise we start looking at the same patches again for patches which
-      won't make it upstream but are still kept in the BSP	        [17:16]
-<wsa> I couldn't think of a better way to maintain this information for now
-<wsa> (please shoot if you can think of one)
-<shimoday> g							        [17:17]
-<shimoday> sorry, my dauther typed this 'g' ;)
-<geertu> wsa: You mean like
-<geertu> + - d8c1fb49de142298c345bd112fbad2b26cac9013 # arm64: dts: r8a77990:
-	 Change IPMMU-MM and IPMMU-caches order in DT (These are provisional
-	 patches. Please refer to https
-	 //patchwork.kernel.org/patch/10157459/)
-<wsa> It needed some yes
-<wsa> argh
-<wsa> yes
-<geertu> shimoday: Good. next important keys are "e", "e", "r", and "t" ;-)
-								        [17:18]
-<wsa> It needed some AWK scripts to port this information from good old
-      periupport, but it moved quite some patches away
-<pinchartl> wsa: I don't wake up before 11:00 :-)
-<shimoday> geertu: :)						        [17:19]
-<wsa> pinchartl: This is why we discuss all important things before 11:00 ;)
-<geertu> wsa: What exactly do you mean by "add patches ... to the list"?
-<kbingham> is this for understanding why patches are rejected too?      [17:20]
-<wsa> geertu: basically, if you add an entry to the non-target list
-<kbingham> in MM, we have rejected patches in the past, but of course BSP team
-	   still 'need/want' them, so they are there again in this latest bsp
-	   ticket.
-<geertu> wsa: patched moved from upport request, or also for random other
-	 patches we discover in the bsp?
-<wsa> kbingham: Right. And sometimes for years, so it may be forgotten if this
-      could be upported or was already rejected.		        [17:22]
-<wsa> I had this with some RAVB patches which Simon back then already tried
-      upstreaming but they were rejected upstream
-<shimoday> kbingham: sorry for lack information. the current bsp-41x list is
-	   from just the bsp, not thier want/need because
-<wsa> But I had to find this out digging through mail threads
-<shimoday> they are busy to make such "need/want" list for bsp-410...
-<shimoday> so, we need re-reject such patches again		        [17:23]
-<geertu> shimoday: Do they also plan to take our comments into account? E.g.
-								        [17:24]
-<geertu> spi: sh-msiof: Add MSIOF module clock changing processing for R-Car
-	 Gen3 (Proposing 'N'  Should use "assigned-clocks" and
-	 "assigned-clock-rates" in board DTS file that actually uses MSIOF)
-<wsa> and to avoid digging through old mails, I'd like to collect the
-      information somehow
-<wsa> geertu: that might be another benefit			        [17:25]
-<geertu> wsa: OK, I'll update the recent changes I made to
-	 bsp-41x-non-target.yaml
-<wsa> It may not be the best format; I guess updating from one BSP list to the
-      next one is probably still some strange scripting		        [17:26]
-<shimoday> geertu: what is "into account" mean?
-* jmondi catches up with the discussion
-<wsa> but as people want to start filling the "non-target" list, it might be a
-      start at least
-<geertu> shimoday: replace the BSP way by the suggestion in the comment
-<jmondi> wsa: geertu: was the sweep you made to the ticket a manual process or
-	 do you have scripts that identify patches that were rejected and
-	 re-purposed in the new ticket ?			        [17:27]
-<geertu> jmondi: the one marked (patch-id) and (summary) where done by some
-	 half-baked scripting					        [17:28]
-<wsa> jmondi: for porting the comments from periupport, I wrote scripts to
-      identify patches based on $subject
-<geertu> run "git path-id --stable" and "git log --oneline" on all commits
-	 upstream and in the BSP, and look for matches
-<geertu> s/path-id/patch-id/					        [17:29]
-<geertu> s/where/were/
-<jmondi> wsa: geert: I see, everyone has its own method it seems        [17:30]
-<geertu> jmondi: It was similar to what I do for my regular "Auto-update
-	 sweep", which considers patch-id and lore link
-<wsa> jmondi: well, the port from periupport is done now	        [17:31]
-<wsa> now it is about porting from one bsp-list to the next
-<jmondi> yeah sure, I was thinking about moving to one BSP list to anther, and
-	 mostly for future tickets
-<jmondi> anyway, thanks, it's not a huge number of patches, and some scripting
-	 + some manual verification should do			        [17:32]
-<wsa> hopefully so
-<wsa> when backporting upstream patches, BSP team adds lines like
-      "cherry-picked from: ..." to the description		        [17:33]
-<wsa> that would be nice for cherry-picking old BSP patches, too, I'd think
-								        [17:34]
-<wsa> if the BSP team is up for it
-<wsa> that said, matching on $subject worked quite well
-<wsa> OK, I think we can close this now?			        [17:35]
-<wsa> and move to core?
-<jmondi> wsa: so we can match on the 'cherry-picked from' ?
-<geertu> wsa: Indeed, Shimoda-san did that in 4d75bd75ef222375 ("linux:
-	 bsp-41x: Move cherry picked commits to non target")
-<jmondi> between tickets I mean
-<wsa> jmondi: yes
-<geertu> jmondi: If the cherry-picked points to a commit in upstream or
-	 stable.
-<geertu> I.e. if "git tag --contains <sha1> v5.11" prints v5.11	        [17:36]
-<geertu> (stable needs more checks, as there are more trees)	        [17:37]
-<jmondi> oh I thought wolfram was suggesting, in case the patch has not been
-	 upstreamed, to point to the commit id in the previous bsp ticket
-<jmondi> so we can easy get to the status assigned to the patch in the
-	 previous ticket					        [17:38]
-<geertu> Oops, I missed that detail
-<jmondi> anyway, please move to core, I don't want to continue interrupting
-	 the meeting
-<geertu> So yes, then we have to look at what cherry-picked points to for
-	 sure!
-<wsa> geertu: ready?						        [17:39]
-<geertu> wsa: it can point to a commit in upstream, stable, or another BSP
-	 version.
-<wsa> geertu: right						        [17:40]
-<geertu> I believe a new BSP is created by rebasing, not by cherry-picking?
-	 (yes, technically, it's the same)
-<wsa> I wouldn't want to solely rely on "cherry-picked from" anyhow     [17:42]
-<geertu> agreed
-<wsa> It is nice if the BSP teams helps
-<wsa> but we should be able to act independently from that IMO	        [17:43]
-<wsa> so, core now?						        [17:44]
+09:02 < wsa> so, welcome to the io meeting and here are the status updates:
+09:02 < jmondi> 'morning everyone
+09:02 -!- damm [~damm@l193216.ppp.asahi-net.or.jp] has joined #periperi
+09:02 < wsa> A - what have I done since last time
+09:02 < wsa> ------------------------------------
+09:02 < wsa> Geert
+09:02 < wsa> : fixed PHY Runtime PM in SH-ETH and related improvements for SMSC911X, added Falcon I2C EEPROM support
+09:02 < wsa> Niklas
+09:02 < wsa> : resent Gen3 timer patches, discussed V3U timer support
+09:02 < wsa> Shimoda-san
+09:02 < wsa> : added mmc aliases to Gen2/3 board files, investigated RPC-IF driver issues with BSP team, got some information about Gen3e
+09:02 < wsa> Ulrich
+09:02 < wsa> : sent atomic xfer support for i2c-rcar
+09:02 < wsa> Wolfram
+09:02 < wsa> : upstreamed V3U support for WDT, I2C, AVB0, SDHI, (H)SCIF for 5.12, investigated issues of AVB1-5 and RPC-IF on the V3U Falcon board, sent I2C core preparations for extended RECV_LEN sizes, improved I2C testunit with RECV_LEN testcase, moved already rejected patches from new BSP list to the non-target list, enabled WAIT_WHILE_BUSY and removed NON_REMOVABLE workaround for SDHI
+09:02 < wsa> B - what I want to do until next time
+09:02 < wsa> -------------------------------------
+09:02 < wsa> Geert
+09:02 < wsa> : wants to revise Falcon I2C EEPROM support
+09:02 < wsa> Niklas
+09:02 < wsa> : wants to figure out number of TSC nodes on V3U
+09:02 < wsa> Shimoda-san
+09:02 < wsa> : wants to continue to investigate SDHI driver's issues, collect more information about R-Car Gen3e, continue to develop R-Car S4 Ethernet driver
+09:02 < wsa> Wolfram
+09:02 < wsa> : wants to pick up "logic analyzer via isolated CPU" work again, upstream CMT and TMU support for V3U, continue with extended RECV_LEN and its R-Car support, keep working on SDHI issues
+09:02 < wsa> C - problems I currently have
+09:02 < wsa> -----------------------------
+09:02 < wsa> None reported.
+09:03 < wsa> uli__: is this audio task a big one? Because I wanted to talk about a (hopefully) small RAVB task and am curious when I can get back to you?
+09:03 < uli__> that's not a problem
+09:04 < wsa> marex: what can we do to push the PCI L1 issue? Resend the patch?
+09:05 < marex> wsa: probably disable L1 altogether
+09:05 < wsa> uli__: okay. so, i'll send you a mail with the details later.
+09:05 < marex> wsa: and if someone needs it in the BSP, then there can be a downstream BSP patch which enables it for special cases where it might work OK
+09:05 < wsa> unconditionally? or just for some devices?
+09:05 < uli__> ok, thx
+09:06 < marex> wsa: but it seems for the generic case, which maintainers seems to care about, L1 is unusable
+09:07 < wsa> caring for the generic case sounds OK to me
+09:07 < wsa> so we should disable it?
+09:07 < marex> the question is whether it is OK to just disable L1 altogether
+09:07 < marex> right
+09:07 < marex> I guess we are out of options anyway
+09:08 < geertu> FTR, I got the interupt crash during PCIe resume on M3-W again earlier this week
+09:08 < wsa> shimoday: do you want to discuss this with the BSP team?
+09:08 < marex> geertu: with what PCIe card and on which CPU core ?
+09:08 < geertu> As it's not easy to reproduce, it might be hard to see if disabling L1 helps
+09:09 < wsa> shimoday: if we should disable L1 on PCIe upstream because that's what the maintainers prefer
+09:09 < wsa> geertu: neg: thanks for testing the SDHI workaround removal patch. Much appreciated!
+09:10 < geertu> marex: e1000e: Intel(R) PRO/1000 Network Driver
+09:10 < neg> I'm happy to see that quirk gone ;-)
+09:10 < wsa> neg: hopefully it will stay "gone" this time
+09:11 < marex> wsa: BSP team can keep the patch which handles the link resume
+09:11 < geertu> marex: No idea which CPU core
+09:11 < marex> wsa: although maybe it is just safer to turn off the L1 states in the BSP too
+09:11 < marex> geertu: do you have the backtrace ?
+09:12 < wsa> marex: exactly, maybe they want to support the generic case, too ;)
+09:12 < wsa> okay, are there questions / comments from your side?
+09:13 < shimoday> wsa: i think we don't need to discus with BSP team because it's the maintainers prefer so BSP team will have no objection, i guess
+09:13 < wsa> i have one periject topic but I want this last
+09:13 < wsa> marex: can you prepare a patch then?
+09:13 < marex> shimoday: do you happen to have customers that might need L1 link states ?
+09:13 < marex> for whatever reason
+09:14 < moriperi> geertu: sorry for my late response. Haha :) it is interesting way to increase for me :)
+09:16 < geertu> marex: It's the same/similar one as https://lore.kernel.org/linux-pci/CAMuHMdX_ksY_AnaGyL0Z4HjUv72ndRM7XsRHkSKaBP7J-xmN1A@mail.gmail.com/
+09:17 < marex> geertu: makes me wonder whether the spinlock in atf doesn't quite lock, uh
+09:17 < geertu> marex: oh right, could be a bug in atf ;-)
+09:17 < marex> the entire gen3 L1->L0 code should be serialized
+09:17 < geertu> or better :-(
+09:18 < marex> hopefully not in such fundamental primitives
+09:19 < shimoday> marex: hmm, it's a difficut thing. I don't have any idea how way is better for now...
+09:20 < wsa> I guess, at least for upstream, we should disable L1
+09:20 < wsa> BSP team then can decide if they want to pick it
+09:21 < wsa> so, for my periject topic
+09:21 < shimoday> wsa: i agree
+09:22 < marex> wsa: I guess we have no other options anyway
+09:22 < wsa> let's wake some MM members first: kbingham[m] jmondi pinchartl neg :)
+09:22 < marex> and if BSP team needs the patch, it was posted
+09:22 <@kbingham> wsa, Hey I felt that
+09:22 <@kbingham> :-)
+09:23 < wsa> some ppl said they want to add patches to the new "non-target" list
+09:23 < wsa> kbingham: good \o/
+09:23 < neg> zZzZ ;-)
+09:23 < wsa> I propose that we add the reason in brackets '()' for now
+09:24 < wsa> Otherwise we start looking at the same patches again for patches which won't make it upstream but are still kept in the BSP
+09:24 < wsa> I couldn't think of a better way to maintain this information for now
+09:25 < wsa> (please shoot if you can think of one)
+09:25 < shimoday> g
+09:25 < shimoday> sorry, my dauther typed this 'g' ;)
+09:25 < geertu> wsa: You mean like
+09:25 < geertu> + - d8c1fb49de142298c345bd112fbad2b26cac9013 # arm64: dts: r8a77990: Change IPMMU-MM and IPMMU-caches order in DT (These are provisional patches. Please refer to https //patchwork.kernel.org/patch/10157459/)
+09:26 < wsa> It needed some yes
+09:26 < wsa> argh
+09:26 < wsa> yes
+09:26 < geertu> shimoday: Good. next important keys are "e", "e", "r", and "t" ;-)
+09:26 < wsa> It needed some AWK scripts to port this information from good old periupport, but it moved quite some patches away
+09:26 < pinchartl> wsa: I don't wake up before 11:00 :-)
+09:27 < shimoday> geertu: :)
+09:27 < wsa> pinchartl: This is why we discuss all important things before 11:00 ;)
+09:27 < geertu> wsa: What exactly do you mean by "add patches ... to the list"?
+09:28 <@kbingham> is this for understanding why patches are rejected too?
+09:28 < wsa> geertu: basically, if you add an entry to the non-target list
+09:28 <@kbingham> in MM, we have rejected patches in the past, but of course BSP team still 'need/want' them, so they are there again in this latest bsp ticket.
+09:28 < geertu> wsa: patched moved from upport request, or also for random other patches we discover in the bsp?
+09:30 < wsa> kbingham: Right. And sometimes for years, so it may be forgotten if this could be upported or was already rejected.
+09:30 < wsa> I had this with some RAVB patches which Simon back then already tried upstreaming but they were rejected upstream
+09:30 < shimoday> kbingham: sorry for lack information. the current bsp-41x list is from just the bsp, not thier want/need because
+09:31 < wsa> But I had to find this out digging through mail threads
+09:31 < shimoday> they are busy to make such "need/want" list for bsp-410...
+09:31 < shimoday> so, we need re-reject such patches again
+09:32 < geertu> shimoday: Do they also plan to take our comments into account? E.g.
+09:32 < geertu> spi: sh-msiof: Add MSIOF module clock changing processing for R-Car Gen3 (Proposing 'N'  Should use "assigned-clocks" and "assigned-clock-rates" in board DTS file that actually uses MSIOF)
+09:32 < wsa> and to avoid digging through old mails, I'd like to collect the information somehow
+09:33 < wsa> geertu: that might be another benefit
+09:33 < geertu> wsa: OK, I'll update the recent changes I made to bsp-41x-non-target.yaml
+09:34 < wsa> It may not be the best format; I guess updating from one BSP list to the next one is probably still some strange scripting
+09:34 < shimoday> geertu: what is "into account" mean?
+09:34  * jmondi catches up with the discussion
+09:34 < wsa> but as people want to start filling the "non-target" list, it might be a start at least
+09:35 < geertu> shimoday: replace the BSP way by the suggestion in the comment
+09:35 < jmondi> wsa: geertu: was the sweep you made to the ticket a manual process or do you have scripts that identify patches that were rejected and re-purposed in the new ticket ?
+09:36 < geertu> jmondi: the one marked (patch-id) and (summary) where done by some half-baked scripting
+09:36 < wsa> jmondi: for porting the comments from periupport, I wrote scripts to identify patches based on $subject
+09:37 < geertu> run "git path-id --stable" and "git log --oneline" on all commits upstream and in the BSP, and look for matches
+09:37 < geertu> s/path-id/patch-id/
+09:37 < geertu> s/where/were/
+09:38 < jmondi> wsa: geert: I see, everyone has its own method it seems
+09:38 < geertu> jmondi: It was similar to what I do for my regular "Auto-update sweep", which considers patch-id and lore link
+09:39 < wsa> jmondi: well, the port from periupport is done now
+09:39 < wsa> now it is about porting from one bsp-list to the next
+09:39 < jmondi> yeah sure, I was thinking about moving to one BSP list to anther, and mostly for future tickets
+09:40 < jmondi> anyway, thanks, it's not a huge number of patches, and some scripting + some manual verification should do
+09:41 < wsa> hopefully so
+09:41 < wsa> when backporting upstream patches, BSP team adds lines like "cherry-picked from: ..." to the description
+09:42 < wsa> that would be nice for cherry-picking old BSP patches, too, I'd think
+09:42 < wsa> if the BSP team is up for it
+09:43 < wsa> that said, matching on $subject worked quite well
+09:43 < wsa> OK, I think we can close this now?
+09:43 < wsa> and move to core?
+09:43 < jmondi> wsa: so we can match on the 'cherry-picked from' ?
+09:43 < geertu> wsa: Indeed, Shimoda-san did that in 4d75bd75ef222375 ("linux: bsp-41x: Move cherry picked commits to non target")
+09:43 < jmondi> between tickets I mean
+09:43 < wsa> jmondi: yes
+09:44 < geertu> jmondi: If the cherry-picked points to a commit in upstream or stable.
+09:45 < geertu> I.e. if "git tag --contains <sha1> v5.11" prints v5.11
+09:45 < geertu> (stable needs more checks, as there are more trees)
+09:45 < jmondi> oh I thought wolfram was suggesting, in case the patch has not been upstreamed, to point to the commit id in the previous bsp ticket
+09:46 < jmondi> so we can easy get to the status assigned to the patch in the previous ticket
+09:46 < geertu> Oops, I missed that detail
+09:46 < jmondi> anyway, please move to core, I don't want to continue interrupting the meeting
+09:46 < geertu> So yes, then we have to look at what cherry-picked points to for sure!
+09:47 < wsa> geertu: ready?
+09:47 < geertu> wsa: it can point to a commit in upstream, stable, or another BSP version.
+09:48 < wsa> geertu: right
+09:48 < geertu> I believe a new BSP is created by rebasing, not by cherry-picking? (yes, technically, it's the same)
+09:50 < wsa> I wouldn't want to solely rely on "cherry-picked from" anyhow
+09:50 < geertu> agreed
+09:50 < wsa> It is nice if the BSP teams helps
+09:51 < wsa> but we should be able to act independently from that IMO
+09:52 < wsa> so, core now?
+09:53 < geertu> yes! (I/O was going to be short ;-)