ChanServ changed the topic of #linux-msm to:
<konradybcio> marc|gonzalez: you're lucky to have landed on the last major soc that was released before a major hardware cleanup..
amazingfate has joined #linux-msm
<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: And I have created a fix for it: Would you mind merging it so that armbian can use debian trixie's packged qbootctl
<amazingfate> instead of using a patching one?
<lumag> amazingfate, merged, I'll work on uploading it today or tomorrow.
<amazingfate> lumag: thank you very much!
amazingfate has quit [Quit: Leaving]
flto has quit [Remote host closed the connection]
flto has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
pespin has joined #linux-msm
pespin has quit []
pespin has joined #linux-msm
smpl has joined #linux-msm
jnn is now known as jn
<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.
sgerhold has joined #linux-msm
<konradybcio> marc|gonzalez: yes, it could have been much worse
<konradybcio> the previous 2 platforms in turn, have permanent stability issues
<marc|gonzalez> 8996 ?
<marc|gonzalez> Because of HW issues or because one or several Linux frameworks is/are not appropriate for supporting the HW?
<konradybcio> 1 implies 2
<konradybcio> it was a cool design, but not very polished..
<konradybcio> would have probably much better if much of the ugly parts were abstracted away by the firmware
<marc|gonzalez> I used to worked for a SoC vendor. PCIe HC had a bit to mux accesses between config space & regular space.
<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.
<marc|gonzalez> This did not work well (at all) in Linux. (One might argue that it wouldn't work well in any OS)
<marc|gonzalez> But I suppose it could work for a µ-kernel
<marc|gonzalez> anyway
<marc|gonzalez> bamse: will you take patches 1 & 2 of [PATCH v4 0/3] Add support for qcom msm8998-venus (HW vdec / venc) ?
<lumag> marc|gonzalez, patch 1 should go through media
<lumag> (as well as patch 3)
<bamse> marc|gonzalez: it would be nice if you include a link to (or at least a message-id)
<marc|gonzalez> bamse: will look it up OK
<marc|gonzalez> lumag: Does Stanimir have a tree? A few years ago, I waited 18 months for Mauro to review one of my patches...
<bamse> found it... as lumag says, patch 1 and 3 relates to the driver, so those should go through the driver tree
<marc|gonzalez> makes sense
<marc|gonzalez> Then patch 2 alone
<bamse> i will merge that once the devicetree binding has been picked up by the maintainer...
<marc|gonzalez> upside down face
<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?
<marc|gonzalez> He's not in the original To: but I added media, and later pinged him
<marc|gonzalez> I don't understand how 1 maintainer can shepherd 5 gazillion device drivers
<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
<marc|gonzalez> I don't understand this order of patches stuff
<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
<marc|gonzalez> Why would the binding come last?
<marc|gonzalez> Binding is the first thing required
<bamse> no, binding first, then driver, then dts
<marc|gonzalez> Oh, that makes more sense, OK
<bamse> that's why i said "swap 2 and 3" :)
<marc|gonzalez> I guess my mind just froze when you wrote "send another version"
<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
<lumag> marc|gonzalez, it really makes life of a maintainer easier
<marc|gonzalez> lumag: what does? :) Getting the details right? I suppose that's true in all walks of life ;)
<lumag> Even ordering the patches.
<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"
<marc|gonzalez> probably because I find git send-email so intimidating
<marc|gonzalez> Also, I'd still be happy to get 3 rounds on a ring with Linus some day
<javierm> marc|gonzalez: are you familiar with b4 or patman? Make the whole process less frustrating
<marc|gonzalez> javierm: I am not!
<marc|gonzalez> which one do you recommend?
<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
<marc|gonzalez> thanks for the pointer
<javierm> marc|gonzalez: patman is awesome and I've been using it for a decade now :)
<lumag> marc|gonzalez, I've switched to b4. It made my life easier.
<marc|gonzalez> I've been doing everything by hand
<javierm> lumag: I've meaning to look at b4 but it seems I'm too old to change my workflow :D
<javierm> but yes, I only heard good things about b4
<marc|gonzalez> b4 there was nothing, then someone said let there be light
<lumag> javierm, judging by your graduation dates, we should be of the same age. you can't be too old.
<marc|gonzalez> Age Is Just a Number — That Keeps Going Up
<phh> so a monotonic counter
<javierm> lumag: yeah, I was partially joking. I've in my TODO to switch to b4 but is low prio in the list
<lumag> :-D
<javierm> lumag: I'm a happy camper with patman though, so I first to understand what value b4 would bring to my workflow
<javierm> *first need to
<aka_[m]> <marc|gonzalez> "Age Is Just a Number — That..." <- thats right officer
<lumag> I haven't looked at patman. It definitely was an improvement over raw git-send-email & scripts that I was using beforehand
<javierm> lumag: I've a presentation from dianders in my queue but again is hidden on top of another 100's videos
<narmstrong> I saw it live at eoss and I still prefer patman
<lumag> The important point for me was that it solved handling of to/cc lists and me forgetting to include / update a cover letter
<javierm> narmstrong: ah! interesting
<javierm> is the talk from Doug btw
<narmstrong> Sorry I still prefer b4
<javierm> narmstrong: oh, plot twist :P
<narmstrong> Yeah patman is more about tracking per patches changes and per patches cc/to
<marc|gonzalez> No, wait, patman!
<marc|gonzalez> Who doesn't love pacman, anyway...
<narmstrong> Perhaps it’s better for treewide changes
<narmstrong> And for sure is more adapted to uboot process
<narmstrong> B4 filled 110% of my workflow…
<javierm> narmstrong: I've been using it for any project that uses a send-patch-by-email workflow
<javierm> but my gut feeling is that both tools are quite similar
<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. ;-)
<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
<narmstrong> dianders: definitely adding lore url support would be a game changer
<dianders> narmstrong: you mean having it add the link to the previous versions of the patches, or something else?
<javierm> dianders: I'm a member of the Patman Evangelism Strike Force :D
<narmstrong> And the signature added by b4 is also very important when Google does dkim key rotations
<narmstrong> dianders: yes for example, but b4 can also apply any lore patchset and check the signature
<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...
<bamse> marc|gonzalez: and as was suggested above, removes pretty much all the effort on your side
<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"
<marc|gonzalez> As I mentioned, I had one patch series (very cool IMHO) for Mauro, which was ignored for 18 months
<marc|gonzalez> when he finally got to it, I had moved on, and on, and on, like the Energizer bunny
<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
<marc|gonzalez> bamse: in this circumstance, I had assumed that a subdir maintainer would pick it up
<marc|gonzalez> and incorrectly left Mauro out of the process, based on my previous interaction
<bamse> yeah, that process differs from area to area...
<bamse> makes sense...
<marc|gonzalez> It makes no sense to me to have a single dude be in charge of 5 gazillion disparate gizmos
<marc|gonzalez> I understand that he could be under water
<bamse> and tbh as a maintainer, the number of To: and Cc: is prohibitive, so in my case it doesn't really matter...
<marc|gonzalez> For this resend, I'm letting git send-email do its thing
<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
<krzk> I have a template answer which could work here (based on Greg's one), lemme paste:
<marc|gonzalez> I expected the solution would be divide & conquer, so having maintainers of drivers/media/platform/qcom feed their tree to Mauro
<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."
<marc|gonzalez> Yeah I'll relax when I'm dead, and then again, maybe not
<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.
<marc|gonzalez> krzk: what is the difference between Reviewer & Maintainer (in media) ?
<marc|gonzalez> I thought Reviewers would give "Reviewed-by" & Maintainers would merge to their trees
<marc|gonzalez> but in media, maintainers don't maintain a tree?
<marc|gonzalez> Sean & Hans have trees (I think)
<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).
<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.
<krzk> Simplifying you could think that reviewer helps, but maintainer decides (even if does not pick up patches).
<krzk> btw, media or DT is not odd here. netdev has similar rules, many other SoC trees as well (qcom...).
<marc|gonzalez> I don't understand why media would have so many maintainers, but ultimately everything must be reviewed by one person
<bamse> marc|gonzalez: no, all patches are reviewed by anyone...the maintainer can then through trust determine how much additional review is needed
<marc|gonzalez> bamse: but he must review the tags for 1000 patches every month
<bamse> marc|gonzalez: case in point, i expect Vikash knows the media i should only have to review the dts patch from a upstream-style point of view...
<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?
<marc|gonzalez> I imagine that's one thing improved by b'?
<marc|gonzalez> b4
pespin has quit [Remote host closed the connection]
<abhinav__> krzk Hi, can you pls explain to me about the question I asked on ... 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
mripard has quit [Remote host closed the connection]
flto has quit [Quit: Leaving]
flto has joined #linux-msm
flto has quit [Remote host closed the connection]
flto has joined #linux-msm
<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)
<bamse> marc|gonzalez: and it does that per patch
<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
<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)
valida-69[m] has quit []
eliaselias[m] has quit []
AntoniAloyTorrens[m]1 has quit []
MatrixTravelerbot[m] has quit []
nergzd723 has quit []
aedancullen has quit []