Received-SPF: pass (google.com: domain of linux-kernel+bounces-183885-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 20 May 2024 10:12:07 -0500
From: Rob Herring <robh@kernel.org>
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Saravana Kannan <saravanak@google.com>,
	Arnd Bergmann <arnd@arndb.de>, Helge Deller <deller@gmx.de>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Baoquan He <bhe@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	David Bauer <mail@david-bauer.net>, Liviu Dudau <liviu@dudau.co.uk>,
	Serge Semin <fancer.lancer@gmail.com>, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org
Subject: Re: [PATCH 0/4] of: bootargs handling improvement
Message-ID: <20240520151207.GA541701-robh@kernel.org>
References: <20240512132513.2831-1-ansuelsmth@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240512132513.2831-1-ansuelsmth@gmail.com>

On Sun, May 12, 2024 at 03:25:07PM +0200, Christian Marangi wrote:
> This is a very simple series that try to solve a very simple problem.
> 
> Many emebedded devices have very hacked (by OEMS) bootloader that do all
> kind of modification and makes the kernel unbootable with the very first
> small modification. And also many times these broken bootloader have
> hardcoded values that can't be modified and would require risky
> procedure that can brick the device.
> 
> One of the common modification done is hardcoding bootargs in the
> appended kernel DT trashing the bootargs set in the /chosen.
> 
> The main usage of this is to have dynamic stuff to support dual
> partition scheme and make the kernel load a dedicated rootfs. But the
> other usage of this is to effectively lockup the device and cause kernel
> panic on modification like using squashfs instead of legacy jffs2.
> 
> The simple solution to this is to let the bootloader override the
> bootargs in /chosen and make the kernel parse a different property.

What happens when bootloaders start using these new "standard" bootarg 
properties and you need to override them? Perhaps name it something the 
OEM wouldn't use (maybe): 
"use-this-bootargs-instead-for-the-broken-bootloader"

> >From long time on OpenWRT we use bootargs-override as the alternative
> property for this task fixing the problem of overridden bootargs.
> 
> The second feature is bootargs-append. This is self-explanatory,
> sometimes bootargs from bootloader might be good but lack of some
> crucial things that needs to be appended, like rootfstype or rootfs
> path.

It is unfortunate that the kernel's handling of appending or prepending 
to bootargs is ambiguous. And MIPS is a further mess with handling 
cmdline from multiple sources.

I'm not really interested in adding any more complexity to the cmdline 
handling until it is made common. There's been at least 2 approaches to 
doing that.

Rob