[PATCH v2] OF: Handle CMDLINE when /chosen node is not present
mick at ics.forth.gr
Wed Oct 24 06:32:40 PDT 2018
Στις 2018-10-23 17:30, Rob Herring έγραψε:
> On Mon, Oct 22, 2018 at 5:55 PM Palmer Dabbelt <palmer at sifive.com>
>> On Mon, 22 Oct 2018 15:42:13 PDT (-0700), robh at kernel.org wrote:
>> > On Mon, Oct 15, 2018 at 05:20:10PM +0300, Nick Kossifidis wrote:
>> >> The /chosen node is optional so we should handle CMDLINE regardless
>> >> the presence of /chosen/bootargs. Move handling of CMDLINE in
>> >> early_init_dt_scan() instead.
>> > I looked at this a while back. I'm not sure this behavior can be changed
>> > without breaking some MIPS platforms that could be relying on the
>> > current behavior. But trying to make sense of the MIPS code is a
>> > challenge and they have some other issues in this area.
>> > Can't this be fixed by making /chosen manditory? I'd expect ultimately
>> > you are always going to need it.
>> > I'd rather not resort to making this per arch. There's also some effort
>> > to consolidate cmd line handling.
>> I'd rather make /chosen mandatory on RISC-V than to have per-arch
>> handling, as
>> like you've said there's already too much duplication. That said, it
>> does seem
>> like a bug to me because the behavior seems somewhat arbitrary -- an
>> /chosen node causing the built-in command-line argument handling to go
>> off the
>> rails just smells so buggy.
> Yes. Probably need to do some archaeology on this code to figure out
> some of the expectations.
>> If that's the case, could we at least have something like
>> "CONFIG_OF_CHOSEN_IS_MANDATORY" that provides a warning when there is
>> /chosen node and is set on architecture where the spec mandates
> I'd be okay to make it a warning unconditionally. At least then we can
> find the cases that deviate and either fix them or understand their
I don't think we can make /chosen node mandatory since it's not
specified as such
by the spec
No matter what we say from the kernel side, the device tree provider is
to always provide the /chosen mode. Also device tree is not the only
a command line, we might get a command line from different places
per-arch (e.g. atags
on arm) or through EFI/ACPI/kexec as well. That's why my initial
approach for RISC-V
was on the arch-specific code.
We shouldn't try to handle the built-in CMDLINE on each of the possible
providers and if we do we should at least make sure we don't depend on
of a provided command line (which is the issue in this case).
I believe the best approach is to consolidate all the different CMDLINE
for the various archs / providers and clean up the mess instead of
the same thing again and again. I saw the patch you mentioned and it's a
I'll look more into it and try to come up with a similar one.
More information about the linux-riscv