01:08 <konradybcio> marc|gonzalez: you're lucky to have landed on the last major soc that was released before a major hardware cleanup..

01:47 <amazingfate> lumag: Hi, I've been working on armbian for xiaomi pad5 pro(sm8250), which need qbootctl package. I find this package from debian is packaged by you, and there is a bug of it causing systemd service can't start:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057918. And I have created a fix for it: https://salsa.debian.org/lumag/qbootctl/-/merge_requests/2. Would you mind merging it so that armbian can use debian trixie's packged qbootctl

01:47 <amazingfate> instead of using a patching one?

01:49 <lumag> amazingfate, merged, I'll work on uploading it today or tomorrow.

01:50 <amazingfate> lumag: thank you very much!

09:09 <marc|gonzalez> konradybcio: I am not in a position to appreciate the luck you speak of. If you're saying it could be worse, I say emoji_of_munch.

12:06 <konradybcio> marc|gonzalez: yes, it could have been much worse

12:07 <konradybcio> the previous 2 platforms in turn, have permanent stability issues

12:13 <marc|gonzalez> 8996 ?

12:14 <marc|gonzalez> Because of HW issues or because one or several Linux frameworks is/are not appropriate for supporting the HW?

12:39 <konradybcio> 1 implies 2

12:39 <konradybcio> it was a cool design, but not very polished..

12:39 <konradybcio> would have probably much better if much of the ugly parts were abstracted away by the firmware

14:00 <marc|gonzalez> I used to worked for a SoC vendor. PCIe HC had a bit to mux accesses between config space & regular space.

14:01 <marc|gonzalez> In the HW dev's mind, there was a single thread accessing PCIe bus, and there would be some kind of mutex to access either config space OR regular space. Never both at the same time.

14:02 <marc|gonzalez> This did not work well (at all) in Linux. (One might argue that it wouldn't work well in any OS)

14:02 <marc|gonzalez> But I suppose it could work for a µ-kernel

14:03 <marc|gonzalez> anyway

14:03 <marc|gonzalez> bamse: will you take patches 1 & 2 of [PATCH v4 0/3] Add support for qcom msm8998-venus (HW vdec / venc) ?

14:50 <lumag> marc|gonzalez, patch 1 should go through media

14:50 <lumag> (as well as patch 3)

14:57 <bamse> marc|gonzalez: it would be nice if you include a link to lore.kernel.org (or at least a message-id)

14:58 <marc|gonzalez> bamse: will look it up OK

14:59 <marc|gonzalez> lumag: Does Stanimir have a tree? A few years ago, I waited 18 months for Mauro to review one of my patches...

15:00 <marc|gonzalez> bamse: https://patchwork.kernel.org/project/linux-media/patch/c2fca6c7-2421-42b4-a43d-68b251daf9b4@freebox.fr/

15:00 <bamse> found it... as lumag says, patch 1 and 3 relates to the driver, so those should go through the driver tree

15:01 <marc|gonzalez> makes sense

15:01 <marc|gonzalez> Then patch 2 alone

15:02 <bamse> i will merge that once the devicetree binding has been picked up by the maintainer...

15:03 <marc|gonzalez> upside down face

15:03 <bamse> but it seems Mauro is the maintainer who would pick this, and he's not among the recipients of the patches...or am i just failing to read?

15:03 <marc|gonzalez> He's not in the original To: but I added media, and later pinged him

15:04 <marc|gonzalez> I don't understand how 1 maintainer can shepherd 5 gazillion device drivers

15:04 <bamse> marc|gonzalez: pick up the acks you received, swap order of patch 2 and 3 (so the dts comes last) and send out v5 with the recipients as per get_maintainer

15:05 <marc|gonzalez> I don't understand this order of patches stuff

15:05 <bamse> marc|gonzalez: he shepherd them by the help of those reviewed-by and acked-by received from people with more detailed knowledge about the particular driver

15:06 <marc|gonzalez> Why would the binding come last?

15:06 <marc|gonzalez> Binding is the first thing required

15:06 <bamse> no, binding first, then driver, then dts

15:06 <marc|gonzalez> Oh, that makes more sense, OK

15:06 <bamse> that's why i said "swap 2 and 3" :)

15:06 <marc|gonzalez> I guess my mind just froze when you wrote "send another version"

15:07 <marc|gonzalez> I understand the stress on maintainers, I do. But OMG, I wanna bash my head against a wall until it's red & gray

15:17 <lumag> marc|gonzalez, it really makes life of a maintainer easier

15:18 <marc|gonzalez> lumag: what does? :) Getting the details right? I suppose that's true in all walks of life ;)

