From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 009.lax.mailroute.net (009.lax.mailroute.net [199.89.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8438679924; Fri, 22 Mar 2024 19:22:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=199.89.1.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711135366; cv=none; b=cpA1MGiGVNI+w6NC+W2rTlblHMn8y26BIyqjzaZtGyfeYKl3ocllALq7PXhx2EC0CW6M38FF8PRKNOzAGROgxhLDJhrQ6/jW6ch8z0QsnvfA70MR8Gv8eHTbnP+FLolqFzyVpDskE16+8H0Czdv6WGuRHAYm6OcGyraYjc4Oh2k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711135366; c=relaxed/simple; bh=BUz5hK96G+jleUn15ldF4ameZxFw2z69VYrq+t9w4a4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Pb6TN6gUJzJX3/4ku9CCD8ax/sVUOQFpA+IWFgfmGv+N6KFJjOZBV/ruOz6CJxM+LU3IovkuzdzhqoG5r1QrpGgNIro7/IyWglGwvwLZFNzbp2hk9q4kSpY7IpqRldRw11zz5wsmKCWeBzEUGchyJdfzAUHgoxymDfC7dT38wb8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=acm.org; spf=pass smtp.mailfrom=acm.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b=RBf0ivVv; arc=none smtp.client-ip=199.89.1.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=acm.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=acm.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b="RBf0ivVv" Received: from localhost (localhost [127.0.0.1]) by 009.lax.mailroute.net (Postfix) with ESMTP id 4V1XKH5p80zlgVnF; Fri, 22 Mar 2024 19:22:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=mr01; t=1711135355; x=1713727356; bh=FI4Z6ZgHS15qtNLhRTTVJj5+ StHISvSkt2DHgw+Aldg=; b=RBf0ivVv7aAbjp3GUFo3+Fb23Fs8iMz79BTY+mUS EarP+Luey+lgFSgqlWVpFMnI8934ZRjKGYBsQPV0/uDEF2I/ioeqPDiIvStU5EQy YZy4csacStuJhxZhB+s2GHvbfAoqE3BlM720eGX2QDh6zyTAewKYwV7f5FHKF80Z HtHD2I1z8V+3I7isZfr9IQkxE2RLv9bhUeo5VRAWnkbLZButB2Neg0khwa3NnKF+ nvkiPImFUpBkLDtJGfA1ADUzwaZVe0tU5craHZgAmX7UgaX6QOIzvePFsy66yZb7 rC6fXjyxw3vKuN3wV+nx5gx9Ax294Tdaam87uhfxQBAxuA== X-Virus-Scanned: by MailRoute Received: from 009.lax.mailroute.net ([127.0.0.1]) by localhost (009.lax [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id GAB01t24zNHL; Fri, 22 Mar 2024 19:22:35 +0000 (UTC) Received: from [100.96.154.173] (unknown [104.132.1.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bvanassche@acm.org) by 009.lax.mailroute.net (Postfix) with ESMTPSA id 4V1XK5106BzlgTGW; Fri, 22 Mar 2024 19:22:33 +0000 (UTC) Message-ID: <192acb8f-47b8-426c-bcc9-ef214a797f26@acm.org> Date: Fri, 22 Mar 2024 12:22:32 -0700 Precedence: bulk X-Mailing-List: linux-mmc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/8] block: add new genhd flag GENHD_FL_NVMEM Content-Language: en-US To: Daniel Golle Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Ulf Hansson , Jens Axboe , Dave Chinner , Jan Kara , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , Damien Le Moal , Li Lingfeng , Christian Brauner , Christian Heusel , Min Li , Adrian Hunter , Avri Altman , Hannes Reinecke , Christian Loehle , Bean Huo , Yeqi Fu , Victor Shih , Christophe JAILLET , Dominique Martinet , "Ricardo B. Marliere" , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, linux-block@vger.kernel.org References: <89abd9ab93783da0e8934ebc03d66559f78f6060.1711048433.git.daniel@makrotopia.org> <7027ccdc-878a-420e-a7ea-5156e1d67b8a@acm.org> From: Bart Van Assche In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/22/24 11:07, Daniel Golle wrote: > On Fri, Mar 22, 2024 at 10:49:48AM -0700, Bart Van Assche wrote: >> On 3/21/24 12:33, Daniel Golle wrote: >>> enum { >>> GENHD_FL_REMOVABLE = 1 << 0, >>> GENHD_FL_HIDDEN = 1 << 1, >>> GENHD_FL_NO_PART = 1 << 2, >>> + GENHD_FL_NVMEM = 1 << 3, >>> }; >> >> What would break if this flag wouldn't exist? > > As both, MTD and UBI already act as NVMEM providers themselves, once > the user creates a ubiblock device or got CONFIG_MTD_BLOCK=y set in their > kernel configuration, we would run into problems because both, the block > layer as well as MTD or UBI would try to be an NVMEM provider for the same > device tree node. Why would both MTD and UBI try to be an NVMEM provider for the same device tree node? Why can't this patch series be implemented such that a partition UUID occurs in the device tree and such that other code scans for that partition UUID? Thanks, Bart.