From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CDF79EB64DC for ; Thu, 20 Jul 2023 07:09:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PvC8lVOvDJr0Aey2Cq8hyR6SdRAADpKy8L1DSOndJMM=; b=L16/LLovDQr9ua iIzvBYhc/BztXRRa8bRNQ/jn4siFIt9ilIg1s3n6q4hDsGqJbxh4STMs49NsMg//8JMKnnMg+NQLX +Hkh4Q41rQBS9oV+gnB4czHo+CStsMjU/tUNWsXZ/Jt7Mox/HbSz5hK9UyISdLzKzK0/4tKUe7DDC +4Uyj2DbdM7v47KcVSJenoot/HhL/dLOXnRo/kMGQDveLOdsM+d4ghAEr3VuIo8XYeUYCCGbyac1b mmdpThtK5iEi3JHMSh/+dVab1HEvOEyQziGWu4kbSQFOLG0/nrCOrftHo/EWOUp2Qj6fs1VOVp+kT Fvb3PpIBMXRiLwniZNcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qMNmi-00A3ui-0o; Thu, 20 Jul 2023 07:09:12 +0000 Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1qMNmf-00A3ta-0l; Thu, 20 Jul 2023 07:09:09 +0000 Date: Thu, 20 Jul 2023 00:09:09 -0700 From: Christoph Hellwig To: Daniel Golle Cc: Jens Axboe , Ulf Hansson , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Dave Chinner , Matthew Wilcox , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Jan Kara , Damien Le Moal , Ming Lei , Min Li , Christian Loehle , Adrian Hunter , Hannes Reinecke , Jack Wang , Florian Fainelli , Yeqi Fu , Avri Altman , Hans de Goede , Ye Bin , Greg Kroah-Hartman , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org Subject: Re: [RFC PATCH 0/6] nvmem: add block device NVMEM provider Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Wed, Jul 19, 2023 at 11:01:14PM +0100, Daniel Golle wrote: > This series is meant to open the discussion on how exactly the device tree > schema for block devices and partitions may look like, and even if using > the block layer to back the NVMEM device is at all the way to go -- to me > it seemed to be a good solution because it will be reuable e.g. for NVMe. If only NVMe did something sane there. NVMe copied the completely idiotic idea of boot partitions from eMMC/SD, and made it even worse by first requiring bit banged register access for them, and now adding a weird admin command to read them, which is not bound to a block device. If we want to support that in NVMe we'll need code in the nvme core, but I hope we can avoid it and no one sane (that is everyone but the completely clueless BIOS people at Intel) will never use this completely fucked up boot partition concept. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/