15:19 <lumag> Even ordering the patches.

15:20 <marc|gonzalez> I don't know why I find the whole process so frustrating, it should just be "make the change, increment patch version, hit a button"

15:21 <marc|gonzalez> probably because I find git send-email so intimidating

15:22 <marc|gonzalez> Also, I'd still be happy to get 3 rounds on a ring with Linus some day

15:22 <javierm> marc|gonzalez: are you familiar with b4 or patman? Make the whole process less frustrating

15:22 <marc|gonzalez> javierm: I am not!

15:22 <marc|gonzalez> which one do you recommend?

15:24 <javierm> marc|gonzalez: I use patman (https://docs.u-boot.org/en/stable/develop/patman.html) but b4 (https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1) seems to be popular these days

15:25 <marc|gonzalez> Just a few weeks ago, narmstrong had a weird b4 bug on one of the mailing lists... But I suppose I should have a look

15:25 <marc|gonzalez> thanks for the pointer

15:26 <javierm> marc|gonzalez: patman is awesome and I've been using it for a decade now :)

15:26 <lumag> marc|gonzalez, I've switched to b4. It made my life easier.

15:26 <marc|gonzalez> I've been doing everything by hand

15:28 <javierm> lumag: I've meaning to look at b4 but it seems I'm too old to change my workflow :D

15:28 <javierm> but yes, I only heard good things about b4

15:32 <marc|gonzalez> b4 there was nothing, then someone said let there be light

15:39 <lumag> javierm, judging by your graduation dates, we should be of the same age. you can't be too old.

15:40 <marc|gonzalez> Age Is Just a Number — That Keeps Going Up

15:44 <phh> so a monotonic counter

15:45 <javierm> lumag: yeah, I was partially joking. I've in my TODO to switch to b4 but is low prio in the list

15:46 <lumag> :-D

15:47 <javierm> lumag: I'm a happy camper with patman though, so I first to understand what value b4 would bring to my workflow

15:47 <javierm> *first need to

15:47 <aka_[m]> <marc|gonzalez> "Age Is Just a Number — That..." <- thats right officer

15:47 <lumag> I haven't looked at patman. It definitely was an improvement over raw git-send-email & scripts that I was using beforehand

15:47 <javierm> lumag: I've a presentation from dianders in my queue but again is hidden on top of another 100's videos

15:48 <narmstrong> I saw it live at eoss and I still prefer patman

15:48 <lumag> The important point for me was that it solved handling of to/cc lists and me forgetting to include / update a cover letter

15:48 <javierm> narmstrong: ah! interesting

15:48 <javierm> https://www.youtube.com/watch?v=7B3nKmBoFoQ is the talk from Doug btw

15:48 <narmstrong> Sorry I still prefer b4

15:49 <javierm> narmstrong: oh, plot twist :P

15:49 <narmstrong> Yeah patman is more about tracking per patches changes and per patches cc/to

15:49 <marc|gonzalez> No, wait, patman!

15:49 <marc|gonzalez> Who doesn't love pacman, anyway...

15:49 <narmstrong> Perhaps it’s better for treewide changes

15:49 <narmstrong> And for sure is more adapted to uboot process

15:50 <narmstrong> B4 filled 110% of my workflow…

15:50 <javierm> narmstrong: I've been using it for any project that uses a send-patch-by-email workflow

15:51 <javierm> but my gut feeling is that both tools are quite similar

15:52 <dianders> LOL. Both tools are good. I'm not giving up patman at the moment, but there are some b4 things that I wish I had. Maybe one day I'll try to add some of the patman feature to b4, or maybe someone else will. ;-)

15:52 <narmstrong> javierm: as doug said, they are very close, but b4 is part of lore/lei toolchain and would be useless for projects not tracked using public inbox

15:53 <narmstrong> dianders: definitely adding lore url support would be a game changer

15:54 <dianders> narmstrong: you mean having it add the link to the previous versions of the patches, or something else?

15:55 <javierm> dianders: I'm a member of the Patman Evangelism Strike Force :D

15:55 <narmstrong> And the signature added by b4 is also very important when Google does dkim key rotations

15:55 <narmstrong> dianders: yes for example, but b4 can also apply any lore patchset and check the signature

16:03 <bamse> marc|gonzalez: you resending it about the same effort on your side as getting this patch infront of Mauro...and assuming that Mauro has a convenient flow to merge patches, you reduce his burden from X to close to 0...

16:04 <bamse> marc|gonzalez: and as was suggested above, https://b4.docs.kernel.org/en/latest/contributor/overview.html removes pretty much all the effort on your side

