12:48 <mraynal1> krzk: Hello, regarding the series "Prevent NAND chip unevaluated properties", I'm not sure I can apply it on my tree, if yes I'd like to do it soon, but your answer was not very clear so I wanted to double check first.

12:56 <krzk> mraynal1: sorry, I don't recognize the series

12:57 <krzk> mraynal1: I don't have anything in my inbox from you

12:59 <krzk> but just in case you missed discussion about OoO of lag and cc-ing wrong address - are you sure you are Ccing correct address?

13:06 <mraynal1> krzk: I had the old address hardcoded on my side, I corrected it after you mentioned it

13:08 <mraynal1> krzk: I answered to your remark there, but maybe I should have added the other address in Cc -> https://lore.kernel.org/linux-mtd/20230615102609.0aeea6ab@xps-13/

13:08 <mraynal1> anyhow, just let me know what you prefer between (i) I apply the series, (ii) you apply the series, (iii) i re-send and we'll see later

13:17 <mraynal1> btw. I expect everybody to take vacations and enjoy them, so I will always wait for you/robh to be back and catch up at your own pace :)

13:50 <krzk> don't hard-code addresses, but take them from maintainers.pl. Every time. You also skipped other maintainer(s?).

13:55 <mraynal1> I personally don't trust maintainers.pl, I always use it to check who I should Cc but then I create the Cc line using git_aliases for people I am used to reach

13:56 <mraynal1> It's extremely handy but the downside, it's true, I may sometimes overlook address changes

13:56 <krzk> mraynal1: ok, whatever method produces correct output. Since the output is not correct, method has issues.

14:00 <geertu> krzk: let's ask ChatGPT for the list of maintainers to CC ;-)

14:02 <mraynal1> geertu::-)

14:03 <jn> lets put chatgpt on the CC list ;p

14:04 <mraynal1> geertu: btw, talking about maintainers.pl holes, I was not paying attention enough a few minutes ago when I used it (once again) and I forgot to Cc you on a CAN series, there is a bug which we discovered on RZN1 CAN controller

14:04 <mraynal1> geertu: just in case you wanna have a look -> https://lore.kernel.org/netdev/20230616134553.2786391-1-miquel.raynal@bootlin.com/T/#m42f7512c35e529a1c2704542e9ffd31b025d8fc7

14:10 <conchuod> krzk: you seem to find someone every 2 days that is CCing the wrong email for you

14:16 <krzk> conchuod: every 2 days I find someone skipping DT list or skipping me entirely :)

14:16 <krzk> Ccing wrong email is I think now rarer... people prefer to skip me :)

14:16 <conchuod> That just means the kernel they have is even older..

14:18 <krzk> conchuod: or their process is broken. I am advocating for this simple stuff https://github.com/krzk/tools/blob/master/linux/.bash_aliases_linux#L91 since some time (or use Rob's proposed sendemail.linux gitconfig entry but then get_maintainer.pl is per patch - anyway also would work)

14:19 <geertu> mraynal1: thx!

14:20 <krzk> With simple trick one cann make the problem not existing but no! Better to have problems and then you get HTML answer from lag's OoO (because change in August 2022 is just 10 months old, not enough)

14:21 <krzk> or cc my @canonical.com email... or not Cc people at all. "Processes" are not to annoy people (or should not be to annoy, but then of course we have governments...), but to make some problem disappear. Here the problem is - whom to Cc? solution - simple, every time use get_maintainers.pl and it will not be your problem.

14:22 <robmur01> We should make sure MAINTAINTERS updates get backported to the Android GKI branches that many companies are actually doing their work in :)

14:23 <krzk> robmur01: yes and no, because then we see someone is working on wrong tree :)

14:23 <geertu> krzk: I use a script that runs scripts/get_maintainers.pl, and turns its output into a bash script that calls git send-email. Then I edit the bash script manually (to remove/add people), and run it

14:23 <krzk> people should actually not work on GKI branch, ever.

14:23 <robmur01> but first we should make sure we can actually spell "maintainers"...

14:23 <krzk> geertu: also should work. The point is to automate it and don't care about actual addresses.

14:23 <geertu> robmur01: canned reply "is that reproducible on upstream?"

14:23 <conchuod> tbh krzk, I am just ignoring anything that doesn't go to the correct address

14:25 <robmur01> krzk: Indeed they should not. But the fact is that they do :/

