[LA.UM.7.1.r1] Merge tag 'LA.UM.7.1.r1-16600-sm8150.0'

[tomgus1]

No description provided.

[pablomh]

Hi @tomgus1, should this one be applied on top of the other?

[tomgus1]

@pablomh this can be applied without the other but added for continuity and easier tracking.

[stefanhh0]

Testing this one on yoshino/lilac. Until now no new regressions found everything seems to be fine.

Already tested:

• Booting the phone
• Using Front and Rear camera
• Playing ogg music files

In case I spot something unusual I will report back, running this one together with Kernel 4.14.190 PR

[kholk]

Tim, I've been thinking about this one a lil more... Can you remove and PR separately all the camera related commits?
Also please remove the "useless" merge commits (let's not start a discussion about this, they're useless but they're not).

After applying the requested changes, we should then merge the rest.

[stefanhh0]

Very good idea indeed Angelo, 42 of the 87 commits are merge commits. Removing them, makes the PR a lot more easier to deal with and removes the noise from the content.

@tomgus1 if you don't have enough time sorting commits I could help you with that.

In general I'd love to see that we are making progress adapting also the other missing fixes from CAF that are contained in https://source.codeaurora.org/quic/la/kernel/msm-4.14/tag/?h=LA.UM.7.1.r1-17400-sm8150.0. My hope would be, that there are more fixes that stabilize/improve the kernel for our phones. The 17400 tag is as well already 8 month old and maybe it contains fixes for the 10 month old tag: 16600?! I wonder if it wouldn't be more time efficient when we try to test all non camera related fixes until 17400 in one go and afterwards testing the camera related stuff in the from Angelo suggested separate PR. It would be very unfortunate to stumble upon problems in 16600 that have been already fixed in 17400. Do they have a consolidated changelog like e.g. kernel.org? I haven't found one.

[MarijnS95]

Sorting out the merges should be relatively easy as rebase automatically drops them (assuming no merge conflict resolution is the merge commits 🙈).

The only reason to "keep" this history is to share the tree with CAF. Meaning all the commits retain their identical hash with CAF rather than appearing cherry-picked, and new(er) tags on the same branch will be properly based on top of that, instead of appearing as a totally different diverging branch. In addition git might not always be able to understand what commits have been applied (especially if things are applied and reverted multiple times), but that's relatively easy to solve with git rebase --onto aosp/LA.UM.7.1.r1 last-merged-tag-like-16600 new-tag-to-merge-like-17400 to pick only new stuff (or cherry-picking a range...).

Though, I guess this all sums up to Angelo's:

let's not start a discussion about this, they're useless but they're not

😁

@stefanhh0 all development now happens on 8.1 tags for "Android 10" which is why 7.1 tags for "Android 9" haven't been added anymore.

[stefanhh0]

x

[kholk]

So basically we already have at least 75% of this PR in... :p

[stefanhh0]

Yes, I will go through and prepare a separate PR that collects the very few commits that are missing.

[MarijnS95]

@stefanhh0 that's a lot of manual labour here! Are you checking whether commits are potentially reverted and re-applied again or is this something that a rebase with conflicts (utilizing patch-id under the hood to omit previously applied commits, even if they are reverted later) could have solved?

[stefanhh0]

Well, I wanted to understand what exactly is missing and what can be omitted. I have finished the work already and I will send the PR as soon as I have build it and it and see it running on my phone. Only 16 commits were missing.

[MarijnS95]

Fair point to be made, rebasing and blindly skipping every commit that conflicts yields me 13 commits. So it's good to have all these checked in the end.