Merge tag 'LA.UM.9.2.r1-03400-SDMxx0.0' of https://source.codeauroraorg/quic/la/kernel/msm-4.4 into lineage-18.1-caf-msm8998

[Flamefire]

• tag 'LA.UM.9.2.r1-03400-SDMxx0.0' of https://source.codeaurora.org/quic/la/kernel/msm-4.4:
  diag: Use valid data_source for a valid token

Change-Id: Ie86f072048d1863b07d74ef1e6500b5f18e75963

[derfelot]

Thanks. Before I get to my question, I'll just reply to you previous question here, regarding what we track for the kernel.

Besides the obvious (Linux 4.4 stable) we track

• Wireguard (https://git.zx2c4.com/wireguard-linux-compat/log/). Though I only ever merge snapshots, v1.0.20210606 being the last.
• sdfat in fs/sdfat from https://github.com/cryptomilk/kernel-sdfat I always try to update that first and bump @cryptomilk for merge if he doesn't see it before pulling it for updates. It is added to the kernel as a subtree, so doing git subtree pull --prefix fs/sdfat/ https://github.com/cryptomilk/kernel-sdfat master should do it
• Same with the qcom wifi driver in drivers/staging/fw-api/, drivers/staging/qca-wifi-host-cmn/ and drivers/staging/qcacld-3.0/ Here we need to track the LA.UM.7.4.r1 branch. Anything more recent is not compatible with our firmware, causing crazily reduced speeds. luk1337 also helped to test this for me once using a device that does have a new firmware. There won't be any more updates for this branch, so critical updates need to be checked manually in the ASB's from other branches to see if they apply for us as well.
• Finally, the caf tag for the msm-4.4 kernel. Until now, we have tracked LA.UM.8.4.r1 at first, then LA.UM.8.4.1.r1 to get more recent updates (they were virtually similar).

That's all I can think of. Now, for this change, I am generally fine with tracking this caf branch, I know of other devices doing this as well (e.g. cheeseburger on LOS). But I was wondering if this is the only update there is, e.g. the only change we are missing? Have you tried pulling the complete tag, or just this specific one for that commit? I haven't yet had the chance to compare LA.UM.8.4.r1 or LA.UM.8.4.1.r1 with LA.UM.9.2.r1 to see what the differences are.

Thanks

[Flamefire]

Thanks a lot! What a mess...
Could you (for completeness, this is a great summary!) edit in the source repos for the qcom wifi drivers? Having an example source commit where to get the fixes for ASB issues would also be good for future reference.

For my understanding: "the caf tag for the msm-4.4 kernel. [...] tracked LA.UM.8.4.r1". What is the caf tag? I have seen multiple tags named LA.UM.8.4.r1-04600-8x98.0, LA.UM.8.4.r1-04500-8x98.0, ... So I guess this is LA.UM.8.4.r1-<version>-8x98.0
Also what does caf and LA.UM actually stand for? Haven't followed kernel dev to much previously so this is new to me. Been more into userspace where you can better debug stuff ;)

But I was wondering if this is the only update there is, e.g. the only change we are missing? Have you tried pulling the complete tag, or just this specific one for that commit?

I actually just took LineageOS/android_kernel_razer_msm8998@d46db1f which also uses msm8998 and 4.4 kernel and the commit did look correct and useful as far as I can tell. So no, didn't check the whole tag, just this single commit. Can double check later or tomorrow.

I also found other kernel repos tracking https://android.googlesource.com/kernel/common/+log/refs/heads/android-4.4-p instead of mainline linux. A quick rebase check shows a few commits (~50) not in our kernel although they may be superseded by upstream changes. Wanted to check which of those are still useful for us (most are tagged as ANDROID) when I got some time.

[bananafunction]

@derfelot & @Flamefire : you can use CAFs latest tag for QCOMs wifi driver on Android 9: LA.UM.7.2.r2-08800-8x98.0
For what I see, it is up to date with latest patches from ASB and for me (running LOS 18.1 on lilac) it does work fine:
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/log/?h=wlan-cld3.driver.lnx.1.1.r61-rel
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qca-wifi-host-cmn/log/?h=wlan-cmn.driver.lnx.1.0.r61-rel
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/fw-api/log/?h=wlan-api.lnx.1.1.r64-rel

[Flamefire]

@bananafunction Thanks for the info! I guess https://github.com/bananafunction/android_kernel_sony_msm8994 is the kernel you are using? It's on CM 14.1, so maybe you use another one? Asking because it might make sense to join forces. E.g. I'm building LOS 17.1 and 18.1 ROMs with this kernel, another user is using it for HavocOS already, ...

And WTF is up the with versioning? The latest tag from @derfelot is LA.UM.7.4.r1-06000-8x98.0 from 17 months ago, LA.UM.7.2.r2-08800-8x98.0 is last changed 5 weeks ago O.o So how am I supposed to read those tags?

[bananafunction]

@bananafunction Thanks for the info! I guess https://github.com/bananafunction/android_kernel_sony_msm8994 is the kernel you are using? It's on CM 14.1, so maybe you use another one? Asking because it might make sense to join forces. E.g. I'm building LOS 17.1 and 18.1 ROMs with this kernel, another user is using it for HavocOS already, ...

And WTF is up the with versioning? The latest tag from @derfelot is LA.UM.7.4.r1-06000-8x98.0 from 17 months ago, LA.UM.7.2.r2-08800-8x98.0 is last changed 5 weeks ago O.o So how am I supposed to read those tags?

@Flamefire For my kernel I am using a fork from @cryptomilk & @derfelot kernel: https://github.com/bananafunction/android_kernel_sony_msm8998 and currently on branch lineage-18.1
Basically I just updated/removed some stuff (e.g. no kernel wireguard support, additional patches from googles common kernel branch 'android-4.4-p', wifi patches from CAF tag 'LA.UM.7.2.r2-08800-8x98.0' and soon - as you are already asking in this PR - I will track CAF tags 'LA.UM.9.2.r1' - just like many msm8998 kernel)

As @derfelot mentioned, there were speed/stability issues with the wifi drivers from 'LA.UM.8.4.r1' for our devices, so those were reverted to 'LA.UM.7.4.r1'. However, I found that CAF opened a new branch (and therefore new tags) for msm8998 on Android 9 which I now use to stay up-to-date. However, I just own a lilac device and no other yoshino platform based devices, so I cannot tell if the updated 7.2.r2 wifi drivers work on all devices. If you like, you can build my kernel for testing purpose in your own build.

EDIT: for some weird reason I just saw, github reports my kernel to be forked from @Myself5 kernel. I guess that this is a broken information from time before 'whatawurst' repos were created....

[Flamefire]

Ah confused that last digit 😅
Yeah that sounds pretty reasonable for this kernel. Wanted to include the Google patches too once I got some time. Not trivial at this point due to conflicts and need to check what is still required. I'd guess it makes more sense to track that Google branch instead of upstream Linux as upstream Linux is already tracked by Google, with minor delay.
What was the reason for removing wireguard?

Maybe you can change the base fork or contact the support to do that? Might be worth comparing your repo with this :)

