Received: by 10.213.65.68 with SMTP id h4csp865477imn; Tue, 20 Mar 2018 18:14:06 -0700 (PDT) X-Google-Smtp-Source: AG47ELv9efv1kbFIANJEUphUGT5h2lWx+uLhkm0SDOxymShyXcOqXYAzo/XGHpUCgNNZQvOoPTxf X-Received: by 10.98.46.197 with SMTP id u188mr15473372pfu.32.1521594846634; Tue, 20 Mar 2018 18:14:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521594846; cv=none; d=google.com; s=arc-20160816; b=P/LLPKugaBfXnyD7oAbnu0J199pYKboT+WnOROr+97DIlAOxCdwGVldQ5mtfFg93/5 QL6LGJ/gi33cfGBppHrccttzPRnUoDGCgFUWWBA/CjQCaxYvPAEyxzEwENuyPqct7IjE ozkHQBGOt3lyhiT7y2z2qUWC6wWdPl2+XDy0SwC8spT6Wfqhugn+UBWnwjSKP97udtLC G+eKHqrdnm8Swxo3Gj7K11COh0wJpcjOGQpgvAPdUOjmZWYG4R8+5bY80Cl91+f0g6GX wRxV8cYm/ZcAsA2LTf9Cvn+q2Pv+a72CDKbc5Tzm1GnnJJRq3dpyraM4HWHMX6IkNPJ/ kvRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature :arc-authentication-results; bh=36+dKm/E6rKkPz0Xzr6rJeMpzRX7hk5tPwO7/mBOkfg=; b=gqdCHonyUqXzg7L3S8K5skkmub3r+IEyeTLCqx5xfAq8kpKd02F4TNqKp8SI3CqE5p pX5ZeUF1zBq3Bwp4uasoNr0dMVZPrPJRo6/B9Osvxcm7U+hmIwDBehNg6vtoP+2oUOxv jnMmnQ1GCZUYW5KsGNJdbxso6Ca5zweIVqhCWyD4nXch5yKri7oH4K3PXu3t8250DxXl 5b2mz222s7rf4ycFvA144hz4SOAxxejlZFrNzEmIeXrfQ2AZV7I4Ahrvbrqd99XuQqyW tae0NCsvMt5Oex4w8OBBY6/ETDnRhMpdwaEf5Q37fsfZDJLO6ztO++YW8LMNMgd5oWO/ 0FLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=CGkRWSy2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v3-v6si2744373plb.522.2018.03.20.18.13.52; Tue, 20 Mar 2018 18:14:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=CGkRWSy2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752139AbeCUBMc (ORCPT + 99 others); Tue, 20 Mar 2018 21:12:32 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:45013 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752124AbeCUBMY (ORCPT ); Tue, 20 Mar 2018 21:12:24 -0400 Received: by mail-pg0-f65.google.com with SMTP id l4so1347642pgp.11 for ; Tue, 20 Mar 2018 18:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=36+dKm/E6rKkPz0Xzr6rJeMpzRX7hk5tPwO7/mBOkfg=; b=CGkRWSy27xEEx8i7nD171vuWgOXROd4kG+Fb3jCNLhuYH+HzDqfU7bOCwSjDYc3we2 vc5afnyZ9JVY3SAoUbT3kEQnA+sEsxFExxXVeX2vwu3bCqzsxe9Gsme+JvMsNWz3a6UD B7jV9v1hSMj7FPsB7ZhF1OebdX0S5ET8cPPjqMY8imVeHueSP+vgwCB0ZbIyNcxAhATb o009gD1+QVZkRwrydl9wuF5EZWUxkPy6CnrBGt80vMZ+y7VJzUHplvVoPYcL2bsosDkI uK9FY3pXHqvzSgOL4GUqrVpiFJHKVAZnXDpuAhuU5J2vh/7+TidwtDokYVtRLdEQFQyf MqJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=36+dKm/E6rKkPz0Xzr6rJeMpzRX7hk5tPwO7/mBOkfg=; b=jyLt1sSC3MFv8fEbzeeflU3qS+p8OVGeck8fUO4T9ZAsYBFDFbcYQNfqLdGbDR6rCC gR0WaGSV8VP3O0LeE9kU5QoVj0zLTThdQF0ErehMOWVeNH9gpedyoUhLO1AbemsP8Nel dvLt7eMhSQl+nQEDEyI5+EpHoag6iQ99KFvz0qTBt3lG+0HgTg4npFh1gUyYdXdY6iLM v/PcM1tGcTWnjH2GLvYCeRpOc56bCyCwOGUlOaNeq/m81ulEmhVd2oHlqBDSL40V5FQr fP19Crn02W/ZZFoT3/sTxzbTw2sh0nyV+r+j55kzsFO8qzyPFAVSsBbS3utddQeeu6uW ZZvw== X-Gm-Message-State: AElRT7G/7UHCYMNkmFX0KRV+C1RRo2dEVvHsyH600O4sRzKop/Qt5Oew sE58ShsLHoGozlXDmf+ZcZqUgA== X-Received: by 10.101.97.139 with SMTP id c11mr13839282pgv.447.1521594743790; Tue, 20 Mar 2018 18:12:23 -0700 (PDT) Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id x128sm5100063pgb.31.2018.03.20.18.12.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 18:12:22 -0700 (PDT) Date: Tue, 20 Mar 2018 18:12:22 -0700 (PDT) X-Google-Original-Date: Tue, 20 Mar 2018 18:07:09 PDT (-0700) Subject: Re: [PATCH] of: Respect CONFIG_CMDLINE{,_EXTENED,_FORCE) with no chosen node In-Reply-To: <20180318125150.3i54r7i5edefbhfq@rob-hp-laptop> CC: frowand.list@gmail.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Clark , trung.tran@ettus.com, mdf@kernel.org From: Palmer Dabbelt To: robh@kernel.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 18 Mar 2018 05:51:50 PDT (-0700), robh@kernel.org wrote: > On Wed, Mar 14, 2018 at 09:31:05AM -0700, Palmer Dabbelt wrote: >> Systems that boot without a chosen node in the device tree should still >> respect the command lines that are built into the kernel. This patch >> avoids bailing out of the command line argument parsing code when there >> is no chosen node in the device tree. This is necessary to boot >> straight to a root file system (ie, without an initramfs) >> >> The intent here is that the only functional change is to copy >> CONFIG_CMDLINE into data if both of them are valid (ie, CONFIG_CMDLINE >> is defined and data is non-null) on systems where there is no chosen >> device tree node. I don't actually know what the return values do so I >> just preserved them. >> >> Thanks to Trung and Moritz for finding the bug during our ELC hackathon >> (and providing the first fix), and Michal for suggesting this fix (which >> is cleaner than what I was doing). I've given this very minimal >> testing: it fixes the RISC-V bug (in conjunction with a patch to move >> from COMMANDLINE_OVERRIDE to COMMANDLINE_FORCE), still works on systems >> with and without the chosen node, and builds on ARM64. >> >> CC: Michael J Clark >> CC: Trung Tran >> CC: Moritz Fischer >> Signed-off-by: Palmer Dabbelt >> --- >> drivers/of/fdt.c | 14 ++++++++++++-- >> 1 file changed, 12 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c >> index 84aa9d676375..60241b1cb024 100644 >> --- a/drivers/of/fdt.c >> +++ b/drivers/of/fdt.c >> @@ -1084,9 +1084,12 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname, >> >> pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname); >> >> - if (depth != 1 || !data || >> + if (!data) >> + goto no_data; > > Just "return 0" here. > >> + >> + if (depth != 1 || >> (strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0)) >> - return 0; >> + goto no_chosen; >> >> early_init_dt_check_for_initrd(node); >> >> @@ -1117,6 +1120,13 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname, >> >> /* break now */ >> return 1; >> + >> +no_chosen: >> +#ifdef CONFIG_CMDLINE >> + strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE); > > Best case, this is going to needlessly copy the string on every single > node that is not /chosen. > > Worst case, I think this changes behavior. For example, first you copy > CONFIG_CMDLINE into data, then on a later iteration, you strlcat > CONFIG_CMDLINE into data if CONFIG_CMDLINE_EXTEND is enable. There could > also be some unintended behavior if data has a string to start with. Ah, sorry, I guess I wasn't paying attention -- I assumed this was only called for the relevant node (like the rest of the device tree stuff), and that chosel was just somewhere inside it. > I'd really like to see this function re-written to just find the /chosen > node and then handle each property one by one. The iterating approach is > silly. I assume it predates libfdt and we didn't have nice functions to > find nodes by path (or any other way). > > I'm working on a patch to re-structure this function. Will send it out > in the next day. > >> +#endif >> +no_data: >> + return 0; >> } >> >> #ifdef CONFIG_HAVE_MEMBLOCK >> -- >> 2.16.1 Thanks. Do you mind CCing me on it? Then I'll figure out a way to make sure our command lines still work.