devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, Paul Burton <paul.burton@mips.com>
Subject: Re: [PATCH v2] of/fdt: implement a "merge-cmdline" property
Date: Mon, 05 Aug 2019 10:39:03 -0700	[thread overview]
Message-ID: <1565026743.10475.24.camel@chimera> (raw)
In-Reply-To: <CAL_JsqLobsATYbKR0Rx8kpS3i+hHqsqibYn9h5Xi1T=DVwRF1g@mail.gmail.com>

On Mon, 2019-08-05 at 10:29 -0600, Rob Herring wrote:
> On Mon, Aug 5, 2019 at 9:53 AM Daniel Gimpelevich
> <daniel@gimpelevich.san-francisco.ca.us> wrote:
> >
> > Currently, "bootargs" supplied via the "chosen" node can be used only to
> > supply a kernel command line as a whole. No mechanism exists in DT to add
> > bootargs to the existing command line instead. This is needed in order to
> > avoid having to update the bootloader or default bootloader config when
> > upgrading to a DTB and kernel pair that requires bootargs not previously
> > needed.
> 
> The DTB and kernel are not a pair. Or at least they shouldn't be. If
> anything, the bootloader and DTB are a pair as those are the h/w
> specific parts. If the DTB and kernel are a pair, then anything you
> want to put into DTB can just be in the kernel.

They would only be a pair in the sense that DTB changes using newer
bindings would also require a newer kernel.

> There's been some
> attempts to rework the command line handling to be common and support
> prepending and appending which could be useful here.

Sounds good. Can you reference any commit hash for this?

> > One example use case is that OpenWrt currently supports four ARM devices by
> > means of locally applying the previously rejected edition of this patch. So
> > far, the patch has been used in production only on ARM, but architecture is
> > not a distinction in the design.
> 
> Other distros support dozens of boards, so why haven't they ever
> needed such a change?

IMHO, each of those four boards could be supported in some other way.
That said, some other devices have bootloaders implementing dual boot
with fallback on failure, and the kernel should always have access to
any bootarg that reflects which one is being booted.

> > On MIPS, Commit 951d223 ("MIPS: Fix CONFIG_CMDLINE handling") currently
> > prevents support of such a mechanism, so I am including a workaround, in
> > anticipation of upcoming changes.
> 
> Like I said on irc, mixing this with the mess that is MIPS
> bootloader-kernel interface generally and command line handling
> specifically is not a path to upstream.

The DT proposal can be separated from the MIPS mess.

> This is worse than the original proposal because 'merge' is not clear
> what it does compared to 'append' and how does 'cmdline' relate to
> 'bootargs'.

Can there be a different property name that would be better instead of
worse?

  reply	other threads:[~2019-08-05 17:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-05 15:53 [PATCH v2] of/fdt: implement a "merge-cmdline" property Daniel Gimpelevich
2019-08-05 16:29 ` Rob Herring
2019-08-05 17:39   ` Daniel Gimpelevich [this message]
2019-08-10  2:12 ` Frank Rowand
2019-08-10  2:26 ` Frank Rowand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1565026743.10475.24.camel@chimera \
    --to=daniel@gimpelevich.san-francisco.ca.us \
    --cc=devicetree@vger.kernel.org \
    --cc=paul.burton@mips.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).