[bananafunction]

Ah confused that last digit 😅
Yeah that sounds pretty reasonable for this kernel. Wanted to include the Google patches too once I got some time. Not trivial at this point due to conflicts and need to check what is still required. I'd guess it makes more sense to track that Google branch instead of upstream Linux as upstream Linux is already tracked by Google, with minor delay.
What was the reason for removing wireguard?

Maybe you can change the base fork or contact the support to do that? Might be worth comparing your repo with this :)

Yeah, I also thought about switching to 'android-4.4-p' branch, but as you also mentioned, there are some conflicts, so I decided to go the easy way with cherry-picking from googles branch and stay on linux stable :-)

Comparison of my kernel to whatawurst kernel is easy as I set it up newly after 27th of May 2021, so no long history to compare ;-)

Reason for removing kernel wireguard support is simply that I tend to forget to update stuff which is neither on linux stable, googles android-4.4-p nor on CAFs branches... So I assume it is safer to use the wireguard android app...

[Flamefire]

Reason for removing kernel wireguard support is simply that I tend to forget to update stuff which is neither on linux stable, googles android-4.4-p nor on CAFs branches... So I assume it is safer to use the wireguard android app...

That's why I suggested we join forces and keep all in one kernel repo and evrybody PRs update he remembers ;)

Comparison of my kernel to whatawurst kernel is easy as I set it up newly after 27th of May 2021, so no long history to compare ;-)

Kinda. But with merging the Linux kernel commits accumulate quite a lot making it harder. Having a common base repo allows to use the Github tools and have stuff like "xxx is ahead of yyy by zzz commits"

[derfelot]

We shouldn't directly track the aosp kernel, since as you have pointed you there are some differences with caf. Sony's kernel is based on caf, so that's why we are using that. There is nothing wrong with cherry-picking relevant commits from aosp though, but the important ones will (or should at least) also make it into caf.

as for wireguard, there are certain advantages to having direct kernel support, such as speeds and battery usage (doesn't the app only also require root? i can't remember). and wireguard kernel implementation is very stable now (iirc it also made it into mainline now), so it's the preferred way.

[Flamefire]

Not fully sure about that. The commits in the AOSP kernel missing here are mostly prefixed by ANDROID, meaning they are specific to android. Sure got to check what in particular they do but I can't imagine it would be bad having them, rather it could be bad NOT having them.
The BACKPORT marked ones probably already landed in caf and I guess conflict resolution will show that. So no worry about them

Quick question about testing: As far as I understood the kernel is compiled into the boot.img file, so instead of flashing the whole ROM to test a new kernel build I get the same result by using fastboot boot boot.img except that the change will be reverted on reboot, which is good in case I mess anything up.
Is this correct, i.e. it is (~99%) enough to test the kernel with fastboot or am I missing anything?

[derfelot]

Not sure about what? the important ones making it to caf?

These are just some examples from LA.UM.8.4.1.r1:

https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LA.UM.8.4.1.r1-03100-8x98.0&id=2b8fab40e5c99041902d9f8eb13d9c66670f08af
https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LA.UM.8.4.1.r1-03100-8x98.0&id=90cbaf5095aa53f37dca49c4e5b2593518cfa955
https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LA.UM.8.4.1.r1-03100-8x98.0&id=766d0c0c6c388ec3833caf9c47e9f3f50230cdc3

If they are ASB-relevant, they should be included (mostly). But i always manually go through each month's ASB to make sure that we have them all. Sometimes some are missing, but it's rare.

Using it via boot should probably be fine. But why not flash it and test, e.g. also reboot to recovery and other things (though I don't see anything here that could cause issues in that respect)? in case of issues you can always flash back the previous one.

[Flamefire]

About this:

We shouldn't directly track the aosp kernel, since as you have pointed you there are some differences with caf.

As far as I can tell the upstream linux kernel is merged into the aosp one and some additional (mostly android specific commits) are added too. So the aosp is a strict superset of the upstream kernel.
I can't (yet) really imagine a case where it would be bad to use the aosp one as I think the "differences" are beneficial (to android). But yeah, got to check first if that holds true for at least the current state.

But why not flash it and test, e.g. also reboot to recovery and other things

In case of a bootloop or hang I can just turn the phone off and am back to a working phone. Flashing back the previous rom is more of a hassle in those cases.
I don't see what rebooting to recovery should test. TWRP is in its own partition so should be affected by the kernel at all. Or what do you have in mind?

[derfelot]

It was just an example of something that is at least partially dependent on kernel. It happened once a long time ago that a caf commit caused issues with reboot to recovery, though I dont remember which one exactly. You dont have to flash the whole previous rom, just the boot.img should be enough.

as for aosp kernel, from what i remember things like zram or binder digressed quite heavily. So i'd rather not directly merge aosp tags, rather pick commits form it.

[Myself5]

If I may jump in with some random infos:

Says forked from M5

If a GitHub repo is deleted (the old msm development one) the "forked from" switches to the oldest fork. In that case my repo.

LA.UM

LA=Linux Android compared to e.g. LE, which is Linux Embedded or LF=Linux Firefox (or newer, Kai)

UM is supposedly "Universal MSM". It symbols the chip/bsp specific branches on newer revisions. E.g. the CAF Android sourced are split up between LA.UM and LA.QSSI.

Versions

8.X Tags are intended for Android 10, 9.X Tags for Android 11.

7.X is Android 9. Its likely 7.4 had been deprecated due upgrading the devices to Android 10, while 7.2 stayed on Android 9 and therefore still receives updates to that branch.

Apart from that: +1 to all (sane) Upstream Merging :)

@derfelot: Evidently I am a terrible IRC user, and I doubt that willl ever get better sooo... hows 18.1? Stable enough for me to leech it yet :P?

[derfelot]

@derfelot: Evidently I am a terrible IRC user, and I doubt that willl ever get better sooo... hows 18.1? Stable enough for me to leech it yet :P?

Heya :) Yeah, should be good. It's been stable enough for a while I think - WiFi display being the exception, as for most < sdm845 devices.

[bananafunction]

If I may jump in with some random infos:

Says forked from M5

If a GitHub repo is deleted (the old msm development one) the "forked from" switches to the oldest fork. In that case my repo.

Thanks for the information. I didn't know that :-)

Versions

8.X Tags are intended for Android 10, 9.X Tags for Android 11.

7.X is Android 9. Its likely 7.4 had been deprecated due upgrading the devices to Android 10, while 7.2 stayed on Android 9 and therefore still receives updates to that branch.

Do you know the full scheme behind the tags? I mean, I did know that 7.x is Android 9 but for me it seems just like random that 7.2.x stays on Android 9 and 7.4.x does not (or is no longer supported). Also, is there any roadmap on e.g. how long a branch/tag will be supported? I just check https://wiki.codeaurora.org/xwiki/bin/QAEP/release regularly and then fetch the CAF branches.

@Myself5 Anyway, thank you for the random yet conversation related facts ;-)

[Myself5]

Do you know the full scheme behind the tags? I mean, I did know that 7.x is Android 9 but for me it seems just like random that 7.2.x stays on Android 9 and 7.4.x does not (or is no longer supported). Also, is there any roadmap on e.g. how long a branch/tag will be supported? I just check wiki.codeaurora.org/xwiki/bin/QAEP/release regularly and then fetch the CAF branches.

The second part (X.2 and X.4) is the platform. Checked with a few people that all confirmed to me that X.2 is actually sdm660 and NOT msm8998. Nobody knows why its listed as msm8998 though. The platform number for msm8998 is X.4, which had been discontinued as msm8998 got upgraded to 8.4.

As far as I know there are no public roadmaps. I'd assume something like this is only accessible to customers (aka the licencees) rather than the public (and possibly a competitor).

[Flamefire]

Fwiw: running this via fastboot for a day now. No issues so far, vibration working.
There is a new tag already so going to check that and likely flash it.

[Flamefire]

Closing in favor of #35 (which is what I tested, damn confusing PRs)