Re: Linux Kernel (megi patches for PinePhone Pro)

Tanvir Roshid <[email protected]> Tue, 12 Mar 2024 16:34:18 +0000
Newsgroups org.kernel.vger.linux-embedded
Message-ID <[email protected]>
On 12/03/2024 16:30, Tanvir Roshid wrote:
> Hi,
>
> I hope you are well.
>
> I wanted to post this message to discuss the megous kernel and 
> communicate with the embedded Linux community. This post is my first 
> attempt at using the Linux mailing list, so forgive me if I make any 
> mistakes.
>
> For context, the megous kernel is a fork of the Torvald kernel 
> containing patches to enable the PinePhone and PinePhone Pro to boot 
> correctly.
>
> The megous kernel disappeared earlier this year. We have spent the 
> better part of the year getting the phones to boot with the upstream 
> kernel for GNOME OS. We successfully confirmed working boards using 
> patches found on this repo:
> - 
> https://gitlab.com/pine64-org/linux/-/tree/linux-pinephonepro-6.6.y?ref_type=heads
>
> The work is visible here:
> - https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/2455
>
> I am aware that a new fork replacing the megous kernel exists here:
> - https://github.com/sailfish-on-dontbeevil/kernel-megi
>
> The GNOME community would prefer not to rely on a custom kernel and 
> use the upstream version to avoid a repeat of the megous kernel and 
> its disappearance. Recently, the patches have understandably failed to 
> apply to the new kernel. We would prefer not to upstream these patches 
> for long-term maintainability versus continuous maintenance.
Apologies; my sentence was not clear here. I mean to state "We would 
prefer to upstream these patches for long-term maintainability versus 
continuous maintenance. "
>
> My question to the embedded community is:
> - What is preventing the upstream kernel from integrating these patches?
>
> From research (https://news.ycombinator.com/item?id=30015412), I can 
> see that these patches present problems. However, we would like to 
> know more specifics to eventually upstream these patches via 
> additional work.
>
> Kind regards,
> Tanvir Roshid
>
>