From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 376132CCC2; Mon, 26 Aug 2024 10:33:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724668395; cv=none; b=hlaYreF6Y5TLcz18q63MO4oSGaQtvkPwHCL/FRYUe11I/OFkfDYRB8TcAqc4Do/CADlRu1I+kOX53Z1pMy7YGIzotZO3yT3h4I18sZx0Cd89RBul2lGJo/nGzU3n0yrfIVHPKXI0LSOjLwOFeU3oyh9P3duDBSJywqwhtCwPM4s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724668395; c=relaxed/simple; bh=8gNhFuofD5zWGUNIriljHUVsJipVG7nNNSIviq4tVXY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Tz4YcyloLxMDGNG9RpSryhM5vJwC8smvTbXhw+YNcBqM5ANKwR/ObU1F15Vdtuih++AdS5RcXWeyrObCqU9dPIThWMAqFA9OAuLe9QZK6/WrLAfWy0wP4lZhpakCfyTM/o8nGc5A4RF+aiQqro6gNSe6g6qR0zYmWqpHRkk07j8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=OyHu+hNH; arc=none smtp.client-ip=192.198.163.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="OyHu+hNH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1724668394; x=1756204394; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8gNhFuofD5zWGUNIriljHUVsJipVG7nNNSIviq4tVXY=; b=OyHu+hNHw9+5OV1xZjLPFfAb6+6Yd0xZhsMKR/kFf61vletunwMrq98F Fiepbfs94mc2Py9gV38ovWk3X1i+uW+ic68WfHp+mYPkuN8aI/zFalgkD MGfzj02wiSEF+IPgOm9VrJjc6a3KMLaQLun1yUVCwpqvwEchpSOwNOOxR MyBz8TTB/5Y93fmDc8Ca4nsBOntQFoMEp6d+1om1iqZoQFlwK39PR//nv g81MlQka/NbyDgueFQ9Jz4do+zMpVLG1nRAciKXXWmBtKbt7zhjOzTKPV IbExW+j+n/BcNrny3fDVjKb77kYkw2TXv0HMzHJFFsk/ykFMEiB5lHhY/ Q==; X-CSE-ConnectionGUID: SRO2l5zLSXuSwmrsN3xXvw== X-CSE-MsgGUID: HFJLkSLqTOGBw4PhP0RCzA== X-IronPort-AV: E=McAfee;i="6700,10204,11175"; a="13208696" X-IronPort-AV: E=Sophos;i="6.10,177,1719903600"; d="scan'208";a="13208696" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 03:33:13 -0700 X-CSE-ConnectionGUID: i7pAAaNJSrSUyr5xtjco/A== X-CSE-MsgGUID: cTuMYcAhT2+25aitr3/fAg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,177,1719903600"; d="scan'208";a="62517541" Received: from smile.fi.intel.com ([10.237.72.54]) by fmviesa009.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 03:33:01 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1siX1d-00000001pi8-1NQC; Mon, 26 Aug 2024 13:32:41 +0300 Date: Mon, 26 Aug 2024 13:32:26 +0300 From: Andy Shevchenko To: Marco Felsch Cc: Miquel Raynal , 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 =?iso-8859-1?Q?Neusch=E4fer?= , 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 0/9] AT24 EEPROM MTD Support Message-ID: References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240826075110.u3cxc6dootou72eq@pengutronix.de> Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240826075110.u3cxc6dootou72eq@pengutronix.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Mon, Aug 26, 2024 at 09:51:10AM +0200, Marco Felsch wrote: > On 24-08-23, Andy Shevchenko wrote: > > On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote: > > > This series adds the intial support to handle EEPROMs via the MTD layer > > > as well. This allow the user-space to have separate paritions since > > > EEPROMs can become quite large nowadays. > > > > > > With this patchset applied EEPROMs can be accessed via: > > > - legacy 'eeprom' device > > > - nvmem device > > > - mtd device(s) > > > > > > The patchset targets only the AT24 (I2C) EEPROMs since I have no access > > > to AT25 (SPI) EEPROMs nor to one of the other misc/eeprom/* devices. > > > > > > Note: I'm not familiar with Kconfig symbol migration so I don't know if > > > the last patch is required at the moment. Please be notified that the > > > list of recipients is quite large due to the defconfig changes. > > > > FWIW, I think that MTD is *not* the place for EEPROMs. > > > > Yeah, we have the driver spread over the kernel for EEPROMs (mostly due to > > historical reasons and absence an umbrella subsystem for them), but it's not > > the reason to hack them into something which is not quite suitable. > > Thank you for you input. There are two things to mention: > 1st) I send a RFC patch and asked for feedback and all I got was: looks > okay, please send a proper patch [1] which I did. I was on a long vacation, I haven't had time or even wishes to look at the patches or patch series. Sorry for that. Second point, RFC means "request for comments", here is mine. It's up to the maintainers and you on how to proceed it. > 2nd) I don't see the hacky part in this patchset. I haven't talked about patchset, I have talked about architectural / design point of view. I read the discussion and to me it seems like it solves the issue with a quite big hammer. If you can prove that on embedded systems with limited resources it is not a problem, just mention that in the cover letter. > Anyway the customer doesn't need the nvmem-partitions anymore and > therefore this patchset can be seen as obsolote. > > [1] https://lore.kernel.org/lkml/20231201144441.imk7rrjnv2dugo7p@pengutronix.de/T/#m1e0e5778448971b50a883f62bd95622f6422b9a2 > > > If NVMEM needs to be updated and may cover these cases after all (and do not > > forget about *small* size EEPROMs that most likely appear on the devices with > > limited amount of resources!) in a reasonable size and performance, why not? -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Date: Mon, 26 Aug 2024 13:32:26 +0300 Subject: [PATCH 0/9] AT24 EEPROM MTD Support In-Reply-To: <20240826075110.u3cxc6dootou72eq@pengutronix.de> References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240826075110.u3cxc6dootou72eq@pengutronix.de> Message-ID: List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Aug 26, 2024 at 09:51:10AM +0200, Marco Felsch wrote: > On 24-08-23, Andy Shevchenko wrote: > > On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote: > > > This series adds the intial support to handle EEPROMs via the MTD layer > > > as well. This allow the user-space to have separate paritions since > > > EEPROMs can become quite large nowadays. > > > > > > With this patchset applied EEPROMs can be accessed via: > > > - legacy 'eeprom' device > > > - nvmem device > > > - mtd device(s) > > > > > > The patchset targets only the AT24 (I2C) EEPROMs since I have no access > > > to AT25 (SPI) EEPROMs nor to one of the other misc/eeprom/* devices. > > > > > > Note: I'm not familiar with Kconfig symbol migration so I don't know if > > > the last patch is required at the moment. Please be notified that the > > > list of recipients is quite large due to the defconfig changes. > > > > FWIW, I think that MTD is *not* the place for EEPROMs. > > > > Yeah, we have the driver spread over the kernel for EEPROMs (mostly due to > > historical reasons and absence an umbrella subsystem for them), but it's not > > the reason to hack them into something which is not quite suitable. > > Thank you for you input. There are two things to mention: > 1st) I send a RFC patch and asked for feedback and all I got was: looks > okay, please send a proper patch [1] which I did. I was on a long vacation, I haven't had time or even wishes to look at the patches or patch series. Sorry for that. Second point, RFC means "request for comments", here is mine. It's up to the maintainers and you on how to proceed it. > 2nd) I don't see the hacky part in this patchset. I haven't talked about patchset, I have talked about architectural / design point of view. I read the discussion and to me it seems like it solves the issue with a quite big hammer. If you can prove that on embedded systems with limited resources it is not a problem, just mention that in the cover letter. > Anyway the customer doesn't need the nvmem-partitions anymore and > therefore this patchset can be seen as obsolote. > > [1] https://lore.kernel.org/lkml/20231201144441.imk7rrjnv2dugo7p at pengutronix.de/T/#m1e0e5778448971b50a883f62bd95622f6422b9a2 > > > If NVMEM needs to be updated and may cover these cases after all (and do not > > forget about *small* size EEPROMs that most likely appear on the devices with > > limited amount of resources!) in a reasonable size and performance, why not? -- With Best Regards, Andy Shevchenko 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 9BAB6C5472E for ; Mon, 26 Aug 2024 10:33:26 +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=OjgWlE7/5+QGaEfrkNN9DLfBLDDfspAcfUHMjSs2kVw=; b=l15fbqNPrTqNjW QaY/XlVTR9DiW7p+iwcEVjvKYfNTrUSBWAP2ngg69DNvpsVFclcjPJX4uol51dR6ql7IBOt6Bb8Y8 IFLV7f37EEoevdg7G6hz1ocxR7gsxCvUROew0MXPsxmc4GDCwXHQ6L09tKVxF97N6ZcVVK6fG+3KI wyKKrhknl3AXUrID1qpRLJviyg3vwuM71QKmU2MqAa07UaihFDMbYf5/glbNAj0MBUAFOP1cXHdLq kzZ+D7Xo5BXKkK/TMMO0b1x+/qTsg/0V/InZ65zzJGrj1rhqCgnqweIYi2M1P+i14ncamplrOySzH 3iGB1sdJ+jqWUVhwWcQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1siX2J-00000006wdt-3ge5; Mon, 26 Aug 2024 10:33:23 +0000 Received: from mgamail.intel.com ([192.198.163.16]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1siX2G-00000006wcv-0R0k; Mon, 26 Aug 2024 10:33:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1724668400; x=1756204400; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8gNhFuofD5zWGUNIriljHUVsJipVG7nNNSIviq4tVXY=; b=PBr33TEqAxa6oXIYUqlqogS0qw3ecJ6OaXfrmy2i+mf6viewGaswONx1 DIk1uTXjDwqGHaTXAZjewxDdli55634Vrwb/sNjUMk8pa1Q8ThCXAAbbE AboXODsq5L51l8VqrUehoSwiq7+JzKiuS08QLyBitBjNoTKFT7Zq8MHbd r8snKCyH9+feUYwq6In53r/zwqqnxWIIasfGFrtbwPJPE6MzeKGfxvqPL FgUkr0OmDRf54L/cz5OUqyipAohoTh6oNKDM61CE0x97oP75LRtWR2TIk hc+KONHEW7uK1ubbDC8jbFfwIMVwhLWhbQnTAKch1t5l2dyOXxaAzWsC6 w==; X-CSE-ConnectionGUID: IP5I966wRdawPOqVRpDzjQ== X-CSE-MsgGUID: 6e6aQh8ZSYmABj9rYZ8DHg== X-IronPort-AV: E=McAfee;i="6700,10204,11175"; a="13208715" X-IronPort-AV: E=Sophos;i="6.10,177,1719903600"; d="scan'208";a="13208715" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 03:33:13 -0700 X-CSE-ConnectionGUID: i7pAAaNJSrSUyr5xtjco/A== X-CSE-MsgGUID: cTuMYcAhT2+25aitr3/fAg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,177,1719903600"; d="scan'208";a="62517541" Received: from smile.fi.intel.com ([10.237.72.54]) by fmviesa009.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 03:33:01 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1siX1d-00000001pi8-1NQC; Mon, 26 Aug 2024 13:32:41 +0300 Date: Mon, 26 Aug 2024 13:32:26 +0300 From: Andy Shevchenko To: Marco Felsch Cc: Miquel Raynal , 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 =?iso-8859-1?Q?Neusch=E4fer?= , 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 0/9] AT24 EEPROM MTD Support Message-ID: References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240826075110.u3cxc6dootou72eq@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240826075110.u3cxc6dootou72eq@pengutronix.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240826_033320_181791_0B24D4E0 X-CRM114-Status: GOOD ( 36.98 ) 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 Mon, Aug 26, 2024 at 09:51:10AM +0200, Marco Felsch wrote: > On 24-08-23, Andy Shevchenko wrote: > > On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote: > > > This series adds the intial support to handle EEPROMs via the MTD layer > > > as well. This allow the user-space to have separate paritions since > > > EEPROMs can become quite large nowadays. > > > > > > With this patchset applied EEPROMs can be accessed via: > > > - legacy 'eeprom' device > > > - nvmem device > > > - mtd device(s) > > > > > > The patchset targets only the AT24 (I2C) EEPROMs since I have no access > > > to AT25 (SPI) EEPROMs nor to one of the other misc/eeprom/* devices. > > > > > > Note: I'm not familiar with Kconfig symbol migration so I don't know if > > > the last patch is required at the moment. Please be notified that the > > > list of recipients is quite large due to the defconfig changes. > > > > FWIW, I think that MTD is *not* the place for EEPROMs. > > > > Yeah, we have the driver spread over the kernel for EEPROMs (mostly due to > > historical reasons and absence an umbrella subsystem for them), but it's not > > the reason to hack them into something which is not quite suitable. > > Thank you for you input. There are two things to mention: > 1st) I send a RFC patch and asked for feedback and all I got was: looks > okay, please send a proper patch [1] which I did. I was on a long vacation, I haven't had time or even wishes to look at the patches or patch series. Sorry for that. Second point, RFC means "request for comments", here is mine. It's up to the maintainers and you on how to proceed it. > 2nd) I don't see the hacky part in this patchset. I haven't talked about patchset, I have talked about architectural / design point of view. I read the discussion and to me it seems like it solves the issue with a quite big hammer. If you can prove that on embedded systems with limited resources it is not a problem, just mention that in the cover letter. > Anyway the customer doesn't need the nvmem-partitions anymore and > therefore this patchset can be seen as obsolote. > > [1] https://lore.kernel.org/lkml/20231201144441.imk7rrjnv2dugo7p@pengutronix.de/T/#m1e0e5778448971b50a883f62bd95622f6422b9a2 > > > If NVMEM needs to be updated and may cover these cases after all (and do not > > forget about *small* size EEPROMs that most likely appear on the devices with > > limited amount of resources!) in a reasonable size and performance, why not? -- With Best Regards, Andy Shevchenko ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ 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 99CC6C5321E for ; Mon, 26 Aug 2024 10:34:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To :Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=okBsmIRRsjrgFRIKVjJuBx4Ep3cJGc18c8OQ+v6lf/E=; b=FPyJ1OqKRSOhNDdTOahpqcikzO /hVOOIlTIe03OfT+GQ2OqugRWk+8qqgxISnjv4qxuNQXoU3pMCVDz1BaOeS0n2punM8wPW3lsqGag jIqU1pJIcfQXj/fmiND5Zm53TjnLeN2KPqsyXRycz983lSEo2Xwpi/TUkjV3aPMePhauhULYY8I42 R/P3NSVxzmPOEBIvH67f0MLaaBcVigTs8vRWlL4nNXxZ+EoHBhNPAbqMvp34N5Kqod7p5N/w1Od+g O1GNi9N2vdr5qJIojo/Qg/7f8VOhWNecFb9vByJcFSLw7hcHLM0+B8p/u2kWK64nulr9qwrC2ZiJg iv6iYyPQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1siX34-00000006woW-2o8j; Mon, 26 Aug 2024 10:34:10 +0000 Received: from mgamail.intel.com ([192.198.163.16]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1siX2G-00000006wcv-0R0k; Mon, 26 Aug 2024 10:33:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1724668400; x=1756204400; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8gNhFuofD5zWGUNIriljHUVsJipVG7nNNSIviq4tVXY=; b=PBr33TEqAxa6oXIYUqlqogS0qw3ecJ6OaXfrmy2i+mf6viewGaswONx1 DIk1uTXjDwqGHaTXAZjewxDdli55634Vrwb/sNjUMk8pa1Q8ThCXAAbbE AboXODsq5L51l8VqrUehoSwiq7+JzKiuS08QLyBitBjNoTKFT7Zq8MHbd r8snKCyH9+feUYwq6In53r/zwqqnxWIIasfGFrtbwPJPE6MzeKGfxvqPL FgUkr0OmDRf54L/cz5OUqyipAohoTh6oNKDM61CE0x97oP75LRtWR2TIk hc+KONHEW7uK1ubbDC8jbFfwIMVwhLWhbQnTAKch1t5l2dyOXxaAzWsC6 w==; X-CSE-ConnectionGUID: IP5I966wRdawPOqVRpDzjQ== X-CSE-MsgGUID: 6e6aQh8ZSYmABj9rYZ8DHg== X-IronPort-AV: E=McAfee;i="6700,10204,11175"; a="13208715" X-IronPort-AV: E=Sophos;i="6.10,177,1719903600"; d="scan'208";a="13208715" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 03:33:13 -0700 X-CSE-ConnectionGUID: i7pAAaNJSrSUyr5xtjco/A== X-CSE-MsgGUID: cTuMYcAhT2+25aitr3/fAg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,177,1719903600"; d="scan'208";a="62517541" Received: from smile.fi.intel.com ([10.237.72.54]) by fmviesa009.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 03:33:01 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1siX1d-00000001pi8-1NQC; Mon, 26 Aug 2024 13:32:41 +0300 Date: Mon, 26 Aug 2024 13:32:26 +0300 From: Andy Shevchenko To: Marco Felsch Subject: Re: [PATCH 0/9] AT24 EEPROM MTD Support Message-ID: References: <20240701-b4-v6-10-topic-usbc-tcpci-v1-0-3fd5f4a193cc@pengutronix.de> <20240826075110.u3cxc6dootou72eq@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240826075110.u3cxc6dootou72eq@pengutronix.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240826_033320_181791_0B24D4E0 X-CRM114-Status: GOOD ( 36.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: 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 , Claudiu Beznea , Thierry Reding , linux-mtd@lists.infradead.org, linux-i2c@vger.kernel.org, Miquel Raynal , WANG Xuerui , Fabio Estevam , linux-aspeed@lists.ozlabs.org, Richard Weinberger , Gregory Clement , Huacai Chen , Magnus Damm , Russell King , Christophe Leroy , Jonathan Hunter , Joel Stanley , "Naveen N. Rao" , Andrew Jeffery , Sebastian Hesselbarth , Arnd Bergmann , openbmc@lists.ozlabs.org, Sascha Hauer , Jonathan =?iso-8859-1?Q?Neusch=E4fer?= , 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, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Dinh Nguyen , Pengutronix Kernel Team , Michael Ellerman , Shawn Guo , Bartosz Golaszewski Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 26, 2024 at 09:51:10AM +0200, Marco Felsch wrote: > On 24-08-23, Andy Shevchenko wrote: > > On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote: > > > This series adds the intial support to handle EEPROMs via the MTD layer > > > as well. This allow the user-space to have separate paritions since > > > EEPROMs can become quite large nowadays. > > > > > > With this patchset applied EEPROMs can be accessed via: > > > - legacy 'eeprom' device > > > - nvmem device > > > - mtd device(s) > > > > > > The patchset targets only the AT24 (I2C) EEPROMs since I have no access > > > to AT25 (SPI) EEPROMs nor to one of the other misc/eeprom/* devices. > > > > > > Note: I'm not familiar with Kconfig symbol migration so I don't know if > > > the last patch is required at the moment. Please be notified that the > > > list of recipients is quite large due to the defconfig changes. > > > > FWIW, I think that MTD is *not* the place for EEPROMs. > > > > Yeah, we have the driver spread over the kernel for EEPROMs (mostly due to > > historical reasons and absence an umbrella subsystem for them), but it's not > > the reason to hack them into something which is not quite suitable. > > Thank you for you input. There are two things to mention: > 1st) I send a RFC patch and asked for feedback and all I got was: looks > okay, please send a proper patch [1] which I did. I was on a long vacation, I haven't had time or even wishes to look at the patches or patch series. Sorry for that. Second point, RFC means "request for comments", here is mine. It's up to the maintainers and you on how to proceed it. > 2nd) I don't see the hacky part in this patchset. I haven't talked about patchset, I have talked about architectural / design point of view. I read the discussion and to me it seems like it solves the issue with a quite big hammer. If you can prove that on embedded systems with limited resources it is not a problem, just mention that in the cover letter. > Anyway the customer doesn't need the nvmem-partitions anymore and > therefore this patchset can be seen as obsolote. > > [1] https://lore.kernel.org/lkml/20231201144441.imk7rrjnv2dugo7p@pengutronix.de/T/#m1e0e5778448971b50a883f62bd95622f6422b9a2 > > > If NVMEM needs to be updated and may cover these cases after all (and do not > > forget about *small* size EEPROMs that most likely appear on the devices with > > limited amount of resources!) in a reasonable size and performance, why not? -- With Best Regards, Andy Shevchenko