14:26 <geertu> robmur01: So, what will the net effect? Real bugs fixed? Or maintainers overloaded with unusable reports and patches?

14:26 <geertu> s/will/will be/

14:31 <robmur01> geertu: often it's benign, because it's some driver of their own which hasn't changed much upstream in the meantime. Sometimes it's "fixes" for bugs which were already fixed 2 years ago, or where the code no longer even exists.

14:35 <krzk> I would day with limited time/resources of us or our employers, we need to allocate time carefully. Now if I suspect that bug could be real but also could be an effect of wrong base kernel (some out-of-tree Android patches or as robmur01 said something already fixed), I will choose to allocate my time to other bug/issue, the one without such risk.

14:35 <krzk> /day/say/

14:37 <rfs613> mraynal1: that CAN bug must have been fun to debug ;-)

14:38 <broonie> krzk: You shouldn't blindly trust get_maintainer output, it's got far too many false positives.

14:38 <krzk> There is another issue with wrong base. Drivers get improved over time. Developers write new drivers using old ones as a base, thus they won't have the fixes/improvements in their base.

14:39 <krzk> broonie: yeah, that's also true, but I think it is less harming than skipping maintainers and lists.

14:39 <Forty-Bot> *of the fiole

14:39 <broonie> My inbox would typically disagree with you on that one.

14:39 <robmur01> However I'd imagine that the spurious patches for old kernels are a lot less common than new drivers/bindings developed against old kernels, because the fact is that most new SoCs get brought up with Android, not mainline

14:39 <krzk> Forty-Bot: with proper script you won't get there. 1-commiters are not maintainers.

14:40 <Forty-Bot> typically I like to CC people who have worked on a file recently as well as the maintainers

14:40 <Forty-Bot> since they may often be more familiar with the code in question, especially for drivers without their own entry in MAINTAINERs

14:41 <broonie> Forty-Bot: That's one of the big issues with get_maintainer generating spam (no, I was just doing a random cleanup that doesn't mean I care about your 20 patch series that's going through endless bikeshedding or whatever)

14:41 <Forty-Bot> of course you can exclude 1-committers, but it's pretty easy to see 2- or 3-committers who are just doing cleanups on the subsystem

14:42 <krzk> broonie: so for the record - when we talk about automated output of get_maintainers.pl, we talk about --no-git --no-git-fallback arguments.

14:43 <krzk> and then you have just few bogus entries, because someone used "N:" keyword :) (but than it is his/hers fault)

14:44 <krzk> actually wait, not N:, K: leads to funny results

14:46 <Forty-Bot> personally, I adopt a "do unto others" approach when CCing people

14:46 <Forty-Bot> but if your inbox is already a firehose from maintaining DTs :)

16:12 <mraynal1> rfs613: yeah that one was tough, but luckily we managed to reproduce the issue with a fragile hardware wiring, which allowed more transfer errors at 1MHz and lead to an easy-to-reproduce bug.

16:12 <mraynal1> rfs613: but then, we were really surprised about how the controller was behaving :-)

16:13 <mraynal1> rfs613: zero load, buffer emptied, you send a single message from the other end and the controller errors out with an overrun. Surprising.

16:14 <rfs613> mraynal1: i was told the CAN bus doesn't work on the bestla board, something wrong with the hardware wiring. So we avoided testing it. But I did see the tickets from derived boards regarding the CAN bus getting stuck.

16:25 <mraynal1> rfs613: ah, interesting

16:26 <mraynal1> rfs613: for me it's a bug in the controller. I suspect the read_offset and write_offset to be desynchronized internally, hence the hardware thinks there is no free space

16:27 <mraynal1> rfs613: I also observe wrong frames when we are around these overrun situations, which makes me think the controller does not keep synchronized with the start/stop bits

16:28 <mraynal1> rfs613: I believe the controller derives the size of the message somehow and sometimes when flooded it uses stale data for that. I could observe something interesting: upon overruns, if we tell the controller that we unqueue several messages (even though the queue was already emptied by the right number of messages previously in there), the bug appears less often

16:28 <mraynal1> Like if playing with these internal offsets would make "something"

16:29 <mraynal1> But I could not find a reliable number of times we should do that, there is no valid indication that we can use, so I opted out for the safer approach: a software reset

17:01 <rfs613> mraynal1: they've had other "clock crossing" bugs in this SoC, so perhaps this is yet another variation on that

17:02 <mraynal1> rfs613: ok, might also make sense