Received-SPF: pass (google.com: domain of linux-embedded+bounces-22-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <cfaa5c50-fc76-4766-8ace-4c92820d3baa@codethink.co.uk>
Date: Tue, 12 Mar 2024 16:34:18 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux Kernel (megi patches for PinePhone Pro)
Content-Language: en-US
From: Tanvir Roshid <tanvir.roshid@codethink.co.uk>
To: linux-embedded@vger.kernel.org
References: <a5b7e74f-fad6-4a07-a2cc-614cdb75046e@codethink.co.uk>
In-Reply-To: <a5b7e74f-fad6-4a07-a2cc-614cdb75046e@codethink.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: tanvir.roshid@codethink.co.uk


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
>
>