16:05 <marc|gonzalez> bamse: will look into it. But as mentioned, issue is not the resend operation per se, rather the weeks of silence then "oh you forgot this one thing"

16:05 <marc|gonzalez> As I mentioned, I had one patch series (very cool IMHO) for Mauro, which was ignored for 18 months

16:06 <marc|gonzalez> when he finally got to it, I had moved on, and on, and on, like the Energizer bunny

16:06 <bamse> marc|gonzalez: well, if you don't send the patches to the maintainer, then it's reasonable to assume the maintainer perhaps won't pick the patches... but i'm not familiar with Mauro's workflow

16:06 <marc|gonzalez> bamse: in this circumstance, I had assumed that a subdir maintainer would pick it up

16:07 <marc|gonzalez> and incorrectly left Mauro out of the process, based on my previous interaction

16:07 <bamse> yeah, that process differs from area to area...

16:07 <bamse> makes sense...

16:07 <marc|gonzalez> It makes no sense to me to have a single dude be in charge of 5 gazillion disparate gizmos

16:08 <marc|gonzalez> I understand that he could be under water

16:08 <bamse> and tbh as a maintainer, the number of To: and Cc: is prohibitive, so in my case it doesn't really matter...

16:08 <marc|gonzalez> For this resend, I'm letting git send-email do its thing

16:09 <bamse> marc|gonzalez: but that's why it's important to review patches, to remvoe the need for the maintainer to review and be deeply familiar with each piece in their area

16:12 <krzk> I have a template answer which could work here (based on Greg's one), lemme paste:

16:12 <marc|gonzalez> I expected the solution would be divide & conquer, so having maintainers of drivers/media/platform/qcom feed their tree to Mauro

16:12 <krzk> "Please relax, and help out by reviewing other patches on the mailing lists in order to relieve the burden of maintainers and move your patches higher up the list."

16:13 <marc|gonzalez> Yeah I'll relax when I'm dead, and then again, maybe not

16:13 <krzk> although media had serious troubles last 2 years with patch flow, but mostly because of huge numbers and limited capacity. They grew with more maintainers recently, so hopefully it will improve, but above suggestion about help in reviewing is always good.

16:14 <marc|gonzalez> krzk: what is the difference between Reviewer & Maintainer (in media) ?

16:14 <marc|gonzalez> I thought Reviewers would give "Reviewed-by" & Maintainers would merge to their trees

16:14 <marc|gonzalez> but in media, maintainers don't maintain a tree?

16:16 <marc|gonzalez> Sean & Hans have trees (I think)

16:20 <krzk> marc|gonzalez: the same as in other subsystem trees - maintainer and co-maintainers take care about that tree. They might or might not have commit rights (or might have backup-commit rights).

16:21 <krzk> so in that case Sakari could look like more as a Reviewer. The same as me or Conor for DT. However the distinction here is responsibility and total weight of ack/nack/opinion.

16:21 <krzk> Simplifying you could think that reviewer helps, but maintainer decides (even if does not pick up patches).

16:23 <krzk> btw, media or DT is not odd here. netdev has similar rules, many other SoC trees as well (qcom...).

16:27 <marc|gonzalez> I don't understand why media would have so many maintainers, but ultimately everything must be reviewed by one person

16:28 <bamse> marc|gonzalez: no, all patches are reviewed by anyone...the maintainer can then through trust determine how much additional review is needed

16:29 <marc|gonzalez> bamse: but he must review the tags for 1000 patches every month

16:29 <bamse> marc|gonzalez: case in point, i expect Vikash knows the media pieces...so i should only have to review the dts patch from a upstream-style point of view...

16:38 <marc|gonzalez> the problem with git send-email is that the automated to & cc lookup only takes a single patch at a time into account, right?

16:38 <marc|gonzalez> I imagine that's one thing improved by b'?

16:38 <marc|gonzalez> b4

18:08 <abhinav__> krzk Hi, can you pls explain to me about the question I asked on https://patchwork.freedesktop.org/patch/594685/#comment_1086895 ... myself and lumag would like to understand this a little better because TE pin has so far not been encountered upstream because noone supported MIPI command mode display which can have different TE pins

20:12 <bamse> marc|gonzalez: hmm, my memory might be failing me, but i didn't think git-send-email did any recipient lookup (except for pulling things out of the commit message)

20:13 <bamse> marc|gonzalez: and it does that per patch

20:13 <bamse> marc|gonzalez: with by you associated (by running b4 prep --auto-to-cc) recipients for the whole series beforehand, and when you invoke b4 send it send to exactly those recipients

20:14 <bamse> marc|gonzalez: and when then call b4 send next time, it will have incremented the version number, and will send to exactly the same people (unless you changed the list)