lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240717101948.2e99f472@xps-13>
Date: Wed, 17 Jul 2024 10:19:48 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: Maxime Ripard <mripard@...nel.org>, Pratyush Yadav
 <pratyush@...nel.org>, Tudor Ambarus <tudor.ambarus@...aro.org>, Richard
 Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>, Arnd
 Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Bartosz Golaszewski <brgl@...ev.pl>, Russell King <linux@...linux.org.uk>,
 Joel Stanley <joel@....id.au>, Andrew Jeffery
 <andrew@...econstruct.com.au>, Nicolas Ferre <nicolas.ferre@...rochip.com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>, Claudiu Beznea
 <claudiu.beznea@...on.dev>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
 <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Vladimir Zapolskiy <vz@...ia.com>,
 Andrew Lunn <andrew@...n.ch>, Gregory Clement
 <gregory.clement@...tlin.com>, Sebastian Hesselbarth
 <sebastian.hesselbarth@...il.com>, Tony Lindgren <tony@...mide.com>, Geert
 Uytterhoeven <geert+renesas@...der.be>, Magnus Damm
 <magnus.damm@...il.com>, Dinh Nguyen <dinguyen@...nel.org>, Thierry Reding
 <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>,
 Jonathan Neuschäfer <j.neuschaefer@....net>, Michael
 Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>, "Naveen N. Rao"
 <naveen.n.rao@...ux.ibm.com>, Thomas Bogendoerfer
 <tsbogend@...ha.franken.de>, Huacai Chen <chenhuacai@...nel.org>, WANG
 Xuerui <kernel@...0n.name>, linux-mtd@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-aspeed@...ts.ozlabs.org,
 imx@...ts.linux.dev, linux-omap@...r.kernel.org,
 linux-renesas-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
 openbmc@...ts.ozlabs.org, linuxppc-dev@...ts.ozlabs.org,
 linux-mips@...r.kernel.org, loongarch@...ts.linux.dev
Subject: Re: [PATCH 4/9] mtd: devices: add AT24 eeprom support

Hi Marco,

> > > > 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  
> 
> Without checking the details I think that converting the MTD
> partitioning code into NVMEM partitioning code is a bigger task. As you
> said below there are many legacy code paths you need to consider so they
> still work afterwards as well.
> 
> > usually EEPROMs don't require very advanced partitioning schemes,
> > unlike flashes (which are the most common MTD devices today).  
> 
> As said in my cover letter EEPROMs can become quite large and MTD
> supports partitioning storage devices which is very handy for large
> EEPROMs as well.

Did you had a look at nvmem-layouts ? In particular the fixed-layout.

Is there anything you would like to achieve already that is not
possible with nvmem but is with mtd?

Thanks,
Miquèl

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