Received: by 10.223.185.116 with SMTP id b49csp5576986wrg; Wed, 7 Mar 2018 14:19:29 -0800 (PST) X-Google-Smtp-Source: AG47ELsWPSQu/+BWG6bKM17dSlXUtM3nmd0nKITimBEanq6MWZYanl2Jvj1caAUtKmrlXVuJA+09 X-Received: by 2002:a17:902:c24:: with SMTP id 33-v6mr21871198pls.24.1520461169370; Wed, 07 Mar 2018 14:19:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520461169; cv=none; d=google.com; s=arc-20160816; b=CesHiUgJyi4hthcG/tMfFBNZ1h7M5Be/j+KAS5O87OF3nREZz2hVb2D6jOFbzm7QBN 4pxAOmzO7nkWjalrxatnk6pRDM9pIasgVSKbw53mboRJDhd5EIzW7yPcAa1+4aqzyDcV ZA7IV41Vljv5gx+D/jazmM3JXoO1Z88XB40q8XHtuYOJ99sD9qOOuXmOnixjIaH3xB53 BZq3Cgi1HSt84WxsqJ9G/m6af2Sg5D8b1X+zREPLnEvTu5ZtgnT3AfCU+9lRV3Z/dW93 SHlKXi/UUEMSKcdKCW+x+cqa66JL/JBEtWiOXyd3dtCQSuv+mJDgXCIxNWCfcA6OKZsI n0KA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=1oHDBq1BpemT29ShMxvTnOyujmtpwENZxNTdpWuiCa0=; b=gavjoQ+6whM30Sv2hNSJaZL1qbSbnaAvihZfyrlgP5x5VNNw2Q75EV3erhQA3HRYuB EmtzjEzJhI2mzq7213b/BDAo7VJjtD9pe0Thp6UAABz4r/9WvFNBhNAd/gMxxNcB/g+l /fVbSGM88j+5eDh4QIk3ixnJBAjaoJ10Z8tdUrZOe3F0RftidWrD9/v6EZgO6rsZxDPD dI7SscY7zMu1MSS71Ut+9IgjgsqTLrzNM3SsorI3Gy2Rzfy511zynZ1T4WSQNc0eJqIa J1m0HljiaTTBUFq+VFuC+/4DKYpWf5ed+pE2yZOUiab7Q50EY2GbU6Qr7a3NihR5m8+P RkiQ== ARC-Authentication-Results: i=1; mx.google.com; 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 y1si14651497pfg.297.2018.03.07.14.19.15; Wed, 07 Mar 2018 14:19:29 -0800 (PST) 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; 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 S1754900AbeCGWRg (ORCPT + 99 others); Wed, 7 Mar 2018 17:17:36 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:59640 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754039AbeCGWRf (ORCPT ); Wed, 7 Mar 2018 17:17:35 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id C0E5C8028C; Wed, 7 Mar 2018 23:17:33 +0100 (CET) Date: Wed, 7 Mar 2018 23:17:33 +0100 From: Pavel Machek To: David Woodhouse , Greg KH Cc: Steve deRosier , Richard Weinberger , Boris Brezillon , dedekind1@gmail.com, tharvey@gateworks.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org, marek.vasut@gmail.com, linux-mtd@lists.infradead.org, cyrille.pitchen@wedev4u.fr, computersforpeace@gmail.com Subject: Re: [PATCH] ubi: Reject MLC NAND Message-ID: <20180307221733.GE10438@amd> References: <20180303104554.5958-1-richard@nod.at> <20180306231805.GA28183@amd> <6772577.AmT7QaWTNU@blindfold> <20180307214342.GA9852@amd> <1520460673.31298.136.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1520460673.31298.136.camel@infradead.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2018-03-07 22:11:13, David Woodhouse wrote: > > > On Wed, 2018-03-07 at 14:08 -0800, Steve deRosier wrote: > > > > To clarify one thing: the reason for this is MLC has actually never > > been supported, nor worked properly. The fact that it kinda worked was > > incidental and the cause of major problems for people due to that not > > being clear. This patch only makes it explicit and avoids people > > mistakenly trying to use UBIFS on MLC flash and risking their data and > > products. To me, that's what's important. > > > > This is an important patch, even if all it does is keep people from > > loosing data. It also changes the conversation from "I have a > > corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get > > UBIFS to work on MLC". Well, for -stable I'd suggest printk(KERN_ALERT ...) but keep the system running. > This is a bug fix. > > UBI on MLC never worked. It was a bug that we ever permitted it. This > is now fixed. Yeah, well, so lets say I have a working hardware (maybe using read-only UBI on MLC), update to next stable kernel, and now kernel refuses to see the partition. I'll certainly not consider this patch a bug fix. Removing support for hardware that "only works by mistake" may be good idea, but maybe it is slightly too surprising for a -stable. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html