[7.1.r1] linux: 4.14.304

[voidanix]

Requires #2581 (marked as draft because of that).

Tested on kumano.

[voidanix]

BTW, there seem to be some code smells e.g. here (notice how the condition is never satisfied due to turning_on_clk = false.

The ACK just keeps the variable unaltered in this case because dropping inside the condition would bootloop the device.

What should be done in these cases? Revert the offending commits? I am currently keeping those for much easier merging down the line, but let me know if these can be tackled otherwise.

[roberto-sartori-gl]

Hi, thank you for your work on this! I don't have time unfortunately to help on it but I really appreciate it.

BTW, there seem to be some code smells e.g. here (notice how the condition is never satisfied due to turning_on_clk = false.

This is present since 4.14.301 due to this commit: https://lore.kernel.org/linux-mmc/20221124170649.63851-1-adrian.hunter@intel.com/T/

https://elixir.bootlin.com/linux/v4.14.301/source/drivers/mmc/host/sdhci.c#L1727

I think that line was missed on the 301 patch, so probably we can rebase to that and add the missing line.

[voidanix]

I don't have time unfortunately to help on it but I really appreciate it.

Thank you for caring :')

I think that line was missed on the 301 patch

Yes, read https://github.com/sonyxperiadev/kernel/pull/2582#issuecomment-1762433463 more carefully though (second line): if I add that line of code that you mentioned, the condition will return the function early and thus bootloop the device.

This also explains why the common-kernel skipped it, even if it looks like a normal merge (shame on them for doing such thing without a separate commit).

AFAIR, this is due to how msm-sdhci works before kernel 5.4, but I do not remember much from this investigation conducted almost a year ago.

Thus my comment was about removing (or not) that specific code about voltage switching, since it does not seem to do anything right now.

[roberto-sartori-gl]

Sorry, yes, I did misread your comment.

This also explains why the common-kernel skipped it, even if it looks like a normal merge (shame on them for doing such thing without a separate commit).

The line is present in the Android 4.14-stable branch though (but the branch is now at 4.14.327): https://android.googlesource.com/kernel/common/+/refs/heads/android-4.14-stable/drivers/mmc/host/sdhci.c#1727

[voidanix]

The line is present in the Android 4.14-stable branch though

Oh dang, you are right.

It seems that google's msm-4.14 repo does not directly merge from common-kernel: here's their 4.14.301 merge of the file, notice how the line is missing.

This should further prove that there is a problem on the msm side of things...

[roberto-sartori-gl]

The line is present in the Android 4.14-stable branch though

Oh dang, you are right.

It seems that google's msm-4.14 repo does not directly merge from common-kernel: here's their 4.14.301 merge of the file, notice how the line is missing.

This should further prove that there is a problem on the msm side of things...

Yeah actually they may have seen the same bootloop issue that you are seeing and decided to hide the workaround in the merge commit. The line is there in the commit: https://github.com/LineageOS/android_kernel_google_msm-4.14/commit/f60b9ea221edd04b591916ccabf1733e0d060860

But it does not exist after the merge, so...

[roberto-sartori-gl]

By the way, I can confirm that 4.14.304 works fine on my msm8998 device too. I don't have an sdhci device (internal UFS and no sdcard) so I don't have the bootloop issue with the change mentioned above anyway, so I can't help much on that.

[ShujathMohd]

Tested this patch on akatsuki and did not notice any issues.

Lets go with what common kernel did with the code smell?

[voidanix]

@jerpelea, this is also ready to be merged :)

[rhjdvsgsgks]

off topic: should we also sync some changes from android common kernel? such as kasan in this series (https://android-review.googlesource.com/c/kernel/common/+/989612)

[jerpelea]

please let people test it a bit

[rhjdvsgsgks]

tested on maple. didn't get any issus so far (i mean this pr. not relevant to "downstream patch" i mentioned before)

[voidanix]

should we also sync some changes from android common kernel?

I already have some fixes queued from the ACK that I intend to submit after 4.14.314, but KASAN is not going to be one of them (unless somebody really uses it).

Also probably going to get cgroup freezer v2 in.

[jerpelea]

Please think about the fact that 4.14 kernel will be EOL soon (Jan, 2024) https://www.kernel.org/category/releases.html

Maybe it is worth spending time on 5.4 instead (Dec, 2025)

[roberto-sartori-gl]

Please think about the fact that 4.14 kernel will be EOL soon (Jan, 2024) https://www.kernel.org/category/releases.html

Maybe it is worth spending time on 5.4 instead (Dec, 2025)

5.4 is not an option for a lot of devices (for example, for Sony, the Yoshino based ones).

[MarijnS95]

5.4 is not an option for a lot of devices (for example, for Sony, the Yoshino based ones).

And how about mainline Linux? It's inching ever closer, but the more time folks spend on EOL downstream the less time remains for upstream.

[roberto-sartori-gl]

5.4 is not an option for a lot of devices (for example, for Sony, the Yoshino based ones).

And how about mainline Linux? It's inching ever closer, but the more time folks spend on EOL downstream the less time remains for upstream.

At the end I think it depends on the final goal here: I'm running 4.14 on my phone right now, and I don't think we should abandon 'old' kernels that are working 'quite well' to just focus on mainline. To be honest mainline is far, far away from being usable with Android.

And, related to this, these are two very different types of jobs. One thing is backporting patches, or upgrading kernel minor versions, another thing is fixing mainline clock configs, peripherals or such. I don't think one thing steals time from the other.

Don't get me wrong, I love the idea of mainline kernel, but if I need a functional phone, mainline is in my opinion not an option for the short or medium term.

In fact, I'm pretty sure there are no phones currently running Android with mainline on day to day devices - just for development.

[MarijnS95]

Abandoning old kernels is completely different from painstakingly trying to port patches from various sources; upstream Linux-stable, ACK, and hopefully also patches provided for the various CAF/QUIC/MSM drivers/changes/subsystems in this tree.

I don't think one thing steals time from the other.

That is the sole reason - for me - to have pretty much stopped contributing to these older kernel branches. It steals an insane amount of time to pick patches, test on various devices, spot bugs, and spend days resolving them. All while only patching half the holes.

In fact, I'm pretty sure there are no phones currently running Android with mainline on day to day devices - just for development.

I think that's solely to blame on the fact that we (= the folks contributing to mainline) are going wide over all platforms/devices rather than depth-first picking one device and pushing it over the finish line. Upstream all Sony devices are somewhere in-between booting to USB console and having display/battery/sound/connectivity working.

Once the latter is achieved on more devices I might start publishing my Android trees for these devices.

[voidanix]

Please think about the fact that 4.14 kernel will be EOL soon (Jan, 2024)

Totally aware of this: it would be indeed nice to get everything in until development stops.

Maybe it is worth spending time on 5.4 instead (Dec, 2025)

Even if it was possible to port older devices there, the issues with binaries remain.

And how about mainline Linux? It's inching ever closer, but the more time folks spend on EOL downstream the less time remains for upstream.

There is no new device bringup or anything super-shiny for 4.14 anymore.

And let's be real now: are you able to get the adsp/cdsp/modem/etc. firmware for e.g. sm8150 on linux-firmware? Without these, the device is seriously handicapped for real daily usage.

...but if I need a functional phone, mainline is in my opinion not an option for the short or medium term.

You said it best, thank you.

In fact, I'm pretty sure there are no phones currently running Android with mainline on day to day devices - just for development.

All mainline devices I know of (and tried to daily drive) are seriously broken for real world usage: from stone age smartphones to things like the Pinephone, they all have quirks and are overall finicky.

It steals an insane amount of time to pick patches, test on various devices, spot bugs, and spend days resolving them.

Thankfully there are other people who can do this though. Mainlining is on a whole different level that us plebs cannot yet reach :D

[roberto-sartori-gl]

That is the sole reason - for me - to have pretty much stopped contributing to these older kernel branches. It steals an insane amount of time to pick patches, test on various devices, spot bugs, and spend days resolving them. All while only patching half the holes.

The assumption here is that everyone has the capabilities/knowledge do both (working on old kernels, and mainlining), but as @voidanix just said:

Mainlining is on a whole different level that us plebs cannot yet reach :D

[MarijnS95]

Take it as a compliment when I said that we're loosing/wasting good developers' time on juggling around downstream kernel patches :wink:

And let's be real now: are you able to get the adsp/cdsp/modem/etc. firmware for e.g. sm8150 on linux-firmware? Without these, the device is seriously handicapped for real daily usage.

Just as one is currently shipping/flashing many downstream binaries in "closed" form to the phone, doesn't mean that in mainline everything should suddenly be available from those repositories. The desire is to run a (close to) mainline fork with few patches on top of the latest stable release, but one will still have to build a (typically generic) Android (boot + vendor) or GNU-or-MUSL/Linux with custom firmware and non-final/-standard userspace drivers.

That's still a lot better than fully-closed-source binaries and libraries, even if their functionality/stability still isn't near downstream. As I said: breadth-first.

---

But I guess it is a compliment to all the capable developers that ever contributed to Sony Open Devices when it is still being daily-driven by the community :+1:

[rhjdvsgsgks]

should we also sync some changes from android common kernel?

I already have some fixes queued from the ACK that I intend to submit after 4.14.314, but KASAN is not going to be one of them (unless somebody really uses it).

in fact. the reason of i want kasan is that it is something necessary when merging mglru commits from here . i can share you all commits i picked from ack when porting mglru if you also interested in it

[voidanix]

but one will still have to build a (typically generic) Android (boot + vendor) or GNU-or-MUSL/Linux with custom firmware and non-final/-standard userspace drivers.

I see your point... sad that we cannot recycle some old binaries to obtain all functionality on a device, even when most of the features would be powered by mainline.

But I guess it is a compliment to all the capable developers that ever contributed to Sony Open Devices when it is still being daily-driven by the community 👍

It absolutely is, thank you guys for everything :)

---

in fact. the reason of i want kasan is that it is something necessary when merging mglru commits from here . i can share you all commits i picked from ack when porting mglru if you also interested in it

Hmm... totally forgot about MGLRU lol.

I encourage you to push a PR on your own that integrates the feature: that would be fantastic.

[MarijnS95]

I see your point... sad that we cannot recycle some old binaries to obtain all functionality on a device, even when most of the features would be powered by mainline.

It "depends". I've been toying with the idea of porting "certain" downstream drivers (if necessary together with downstream blobs) to support quicker bringup. For example fingerprint support. Most of the other basic functionality already has some work going upstream (LEDs, modem, calls and data, audio) and typically in such a way that an upstream project can be used by both GNU/MUSL userspace, as well as Android (bionic).

Either way we'll need firmware that is signed to run on remoteprocs/TZ.

But I digress, this is a PR not a place to discuss mainline support and approaches :)

