From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (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 8B1A2153804; Tue, 9 Jul 2024 09:43:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720518192; cv=none; b=Tbd6w/9fSNdSwg6Jz8VSg96E1yofs0zXMD/LraWqwQt9x2H1lEC+V9mTpDBhU01fn0600RWDHqnotmBvL8QDLAbOgXEyaoQn0gCoAydj762dlpCweQX3b5eHJjp2EwAl+kptOEqzanbNuCCGWuzLc2nuzCZB0WGRAMeitasGiaA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720518192; c=relaxed/simple; bh=Z0HcHq7yzl+7AelddnrRR87bt+aU2j10VpepG5UbVu4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QiIvcl/KpeNm9lruFLKb7tmg/xYQRtik47v1Jh1DKMPp2Rj87zK5Lm/Im0TFsXN/vvQ9QqCwiU6VOcHmG+o82smL97vjmK6BOD/Y1TMkrZLHdiEGyZKiC4kAyMOH8YHtBE2kwehQ+TN7HofP/6r3uJNvBcDBrWrXBcrCSgQ4U/w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=pS12M/hF; arc=none smtp.client-ip=217.70.183.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="pS12M/hF" Received: by mail.gandi.net (Postfix) with ESMTPSA id 896761BF20E; Tue, 9 Jul 2024 09:43:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1720518188; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WVMmtSjwlNQmVjxtUeUdR3iKhz4W+lQLl2pkn1Xk12k=; b=pS12M/hFFtUvUahs26E5vD/JZJjIQ8CmyPf5kCaaSJzFbR3RDeMCaG4WkQ18U83Kje7Xfl AyN919sqdbsVTsmreQhwHSygXqgRJ0kdPQ5zjcJUGtxlT4Ho9p8ijdF8YfTeIO6HFDK7eO 9ZWZUOd5wpLbo4/rkrKRN8+RnXilQYghyruJzJG1B0By1AlkPDEswaoM56ChbKqR9xzmtO jhtQebyqSJwnet2P69DvwaCq24fYzhp/MVzppGLvK1eJdhxGBanp5/LzDMV65mb+L+itk6 lQKaVcgNUEyq8U3sZF8TqV+3RTbRtu+1Gi6vNNP28kc9H4uebjsO4mk9Ei94yg== Date: Tue, 9 Jul 2024 11:43:02 +0200 From: Miquel Raynal To: Marco Felsch Cc: Maxime Ripard , Pratyush Yadav , Tudor Ambarus , Richard Weinberger , Vignesh Raghavendra , Arnd Bergmann , Greg Kroah-Hartman , Bartosz Golaszewski , Russell King , Joel Stanley , Andrew Jeffery , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Vladimir Zapolskiy , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Tony Lindgren , Geert Uytterhoeven , Magnus Damm , Dinh Nguyen , Thierry Reding , Jonathan Hunter , Jonathan =?UTF-8?B?TmV1c2Now6RmZXI=?= , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Naveen N. Rao" , Thomas Bogendoerfer , Huacai Chen , WANG Xuerui , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, imx@lists.linux.dev, linux-omap@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org, openbmc@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org, linux-mips@vger.kernel.org, loongarch@lists.linux.dev Subject: Re: [PATCH 4/9] mtd: devices: add AT24 eeprom support Message-ID: <20240709114302.3c604ef3@xps-13> In-Reply-To: <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240701-b4-v6-10-topic-usbc-tcpci-v1-4-3fd5f4a193cc@pengutronix.de> <07b701a9-7b52-45b7-8dba-1c25d77cbf15@linaro.org> <20240702-congenial-vigilant-boar-aeae44@houat> <20240702-mighty-brilliant-eel-b0d9fa@houat> <20240708084440.70186564@xps-13> <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Hi Marco, > > > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggestin= g adding > > > > >> EEPROMs to MTD [1]. The main purpose would have been unifying th= e EEPROM > > > > >> drivers under a single interface. I am not sure what came of it = though, > > > > >> since I can't find any patches that followed up with the proposa= l. =20 > > > > > > > > > > That discussion led to drivers/nvmem after I started to work on > > > > > some early prototype, and Srinivas took over that work. =20 > > > >=20 > > > > So would you say it is better for EEPROM drivers to use nvmem inste= ad of > > > > moving under MTD? =20 > > >=20 > > > I thought so at the time, but that was more than 10y ago, and I have > > > followed neither nvmem nor MTD since so I don't really have an opinion > > > there. > > >=20 > > > It looks like drivers/misc/eeprom/at24.c has support for nvmem though, > > > and MTD can be used as an nvmem provider too, so it's not clear to me > > > why we would want to create yet another variant. > > >=20 > > > But again, you shouldn't really ask me in the first place :) > > >=20 > > > I'm sure Miquel, Srinivas, and surely others, are much more relevant = to > > > answer that question. =20 > >=20 > > More relevant, I doubt, but just a feeling: EEPROMs have their own > > subsystem now, NVMEM, which, as Maxime said, was initially written for > > that very specific case. EEPROMs don't have the complexity of MTD > > devices, and thus pulling the whole MTD subsystem just for getting > > partitions seems counter intuitive to me. You can definitely "split" > > EEPROM devices with NVMEM as well anyway. =20 >=20 > I asked for feedback on my RFC [1] and all I got was to merge both > drivers into one and make the driver backward compatible, which I did by > this commit. I'm sorry for not bringing this earlier. > > Overall I think the idea of getting rid of these misc/ drivers is goes > > into the right direction, but registering directly into NVMEM makes > > more sense IMO. =20 >=20 > So you propose to have two places for the partition handling (one for > MTD and one for NVMEM) instead of one and moving the code into NVMEM > directly? Why two places for the partitions handling? Just one, in NVMEM. Also usually EEPROMs don't require very advanced partitioning schemes, unlike flashes (which are the most common MTD devices today). > That doesn't sound right to me either. Also I don't get the > point why EEPROMs can't be handled by the MTD layer? They can, but should they? Just compile the two layers and observe the size difference. MTD is complex and old, carries a lot of history, and the user interface is also not straightforward because you need to handle pages, blocks, erases, bitflips, ECC stats, OOB bytes and positions, two OTP areas... None of that exists in the EEPROM world. So why would you want to register into MTD and pull a huge subsystem while there is a much more recent, simpler and way lighter subsystem fitting much better your device? > The layer already > supports devices of type MTD_RAM which are very simple and don't require > an erase-op at least I don't see one. MTD_RAM has been there forever, probably for "bad" reasons. BTW there has been an attempt at removing it which was reverted in _2006_ and then felt into the cracks: 21c8db9eff95 ("[MTD] Restore MTD_ROM and MTD_RAM types") Thanks, Miqu=C3=A8l From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Tue, 09 Jul 2024 09:43:24 -0000 Subject: [PATCH 4/9] mtd: devices: add AT24 eeprom support In-Reply-To: <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240701-b4-v6-10-topic-usbc-tcpci-v1-4-3fd5f4a193cc@pengutronix.de> <07b701a9-7b52-45b7-8dba-1c25d77cbf15@linaro.org> <20240702-congenial-vigilant-boar-aeae44@houat> <20240702-mighty-brilliant-eel-b0d9fa@houat> <20240708084440.70186564@xps-13> <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> Message-ID: <20240709114302.3c604ef3@xps-13> List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Marco, > > > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting adding > > > > >> EEPROMs to MTD [1]. The main purpose would have been unifying the EEPROM > > > > >> drivers under a single interface. I am not sure what came of it though, > > > > >> since I can't find any patches that followed up with the proposal. > > > > > > > > > > That discussion led to drivers/nvmem after I started to work on > > > > > some early prototype, and Srinivas took over that work. > > > > > > > > So would you say it is better for EEPROM drivers to use nvmem instead of > > > > moving under MTD? > > > > > > I thought so at the time, but that was more than 10y ago, and I have > > > followed neither nvmem nor MTD since so I don't really have an opinion > > > there. > > > > > > It looks like drivers/misc/eeprom/at24.c has support for nvmem though, > > > and MTD can be used as an nvmem provider too, so it's not clear to me > > > why we would want to create yet another variant. > > > > > > But again, you shouldn't really ask me in the first place :) > > > > > > I'm sure Miquel, Srinivas, and surely others, are much more relevant to > > > answer that question. > > > > More relevant, I doubt, but just a feeling: EEPROMs have their own > > subsystem now, NVMEM, which, as Maxime said, was initially written for > > that very specific case. EEPROMs don't have the complexity of MTD > > devices, and thus pulling the whole MTD subsystem just for getting > > partitions seems counter intuitive to me. You can definitely "split" > > EEPROM devices with NVMEM as well anyway. > > I asked for feedback on my RFC [1] and all I got was to merge both > drivers into one and make the driver backward compatible, which I did by > this commit. I'm sorry for not bringing this earlier. > > Overall I think the idea of getting rid of these misc/ drivers is goes > > into the right direction, but registering directly into NVMEM makes > > more sense IMO. > > So you propose to have two places for the partition handling (one for > MTD and one for NVMEM) instead of one and moving the code into NVMEM > directly? Why two places for the partitions handling? Just one, in NVMEM. Also usually EEPROMs don't require very advanced partitioning schemes, unlike flashes (which are the most common MTD devices today). > That doesn't sound right to me either. Also I don't get the > point why EEPROMs can't be handled by the MTD layer? They can, but should they? Just compile the two layers and observe the size difference. MTD is complex and old, carries a lot of history, and the user interface is also not straightforward because you need to handle pages, blocks, erases, bitflips, ECC stats, OOB bytes and positions, two OTP areas... None of that exists in the EEPROM world. So why would you want to register into MTD and pull a huge subsystem while there is a much more recent, simpler and way lighter subsystem fitting much better your device? > The layer already > supports devices of type MTD_RAM which are very simple and don't require > an erase-op at least I don't see one. MTD_RAM has been there forever, probably for "bad" reasons. BTW there has been an attempt at removing it which was reverted in _2006_ and then felt into the cracks: 21c8db9eff95 ("[MTD] Restore MTD_ROM and MTD_RAM types") Thanks, Miqu?l 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 BCF90C2BD09 for ; Tue, 9 Jul 2024 09:43:17 +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:MIME-Version:References:In-Reply-To: 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=pecYdA/1mxN3eViFWePQly9bT6MEn0Qt2hWcvmrSVNs=; b=TGWm6Vzg/K6BXC 0rxYTDlQJdQ55xvDk3MtfFNRaWEMp91VbpQ/D64I6VmvKuqHOzN4axpuNcCN9i31QUelV3K5FULJc 0xZQcV8jXVM5NqwtFk7m5HjIy/aXSbeyhmn6kmE/+iToHL9D9S6hGqjDzdYWlPyxOjZMEg5IHLhG5 IWsWm0gxRKzCEU6+L/XpuDw7KR+bulxwh6E+RgINPpjwlDSE6nRYdVuH5MeTZFSKX94gao0sBmMFz 3x9kkNGV0cfRKRiKC0Q0sPISsK953ZQs08lQMpB3W6o9HGgPk16ic7CQuOpcabULM3IpAWE2Q6fMR A78vLRg7cTf9Hue/Cz0w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sR7NT-00000006f4Q-1Dmk; Tue, 09 Jul 2024 09:43:15 +0000 Received: from relay8-d.mail.gandi.net ([217.70.183.201]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sR7NO-00000006f2W-2uFi; Tue, 09 Jul 2024 09:43:12 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 896761BF20E; Tue, 9 Jul 2024 09:43:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1720518188; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WVMmtSjwlNQmVjxtUeUdR3iKhz4W+lQLl2pkn1Xk12k=; b=pS12M/hFFtUvUahs26E5vD/JZJjIQ8CmyPf5kCaaSJzFbR3RDeMCaG4WkQ18U83Kje7Xfl AyN919sqdbsVTsmreQhwHSygXqgRJ0kdPQ5zjcJUGtxlT4Ho9p8ijdF8YfTeIO6HFDK7eO 9ZWZUOd5wpLbo4/rkrKRN8+RnXilQYghyruJzJG1B0By1AlkPDEswaoM56ChbKqR9xzmtO jhtQebyqSJwnet2P69DvwaCq24fYzhp/MVzppGLvK1eJdhxGBanp5/LzDMV65mb+L+itk6 lQKaVcgNUEyq8U3sZF8TqV+3RTbRtu+1Gi6vNNP28kc9H4uebjsO4mk9Ei94yg== Date: Tue, 9 Jul 2024 11:43:02 +0200 From: Miquel Raynal To: Marco Felsch Cc: Maxime Ripard , Pratyush Yadav , Tudor Ambarus , Richard Weinberger , Vignesh Raghavendra , Arnd Bergmann , Greg Kroah-Hartman , Bartosz Golaszewski , Russell King , Joel Stanley , Andrew Jeffery , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Vladimir Zapolskiy , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Tony Lindgren , Geert Uytterhoeven , Magnus Damm , Dinh Nguyen , Thierry Reding , Jonathan Hunter , Jonathan =?UTF-8?B?TmV1c2Now6RmZXI=?= , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Naveen N. Rao" , Thomas Bogendoerfer , Huacai Chen , WANG Xuerui , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, imx@lists.linux.dev, linux-omap@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org, openbmc@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org, linux-mips@vger.kernel.org, loongarch@lists.linux.dev Subject: Re: [PATCH 4/9] mtd: devices: add AT24 eeprom support Message-ID: <20240709114302.3c604ef3@xps-13> In-Reply-To: <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240701-b4-v6-10-topic-usbc-tcpci-v1-4-3fd5f4a193cc@pengutronix.de> <07b701a9-7b52-45b7-8dba-1c25d77cbf15@linaro.org> <20240702-congenial-vigilant-boar-aeae44@houat> <20240702-mighty-brilliant-eel-b0d9fa@houat> <20240708084440.70186564@xps-13> <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240709_024311_025224_7F7C71BA X-CRM114-Status: GOOD ( 34.75 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org SGkgTWFyY28sCgo+ID4gPiA+ID4+IEkgYWxzbyBmb3VuZCBhIHRocmVhZCBmcm9tIDIwMTMgYnkg TWF4aW1lIFJpcGFyZCAoK0NjKSBzdWdnZXN0aW5nIGFkZGluZwo+ID4gPiA+ID4+IEVFUFJPTXMg dG8gTVREIFsxXS4gVGhlIG1haW4gcHVycG9zZSB3b3VsZCBoYXZlIGJlZW4gdW5pZnlpbmcgdGhl IEVFUFJPTQo+ID4gPiA+ID4+IGRyaXZlcnMgdW5kZXIgYSBzaW5nbGUgaW50ZXJmYWNlLiBJIGFt IG5vdCBzdXJlIHdoYXQgY2FtZSBvZiBpdCB0aG91Z2gsCj4gPiA+ID4gPj4gc2luY2UgSSBjYW4n dCBmaW5kIGFueSBwYXRjaGVzIHRoYXQgZm9sbG93ZWQgdXAgd2l0aCB0aGUgcHJvcG9zYWwuICAg IAo+ID4gPiA+ID4KPiA+ID4gPiA+IFRoYXQgZGlzY3Vzc2lvbiBsZWQgdG8gZHJpdmVycy9udm1l bSBhZnRlciBJIHN0YXJ0ZWQgdG8gd29yayBvbgo+ID4gPiA+ID4gc29tZSBlYXJseSBwcm90b3R5 cGUsIGFuZCBTcmluaXZhcyB0b29rIG92ZXIgdGhhdCB3b3JrLiAgICAKPiA+ID4gPiAKPiA+ID4g PiBTbyB3b3VsZCB5b3Ugc2F5IGl0IGlzIGJldHRlciBmb3IgRUVQUk9NIGRyaXZlcnMgdG8gdXNl IG52bWVtIGluc3RlYWQgb2YKPiA+ID4gPiBtb3ZpbmcgdW5kZXIgTVREPyAgICAKPiA+ID4gCj4g PiA+IEkgdGhvdWdodCBzbyBhdCB0aGUgdGltZSwgYnV0IHRoYXQgd2FzIG1vcmUgdGhhbiAxMHkg YWdvLCBhbmQgSSBoYXZlCj4gPiA+IGZvbGxvd2VkIG5laXRoZXIgbnZtZW0gbm9yIE1URCBzaW5j ZSBzbyBJIGRvbid0IHJlYWxseSBoYXZlIGFuIG9waW5pb24KPiA+ID4gdGhlcmUuCj4gPiA+IAo+ ID4gPiBJdCBsb29rcyBsaWtlIGRyaXZlcnMvbWlzYy9lZXByb20vYXQyNC5jIGhhcyBzdXBwb3J0 IGZvciBudm1lbSB0aG91Z2gsCj4gPiA+IGFuZCBNVEQgY2FuIGJlIHVzZWQgYXMgYW4gbnZtZW0g cHJvdmlkZXIgdG9vLCBzbyBpdCdzIG5vdCBjbGVhciB0byBtZQo+ID4gPiB3aHkgd2Ugd291bGQg d2FudCB0byBjcmVhdGUgeWV0IGFub3RoZXIgdmFyaWFudC4KPiA+ID4gCj4gPiA+IEJ1dCBhZ2Fp biwgeW91IHNob3VsZG4ndCByZWFsbHkgYXNrIG1lIGluIHRoZSBmaXJzdCBwbGFjZSA6KQo+ID4g PiAKPiA+ID4gSSdtIHN1cmUgTWlxdWVsLCBTcmluaXZhcywgYW5kIHN1cmVseSBvdGhlcnMsIGFy ZSBtdWNoIG1vcmUgcmVsZXZhbnQgdG8KPiA+ID4gYW5zd2VyIHRoYXQgcXVlc3Rpb24uICAKPiA+ IAo+ID4gTW9yZSByZWxldmFudCwgSSBkb3VidCwgYnV0IGp1c3QgYSBmZWVsaW5nOiBFRVBST01z IGhhdmUgdGhlaXIgb3duCj4gPiBzdWJzeXN0ZW0gbm93LCBOVk1FTSwgd2hpY2gsIGFzIE1heGlt ZSBzYWlkLCB3YXMgaW5pdGlhbGx5IHdyaXR0ZW4gZm9yCj4gPiB0aGF0IHZlcnkgc3BlY2lmaWMg Y2FzZS4gRUVQUk9NcyBkb24ndCBoYXZlIHRoZSBjb21wbGV4aXR5IG9mIE1URAo+ID4gZGV2aWNl cywgYW5kIHRodXMgcHVsbGluZyB0aGUgd2hvbGUgTVREIHN1YnN5c3RlbSBqdXN0IGZvciBnZXR0 aW5nCj4gPiBwYXJ0aXRpb25zIHNlZW1zIGNvdW50ZXIgaW50dWl0aXZlIHRvIG1lLiBZb3UgY2Fu IGRlZmluaXRlbHkgInNwbGl0Igo+ID4gRUVQUk9NIGRldmljZXMgd2l0aCBOVk1FTSBhcyB3ZWxs IGFueXdheS4gIAo+IAo+IEkgYXNrZWQgZm9yIGZlZWRiYWNrIG9uIG15IFJGQyBbMV0gYW5kIGFs bCBJIGdvdCB3YXMgdG8gbWVyZ2UgYm90aAo+IGRyaXZlcnMgaW50byBvbmUgYW5kIG1ha2UgdGhl IGRyaXZlciBiYWNrd2FyZCBjb21wYXRpYmxlLCB3aGljaCBJIGRpZCBieQo+IHRoaXMgY29tbWl0 LgoKSSdtIHNvcnJ5IGZvciBub3QgYnJpbmdpbmcgdGhpcyBlYXJsaWVyLgoKPiA+IE92ZXJhbGwg SSB0aGluayB0aGUgaWRlYSBvZiBnZXR0aW5nIHJpZCBvZiB0aGVzZSBtaXNjLyBkcml2ZXJzIGlz IGdvZXMKPiA+IGludG8gdGhlIHJpZ2h0IGRpcmVjdGlvbiwgYnV0IHJlZ2lzdGVyaW5nIGRpcmVj dGx5IGludG8gTlZNRU0gbWFrZXMKPiA+IG1vcmUgc2Vuc2UgSU1PLiAgCj4gCj4gU28geW91IHBy b3Bvc2UgdG8gaGF2ZSB0d28gcGxhY2VzIGZvciB0aGUgcGFydGl0aW9uIGhhbmRsaW5nIChvbmUg Zm9yCj4gTVREIGFuZCBvbmUgZm9yIE5WTUVNKSBpbnN0ZWFkIG9mIG9uZSBhbmQgbW92aW5nIHRo ZSBjb2RlIGludG8gTlZNRU0KPiBkaXJlY3RseT8KCldoeSB0d28gcGxhY2VzIGZvciB0aGUgcGFy dGl0aW9ucyBoYW5kbGluZz8gSnVzdCBvbmUsIGluIE5WTUVNLiBBbHNvCnVzdWFsbHkgRUVQUk9N cyBkb24ndCByZXF1aXJlIHZlcnkgYWR2YW5jZWQgcGFydGl0aW9uaW5nIHNjaGVtZXMsCnVubGlr ZSBmbGFzaGVzICh3aGljaCBhcmUgdGhlIG1vc3QgY29tbW9uIE1URCBkZXZpY2VzIHRvZGF5KS4K Cj4gVGhhdCBkb2Vzbid0IHNvdW5kIHJpZ2h0IHRvIG1lIGVpdGhlci4gQWxzbyBJIGRvbid0IGdl dCB0aGUKPiBwb2ludCB3aHkgRUVQUk9NcyBjYW4ndCBiZSBoYW5kbGVkIGJ5IHRoZSBNVEQgbGF5 ZXI/CgpUaGV5IGNhbiwgYnV0IHNob3VsZCB0aGV5PyBKdXN0IGNvbXBpbGUgdGhlIHR3byBsYXll cnMgYW5kIG9ic2VydmUKdGhlIHNpemUgZGlmZmVyZW5jZS4gTVREIGlzIGNvbXBsZXggYW5kIG9s ZCwgY2FycmllcyBhIGxvdCBvZiBoaXN0b3J5LAphbmQgdGhlIHVzZXIgaW50ZXJmYWNlIGlzIGFs c28gbm90IHN0cmFpZ2h0Zm9yd2FyZCBiZWNhdXNlIHlvdSBuZWVkIHRvCmhhbmRsZSBwYWdlcywg YmxvY2tzLCBlcmFzZXMsIGJpdGZsaXBzLCBFQ0Mgc3RhdHMsIE9PQiBieXRlcyBhbmQKcG9zaXRp b25zLCB0d28gT1RQIGFyZWFzLi4uIE5vbmUgb2YgdGhhdCBleGlzdHMgaW4gdGhlIEVFUFJPTSB3 b3JsZC4gU28Kd2h5IHdvdWxkIHlvdSB3YW50IHRvIHJlZ2lzdGVyIGludG8gTVREIGFuZCBwdWxs IGEgaHVnZSBzdWJzeXN0ZW0gd2hpbGUKdGhlcmUgaXMgYSBtdWNoIG1vcmUgcmVjZW50LCBzaW1w bGVyIGFuZCB3YXkgbGlnaHRlciBzdWJzeXN0ZW0gZml0dGluZwptdWNoIGJldHRlciB5b3VyIGRl dmljZT8KCj4gVGhlIGxheWVyIGFscmVhZHkKPiBzdXBwb3J0cyBkZXZpY2VzIG9mIHR5cGUgTVRE X1JBTSB3aGljaCBhcmUgdmVyeSBzaW1wbGUgYW5kIGRvbid0IHJlcXVpcmUKPiBhbiBlcmFzZS1v cCBhdCBsZWFzdCBJIGRvbid0IHNlZSBvbmUuCgpNVERfUkFNIGhhcyBiZWVuIHRoZXJlIGZvcmV2 ZXIsIHByb2JhYmx5IGZvciAiYmFkIiByZWFzb25zLiBCVFcgdGhlcmUKaGFzIGJlZW4gYW4gYXR0 ZW1wdCBhdCByZW1vdmluZyBpdCB3aGljaCB3YXMgcmV2ZXJ0ZWQgaW4gXzIwMDZfIGFuZCB0aGVu CmZlbHQgaW50byB0aGUgY3JhY2tzOgoyMWM4ZGI5ZWZmOTUgKCJbTVREXSBSZXN0b3JlIE1URF9S T00gYW5kIE1URF9SQU0gdHlwZXMiKQoKVGhhbmtzLApNaXF1w6hsCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXggTVREIGRpc2N1c3Np b24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGlu Zm8vbGludXgtbXRkLwo= 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 D95DFC2BD09 for ; Tue, 9 Jul 2024 09:44:05 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=pS12M/hF; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4WJGKJ3snLz3dJs for ; Tue, 9 Jul 2024 19:44:04 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=pS12M/hF; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=bootlin.com (client-ip=2001:4b98:dc4:8::228; helo=relay8-d.mail.gandi.net; envelope-from=miquel.raynal@bootlin.com; receiver=lists.ozlabs.org) X-Greylist: delayed 97099 seconds by postgrey-1.37 at boromir; Tue, 09 Jul 2024 19:43:22 AEST Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4WJGJV28jlz30WJ; Tue, 9 Jul 2024 19:43:18 +1000 (AEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 896761BF20E; Tue, 9 Jul 2024 09:43:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1720518188; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WVMmtSjwlNQmVjxtUeUdR3iKhz4W+lQLl2pkn1Xk12k=; b=pS12M/hFFtUvUahs26E5vD/JZJjIQ8CmyPf5kCaaSJzFbR3RDeMCaG4WkQ18U83Kje7Xfl AyN919sqdbsVTsmreQhwHSygXqgRJ0kdPQ5zjcJUGtxlT4Ho9p8ijdF8YfTeIO6HFDK7eO 9ZWZUOd5wpLbo4/rkrKRN8+RnXilQYghyruJzJG1B0By1AlkPDEswaoM56ChbKqR9xzmtO jhtQebyqSJwnet2P69DvwaCq24fYzhp/MVzppGLvK1eJdhxGBanp5/LzDMV65mb+L+itk6 lQKaVcgNUEyq8U3sZF8TqV+3RTbRtu+1Gi6vNNP28kc9H4uebjsO4mk9Ei94yg== Date: Tue, 9 Jul 2024 11:43:02 +0200 From: Miquel Raynal To: Marco Felsch Subject: Re: [PATCH 4/9] mtd: devices: add AT24 eeprom support Message-ID: <20240709114302.3c604ef3@xps-13> In-Reply-To: <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240701-b4-v6-10-topic-usbc-tcpci-v1-4-3fd5f4a193cc@pengutronix.de> <07b701a9-7b52-45b7-8dba-1c25d77cbf15@linaro.org> <20240702-congenial-vigilant-boar-aeae44@houat> <20240702-mighty-brilliant-eel-b0d9fa@houat> <20240708084440.70186564@xps-13> <20240709092214.omr7ccphdzdk7z7j@pengutronix.de> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Alexandre Belloni , Vignesh Raghavendra , Geert Uytterhoeven , imx@lists.linux.dev, Tony Lindgren , Nicolas Ferre , Thierry Reding , linux-mtd@lists.infradead.org, linux-i2c@vger.kernel.org, WANG Xuerui , Fabio Estevam , linux-aspeed@lists.ozlabs.org, Richard Weinberger , Gregory Clement , Huacai Chen , Russell King , Christophe Leroy , Jonathan Hunter , Tudor Ambarus , Joel Stanley , "Naveen N. Rao" , Andrew Jeffery , Sebastian Hesselbarth , Arnd Bergmann , openbmc@lists.ozlabs.org, Sascha Hauer , Jonathan =?UTF-8?B?TmV1c2Now6RmZXI=?= , Maxime Ripard , Vladimir Zapolskiy , Nicholas Piggin , loongarch@lists.linux.dev, linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, Greg Kroah-Hartman , linuxppc-dev@lists.ozlabs.org, Claudiu Beznea , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Dinh Nguyen , Pengutronix Kernel Team , Shawn Guo , Bartosz Golaszewski , Pratyush Yadav Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Marco, > > > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggestin= g adding > > > > >> EEPROMs to MTD [1]. The main purpose would have been unifying th= e EEPROM > > > > >> drivers under a single interface. I am not sure what came of it = though, > > > > >> since I can't find any patches that followed up with the proposa= l. =20 > > > > > > > > > > That discussion led to drivers/nvmem after I started to work on > > > > > some early prototype, and Srinivas took over that work. =20 > > > >=20 > > > > So would you say it is better for EEPROM drivers to use nvmem inste= ad of > > > > moving under MTD? =20 > > >=20 > > > I thought so at the time, but that was more than 10y ago, and I have > > > followed neither nvmem nor MTD since so I don't really have an opinion > > > there. > > >=20 > > > It looks like drivers/misc/eeprom/at24.c has support for nvmem though, > > > and MTD can be used as an nvmem provider too, so it's not clear to me > > > why we would want to create yet another variant. > > >=20 > > > But again, you shouldn't really ask me in the first place :) > > >=20 > > > I'm sure Miquel, Srinivas, and surely others, are much more relevant = to > > > answer that question. =20 > >=20 > > More relevant, I doubt, but just a feeling: EEPROMs have their own > > subsystem now, NVMEM, which, as Maxime said, was initially written for > > that very specific case. EEPROMs don't have the complexity of MTD > > devices, and thus pulling the whole MTD subsystem just for getting > > partitions seems counter intuitive to me. You can definitely "split" > > EEPROM devices with NVMEM as well anyway. =20 >=20 > I asked for feedback on my RFC [1] and all I got was to merge both > drivers into one and make the driver backward compatible, which I did by > this commit. I'm sorry for not bringing this earlier. > > Overall I think the idea of getting rid of these misc/ drivers is goes > > into the right direction, but registering directly into NVMEM makes > > more sense IMO. =20 >=20 > So you propose to have two places for the partition handling (one for > MTD and one for NVMEM) instead of one and moving the code into NVMEM > directly? Why two places for the partitions handling? Just one, in NVMEM. Also usually EEPROMs don't require very advanced partitioning schemes, unlike flashes (which are the most common MTD devices today). > That doesn't sound right to me either. Also I don't get the > point why EEPROMs can't be handled by the MTD layer? They can, but should they? Just compile the two layers and observe the size difference. MTD is complex and old, carries a lot of history, and the user interface is also not straightforward because you need to handle pages, blocks, erases, bitflips, ECC stats, OOB bytes and positions, two OTP areas... None of that exists in the EEPROM world. So why would you want to register into MTD and pull a huge subsystem while there is a much more recent, simpler and way lighter subsystem fitting much better your device? > The layer already > supports devices of type MTD_RAM which are very simple and don't require > an erase-op at least I don't see one. MTD_RAM has been there forever, probably for "bad" reasons. BTW there has been an attempt at removing it which was reverted in _2006_ and then felt into the cracks: 21c8db9eff95 ("[MTD] Restore MTD_ROM and MTD_RAM types") Thanks, Miqu=C3=A8l