linux-kernel - Re: [PATCH 3/5] ARM: dts: introduce MPS2 AN385/AN386

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <571E2110.2070705@arm.com>
Date:	Mon, 25 Apr 2016 14:52:16 +0100
From:	Sudeep Holla <sudeep.holla@....com>
To:	Vladimir Murzin <vladimir.murzin@....com>
Cc:	Arnd Bergmann <arnd@...db.de>, Sudeep Holla <sudeep.holla@....com>,
	Matthias Brugger <mbrugger@...e.com>,
	lorenzo.pieralisi@....com, linux@....linux.org.uk,
	liviu.dudau@....com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 3/5] ARM: dts: introduce MPS2 AN385/AN386



On 25/04/16 13:03, Vladimir Murzin wrote:
> On 25/04/16 12:32, Arnd Bergmann wrote:
>> On Monday 25 April 2016 11:15:35 Vladimir Murzin wrote:
>>>>> +
>>>>> +#include "mps2.dtsi"
>>>>> +
>>>>> +/ {
>>>>> +    model = "ARM MPS2 Application Note 385/386";
>>>>> +    compatible = "arm,mps2";
>>>>> +
>>>>> +    aliases {
>>>>> +        serial0 = &uart0;
>>>>> +    };
>>>>> +
>>>>> +    chosen {
>>>>> +        bootargs = "rdinit=/sbin/init earlycon";
>>>>
>>>> The rootfs should be independent from the board.
>>>> In my opinion, this type of bootargs should not be part of the DTS.
>>>
>>> I have no strong opinion on this, but quick grep shows plenty places
>>> where the same happens, and even [1] has rootfs specific option as an
>>> example. So if there is no strong call to remove rdinit from bootargs,
>>> I'd prefer to keep it as it makes testing easier for me.
>>>
>>> [1] Documentation/devicetree/booting-without-of.txt
>>>
>>
>> I think "rdinit=/sbin/init" is redundant, that is what we try running
>> anyway, so I don't see any downside in removing it.
>
> Fair point.
>
> @Sudeep could you fixup it locally or I need to respin?
>

Done and pushed, will send PR later today.

-- 
Regards,
Sudeep