[rhjdvsgsgks]

in fact. the reason of i want kasan is that it is something necessary when merging mglru commits from here . i can share you all commits i picked from ack when porting mglru if you also interested in it

Hmm... totally forgot about MGLRU lol.

I encourage you to push a PR on your own that integrates the feature: that would be fantastic.

is there any limit of what can i port and what not? i have also picked some other patch in my personal repo, such as update zstd, wireguard, bore, le9, and some wip ebpf stuff. some of them neither in mainline nor in ack. im not sure are they also suitable to pr them here

[roberto-sartori-gl]

in fact. the reason of i want kasan is that it is something necessary when merging mglru commits from here . i can share you all commits i picked from ack when porting mglru if you also interested in it

Hmm... totally forgot about MGLRU lol. I encourage you to push a PR on your own that integrates the feature: that would be fantastic.

is there any limit of what can i port and what not? i have also picked some other patch in my personal repo, such as update zstd, wireguard, bore, le9, and some wip ebpf stuff. some of them neither in mainline nor in ack. im not sure are they also suitable to pr them here

We should keep the PR separated, so if you have a PR with wireguard, just open that one, then a different one for ZSTD for example.

I also have some BPF stuff on my repo but they are not relevant right now.

[rhjdvsgsgks]

in fact. the reason of i want kasan is that it is something necessary when merging mglru commits from here . i can share you all commits i picked from ack when porting mglru if you also interested in it

Hmm... totally forgot about MGLRU lol. I encourage you to push a PR on your own that integrates the feature: that would be fantastic.

is there any limit of what can i port and what not? i have also picked some other patch in my personal repo, such as update zstd, wireguard, bore, le9, and some wip ebpf stuff. some of them neither in mainline nor in ack. im not sure are they also suitable to pr them here

We should keep the PR separated, so if you have a PR with wireguard, just open that one, then a different one for ZSTD for example.

I also have some BPF stuff on my repo but they are not relevant right now.

ofc i will pr them separately.

but what i mean the 3rd part patch which never been merge to mainline or ack (such as bore). because im not smart enough to verify the quality of them. and i have no guarantee to it. should i still pr them in this case?

[voidanix]

should i still pr them in this case?

That would make this a "ready for XDA" custom kernel though... It is just too much IMO.

MGLRU is something that is upstream already and we happen to have the patches available for 4.14, giving gratis performance all around.

[rhjdvsgsgks]

should i still pr them in this case?

That would make this a "ready for XDA" custom kernel though... It is just too much IMO.

MGLRU is something that is upstream already and we happen to have the patches available for 4.14, giving gratis performance all around.

ok. i will only push the patchs which upstreamed already. mglru still need some clean and test. since it is a huge patch