Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752708AbeAQJpf (ORCPT + 1 other); Wed, 17 Jan 2018 04:45:35 -0500 Received: from 9.mo178.mail-out.ovh.net ([46.105.75.45]:39970 "EHLO 9.mo178.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbeAQJpN (ORCPT ); Wed, 17 Jan 2018 04:45:13 -0500 X-Greylist: delayed 2692 seconds by postgrey-1.27 at vger.kernel.org; Wed, 17 Jan 2018 04:45:13 EST MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 17 Jan 2018 09:20:11 +0100 From: =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= To: Boris Brezillon Cc: Peter Rosin , Richard Weinberger , Brian Norris , David Woodhouse , Marek Vasut , Cyrille Pitchen , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [REGRESSION] linux-next panics when trying to mount root In-Reply-To: <20180116163032.54a392c7@bbrezillon> References: <574b1571-1664-f09f-62bf-48f7f94a51cd@axentia.se> <20180116143651.04bca70f@bbrezillon> <20180116152138.18a114d6@bbrezillon> <6a51ff05-89ed-cd57-6d90-3af51c7ce619@axentia.se> <20180116163032.54a392c7@bbrezillon> Message-ID: <0d3201d921386c32d2b65b3b7d3e10e7@milecki.pl> User-Agent: Roundcube Webmail/1.3.4 X-Originating-IP: 194.187.74.233 X-Webmail-UserID: rafal@milecki.pl X-Ovh-Tracer-Id: 523543456746278601 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtvddrtddugdduvdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 2018-01-16 16:30, Boris Brezillon wrote: > On Tue, 16 Jan 2018 16:02:35 +0100 > Peter Rosin wrote: > >> On 2018-01-16 15:21, Boris Brezillon wrote: >> > On Tue, 16 Jan 2018 14:56:52 +0100 >> > Peter Rosin wrote: >> > >> >> Hmmm, I guess the question is if the command line should override the >> >> device tree or not? >> > >> > Yep, that's the problem. Now the core parses the compatible to decides >> > which part parser should be used. The thing is, the "cmdline" parser is >> > not yet exposing a compatible id, and even if it was, this would >> > require patching all DTs to add this new compatible. >> > >> > partitions { >> > compatible = "cmdline", "fixed-partitions"; >> > ... >> > }; >> > >> > Not really an option, so I'll drop the 2 patches for now until we find a >> > better solution. >> > >> >> I'm going to send a patch for the above dts change either way... >> > >> > If you want, but that does not solve the problem: we should not break >> > existing users. >> >> Well, don't let these devices stop you, they will not get a new kernel >> w/o also getting a new dtb, and I can handle this just fine. But maybe >> I'm just the first reporter and you'd rather not risk anything? >> Anyway, >> just wanted to let you know where I stand... > > Unfortunately, at91 is not the only platform to have "fixed-partitions" > defined in its DTs, and I guess users of other platforms also like to > override the default MTD layout by their own using mtdparts.I'd like to > find a solution that keeps everyone happy. I absolutely agree with Boris, we can't risk such regressions. That had to be dropped and I'm looking for a better solution.