From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (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 5143810953; Mon, 8 Jul 2024 06:44:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.196 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720421096; cv=none; b=fVXogCAEkf9ms/hAXj2iwOKto66oFmBM2nEc0+aQyPt+BismBzLiLpKAeUlCmdYMou/Pcb+Pxvp1bb80dTi3GiibSeQMoCl6XXiKdzF+SpWSJ2sPaup9ss1t1eEyNbUtwq7Rs7rpiMrjbUU7M2N7qHy1zG6w4L3MrRZb7rM7HJE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720421096; c=relaxed/simple; bh=EqDlk82dE7XS0/JGyUAUcCtCsFHxwVbAJvsEIiMzMrs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cYndvOhQxosYeybSe9YkIWd+v9HPEeV67u5gdo9C9xgwyTu/fQcmRVVMb6MBGL167DMiTfJg2OpB9QJYRJ0ncyiM5WO5YS3WJQxQ3LBKpDn12vag/haXYf4jtwbFFdra8ooqjRqX/ygpHychzPyqovH/Nt27DpMwl/9uyiUiL5I= 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=PzOy6Z2W; arc=none smtp.client-ip=217.70.183.196 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="PzOy6Z2W" Received: by mail.gandi.net (Postfix) with ESMTPSA id 817CBE0006; Mon, 8 Jul 2024 06:44:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1720421086; 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=kN45r2MzRBKAE4raZ17kWauJPTnIek3N3oaVcC2BO/g=; b=PzOy6Z2WDoUDIURvXSdTtpzbHX3JQqR2TwTpbeUTnfB6vX3dNcZ37ATxjxBqYPJmXyybOW /cSvPuilXVhZeR7B2dXURK6eJ39WhH4IRmB3cgvultxkXbdYRWIJAVPOSzfOAYpJjJ6yjj T4otuw7FybtaZrQhYLIzqq3zUvj4Jc9ZhqWNxjCSwxjRvmd7Z4M+rCx4VXtxp9PGAb8E1q oZ1dnF7ScZhNf1MbVD05qQH3qQWLfMAQwFkOz4wVja8KUEs30B2F3BIx4guMRdC+Ulvnk+ YXsH623cgVPmDlxftJRPmEBJAk7rpJRwu3UnaQOHOTk3BC9lbm01fchVhlirnQ== Date: Mon, 8 Jul 2024 08:44:40 +0200 From: Miquel Raynal To: Maxime Ripard Cc: Pratyush Yadav , Tudor Ambarus , Marco Felsch , 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: <20240708084440.70186564@xps-13> In-Reply-To: <20240702-mighty-brilliant-eel-b0d9fa@houat> 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> 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, > > >> >> Port the current misc/eeprom/at24.c driver to the MTD framework s= ince > > >> >> EEPROMs are memory-technology devices and the framework already s= upports =20 > > >> > > > >> > I was under the impression that MTD devices are tightly coupled by= erase > > >> > blocks. But then we see MTD_NO_ERASE, so what are MTD devices afte= r all? =20 > > >>=20 > > >> I was curious as well so I did some digging. > > >> =20 > > [...] =20 > > >>=20 > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting ad= ding > > >> EEPROMs to MTD [1]. The main purpose would have been unifying the EE= PROM > > >> drivers under a single interface. I am not sure what came of it thou= gh, > > >> since I can't find any patches that followed up with the proposal. = =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 instead 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. 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. 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. Thanks, Miqu=C3=A8l From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Mon, 08 Jul 2024 07:05:15 -0000 Subject: [PATCH 4/9] mtd: devices: add AT24 eeprom support In-Reply-To: <20240702-mighty-brilliant-eel-b0d9fa@houat> 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> Message-ID: <20240708084440.70186564@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, > > >> >> Port the current misc/eeprom/at24.c driver to the MTD framework since > > >> >> EEPROMs are memory-technology devices and the framework already supports > > >> > > > >> > I was under the impression that MTD devices are tightly coupled by erase > > >> > blocks. But then we see MTD_NO_ERASE, so what are MTD devices after all? > > >> > > >> I was curious as well so I did some digging. > > >> > > [...] > > >> > > >> 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. 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. 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 38751C3DA42 for ; Mon, 8 Jul 2024 06:44:58 +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=M/lcp9CIixl3xpoRO1RbQL/OEzL3RXa24vjwJFzmwKM=; b=tMC4jkm2ZOgRq5 P8gZxGERtiM9hoznFay4oFcl2UMDkUEWP/FlplQ72QUqn90NiNwqOIIAp1VmXN6pprGoWm/BKZCVN xzmCEwMjNvhZ9o/lIY8bnJmLyPNJIdbQkYzBgi1jIkslghagDDMTKNwgMZLQ0aLhVHbDkfa/8cUq3 xqLK72mCc1pfBzNQBndBd5ROF6gwBk6cfbjamh0+VUDkDWa011/5o502xUALna2DmKll1lbxxYlBz hN3luhCrm3VNKGji3TyZlm3zMR1xdpbko3keg2dpYNS5M0bFiIiAOMqbU6AcbE8fxTBI2MjYSUPCf yhzugP5goXrWHl2FyEfg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sQi7K-00000002v0C-3jkF; Mon, 08 Jul 2024 06:44:54 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sQi7G-00000002uzN-1yQR; Mon, 08 Jul 2024 06:44:52 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 817CBE0006; Mon, 8 Jul 2024 06:44:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1720421086; 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=kN45r2MzRBKAE4raZ17kWauJPTnIek3N3oaVcC2BO/g=; b=PzOy6Z2WDoUDIURvXSdTtpzbHX3JQqR2TwTpbeUTnfB6vX3dNcZ37ATxjxBqYPJmXyybOW /cSvPuilXVhZeR7B2dXURK6eJ39WhH4IRmB3cgvultxkXbdYRWIJAVPOSzfOAYpJjJ6yjj T4otuw7FybtaZrQhYLIzqq3zUvj4Jc9ZhqWNxjCSwxjRvmd7Z4M+rCx4VXtxp9PGAb8E1q oZ1dnF7ScZhNf1MbVD05qQH3qQWLfMAQwFkOz4wVja8KUEs30B2F3BIx4guMRdC+Ulvnk+ YXsH623cgVPmDlxftJRPmEBJAk7rpJRwu3UnaQOHOTk3BC9lbm01fchVhlirnQ== Date: Mon, 8 Jul 2024 08:44:40 +0200 From: Miquel Raynal To: Maxime Ripard Cc: Pratyush Yadav , Tudor Ambarus , Marco Felsch , 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: <20240708084440.70186564@xps-13> In-Reply-To: <20240702-mighty-brilliant-eel-b0d9fa@houat> 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> 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-20240707_234450_794594_06324AC2 X-CRM114-Status: GOOD ( 24.52 ) 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 SGksCgo+ID4gPj4gPj4gUG9ydCB0aGUgY3VycmVudCBtaXNjL2VlcHJvbS9hdDI0LmMgZHJpdmVy IHRvIHRoZSBNVEQgZnJhbWV3b3JrIHNpbmNlCj4gPiA+PiA+PiBFRVBST01zIGFyZSBtZW1vcnkt dGVjaG5vbG9neSBkZXZpY2VzIGFuZCB0aGUgZnJhbWV3b3JrIGFscmVhZHkgc3VwcG9ydHMgIAo+ ID4gPj4gPgo+ID4gPj4gPiBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IE1URCBkZXZp Y2VzIGFyZSB0aWdodGx5IGNvdXBsZWQgYnkgZXJhc2UKPiA+ID4+ID4gYmxvY2tzLiBCdXQgdGhl biB3ZSBzZWUgTVREX05PX0VSQVNFLCBzbyB3aGF0IGFyZSBNVEQgZGV2aWNlcyBhZnRlciBhbGw/ ICAKPiA+ID4+IAo+ID4gPj4gSSB3YXMgY3VyaW91cyBhcyB3ZWxsIHNvIEkgZGlkIHNvbWUgZGln Z2luZy4KPiA+ID4+ICAgCj4gPiBbLi4uXSAgCj4gPiA+PiAKPiA+ID4+IEkgYWxzbyBmb3VuZCBh IHRocmVhZCBmcm9tIDIwMTMgYnkgTWF4aW1lIFJpcGFyZCAoK0NjKSBzdWdnZXN0aW5nIGFkZGlu Zwo+ID4gPj4gRUVQUk9NcyB0byBNVEQgWzFdLiBUaGUgbWFpbiBwdXJwb3NlIHdvdWxkIGhhdmUg YmVlbiB1bmlmeWluZyB0aGUgRUVQUk9NCj4gPiA+PiBkcml2ZXJzIHVuZGVyIGEgc2luZ2xlIGlu dGVyZmFjZS4gSSBhbSBub3Qgc3VyZSB3aGF0IGNhbWUgb2YgaXQgdGhvdWdoLAo+ID4gPj4gc2lu Y2UgSSBjYW4ndCBmaW5kIGFueSBwYXRjaGVzIHRoYXQgZm9sbG93ZWQgdXAgd2l0aCB0aGUgcHJv cG9zYWwuICAKPiA+ID4KPiA+ID4gVGhhdCBkaXNjdXNzaW9uIGxlZCB0byBkcml2ZXJzL252bWVt IGFmdGVyIEkgc3RhcnRlZCB0byB3b3JrIG9uCj4gPiA+IHNvbWUgZWFybHkgcHJvdG90eXBlLCBh bmQgU3Jpbml2YXMgdG9vayBvdmVyIHRoYXQgd29yay4gIAo+ID4gCj4gPiBTbyB3b3VsZCB5b3Ug c2F5IGl0IGlzIGJldHRlciBmb3IgRUVQUk9NIGRyaXZlcnMgdG8gdXNlIG52bWVtIGluc3RlYWQg b2YKPiA+IG1vdmluZyB1bmRlciBNVEQ/ICAKPiAKPiBJIHRob3VnaHQgc28gYXQgdGhlIHRpbWUs IGJ1dCB0aGF0IHdhcyBtb3JlIHRoYW4gMTB5IGFnbywgYW5kIEkgaGF2ZQo+IGZvbGxvd2VkIG5l aXRoZXIgbnZtZW0gbm9yIE1URCBzaW5jZSBzbyBJIGRvbid0IHJlYWxseSBoYXZlIGFuIG9waW5p b24KPiB0aGVyZS4KPiAKPiBJdCBsb29rcyBsaWtlIGRyaXZlcnMvbWlzYy9lZXByb20vYXQyNC5j IGhhcyBzdXBwb3J0IGZvciBudm1lbSB0aG91Z2gsCj4gYW5kIE1URCBjYW4gYmUgdXNlZCBhcyBh biBudm1lbSBwcm92aWRlciB0b28sIHNvIGl0J3Mgbm90IGNsZWFyIHRvIG1lCj4gd2h5IHdlIHdv dWxkIHdhbnQgdG8gY3JlYXRlIHlldCBhbm90aGVyIHZhcmlhbnQuCj4gCj4gQnV0IGFnYWluLCB5 b3Ugc2hvdWxkbid0IHJlYWxseSBhc2sgbWUgaW4gdGhlIGZpcnN0IHBsYWNlIDopCj4gCj4gSSdt IHN1cmUgTWlxdWVsLCBTcmluaXZhcywgYW5kIHN1cmVseSBvdGhlcnMsIGFyZSBtdWNoIG1vcmUg cmVsZXZhbnQgdG8KPiBhbnN3ZXIgdGhhdCBxdWVzdGlvbi4KCk1vcmUgcmVsZXZhbnQsIEkgZG91 YnQsIGJ1dCBqdXN0IGEgZmVlbGluZzogRUVQUk9NcyBoYXZlIHRoZWlyIG93bgpzdWJzeXN0ZW0g bm93LCBOVk1FTSwgd2hpY2gsIGFzIE1heGltZSBzYWlkLCB3YXMgaW5pdGlhbGx5IHdyaXR0ZW4g Zm9yCnRoYXQgdmVyeSBzcGVjaWZpYyBjYXNlLiBFRVBST01zIGRvbid0IGhhdmUgdGhlIGNvbXBs ZXhpdHkgb2YgTVRECmRldmljZXMsIGFuZCB0aHVzIHB1bGxpbmcgdGhlIHdob2xlIE1URCBzdWJz eXN0ZW0ganVzdCBmb3IgZ2V0dGluZwpwYXJ0aXRpb25zIHNlZW1zIGNvdW50ZXIgaW50dWl0aXZl IHRvIG1lLiBZb3UgY2FuIGRlZmluaXRlbHkgInNwbGl0IgpFRVBST00gZGV2aWNlcyB3aXRoIE5W TUVNIGFzIHdlbGwgYW55d2F5LgoKT3ZlcmFsbCBJIHRoaW5rIHRoZSBpZGVhIG9mIGdldHRpbmcg cmlkIG9mIHRoZXNlIG1pc2MvIGRyaXZlcnMgaXMgZ29lcwppbnRvIHRoZSByaWdodCBkaXJlY3Rp b24sIGJ1dCByZWdpc3RlcmluZyBkaXJlY3RseSBpbnRvIE5WTUVNIG1ha2VzCm1vcmUgc2Vuc2Ug SU1PLgoKVGhhbmtzLApNaXF1w6hsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0 dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRkLwo= 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 7FB1CC3271E for ; Mon, 8 Jul 2024 06:45:47 +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=PzOy6Z2W; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4WHZQ15vhvz3cTl for ; Mon, 8 Jul 2024 16:45:45 +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=PzOy6Z2W; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=bootlin.com (client-ip=2001:4b98:dc4:8::224; helo=relay4-d.mail.gandi.net; envelope-from=miquel.raynal@bootlin.com; receiver=lists.ozlabs.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::224]) (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 4WHZPD1wSTz3cGS for ; Mon, 8 Jul 2024 16:44:57 +1000 (AEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 817CBE0006; Mon, 8 Jul 2024 06:44:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1720421086; 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=kN45r2MzRBKAE4raZ17kWauJPTnIek3N3oaVcC2BO/g=; b=PzOy6Z2WDoUDIURvXSdTtpzbHX3JQqR2TwTpbeUTnfB6vX3dNcZ37ATxjxBqYPJmXyybOW /cSvPuilXVhZeR7B2dXURK6eJ39WhH4IRmB3cgvultxkXbdYRWIJAVPOSzfOAYpJjJ6yjj T4otuw7FybtaZrQhYLIzqq3zUvj4Jc9ZhqWNxjCSwxjRvmd7Z4M+rCx4VXtxp9PGAb8E1q oZ1dnF7ScZhNf1MbVD05qQH3qQWLfMAQwFkOz4wVja8KUEs30B2F3BIx4guMRdC+Ulvnk+ YXsH623cgVPmDlxftJRPmEBJAk7rpJRwu3UnaQOHOTk3BC9lbm01fchVhlirnQ== Date: Mon, 8 Jul 2024 08:44:40 +0200 From: Miquel Raynal To: Maxime Ripard Subject: Re: [PATCH 4/9] mtd: devices: add AT24 eeprom support Message-ID: <20240708084440.70186564@xps-13> In-Reply-To: <20240702-mighty-brilliant-eel-b0d9fa@houat> 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> 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 , Marco Felsch , 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=?= , Nicholas Piggin , Vladimir Zapolskiy , 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, > > >> >> Port the current misc/eeprom/at24.c driver to the MTD framework s= ince > > >> >> EEPROMs are memory-technology devices and the framework already s= upports =20 > > >> > > > >> > I was under the impression that MTD devices are tightly coupled by= erase > > >> > blocks. But then we see MTD_NO_ERASE, so what are MTD devices afte= r all? =20 > > >>=20 > > >> I was curious as well so I did some digging. > > >> =20 > > [...] =20 > > >>=20 > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting ad= ding > > >> EEPROMs to MTD [1]. The main purpose would have been unifying the EE= PROM > > >> drivers under a single interface. I am not sure what came of it thou= gh, > > >> since I can't find any patches that followed up with the proposal. = =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 instead 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. 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. 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. Thanks, Miqu=C3=A8l