linux-kernel - RE: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <IA0PR12MB7699ECBE6F803B2DEF33D633DC8C2@IA0PR12MB7699.namprd12.prod.outlook.com>
Date: Mon, 19 Aug 2024 10:28:57 +0000
From: "Mahapatra, Amit Kumar" <amit.kumar-mahapatra@....com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
CC: Tudor Ambarus <tudor.ambarus@...aro.org>, "broonie@...nel.org"
	<broonie@...nel.org>, "pratyush@...nel.org" <pratyush@...nel.org>,
	"richard@....at" <richard@....at>, "vigneshr@...com" <vigneshr@...com>,
	"sbinding@...nsource.cirrus.com" <sbinding@...nsource.cirrus.com>,
	"lee@...nel.org" <lee@...nel.org>, "james.schulman@...rus.com"
	<james.schulman@...rus.com>, "david.rhodes@...rus.com"
	<david.rhodes@...rus.com>, "rf@...nsource.cirrus.com"
	<rf@...nsource.cirrus.com>, "perex@...ex.cz" <perex@...ex.cz>,
	"tiwai@...e.com" <tiwai@...e.com>, "linux-spi@...r.kernel.org"
	<linux-spi@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "michael@...le.cc" <michael@...le.cc>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
	"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
	"claudiu.beznea@...on.dev" <claudiu.beznea@...on.dev>, "Simek, Michal"
	<michal.simek@....com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "alsa-devel@...a-project.org"
	<alsa-devel@...a-project.org>, "patches@...nsource.cirrus.com"
	<patches@...nsource.cirrus.com>, "linux-sound@...r.kernel.org"
	<linux-sound@...r.kernel.org>, "git (AMD-Xilinx)" <git@....com>,
	"amitrkcian2002@...il.com" <amitrkcian2002@...il.com>, Conor Dooley
	<conor.dooley@...rochip.com>, "beanhuo@...ron.com" <beanhuo@...ron.com>
Subject: RE: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor

Hello Miquel,

> Hi Amit,
> 
> > > > > > For implementing this the current DT binding need to be
> > > > > > updated as follows.
> > > > >
> > > > > So you want to go back to step 1 and redefine bindings? Is that worth?
> > > >
> > > > The current bindings are effective if we only support identical
> > > > flash devices or flashes of the same make but with different sizes
> > > > connected in stacked mode. However, if we want to extend stacked
> > > > support to include flashes of different makes in stacked mode,
> > >
> > > The only actual feature the stacked mode brings is the ability to
> > > consider two devices like one. This is abstracted by hardware, this is a
> controller capability.
> >
> > Stacked mode is a software abstraction rather than a controller
> > feature or capability. At any given time, the controller communicates
> > with one of the two connected flash devices, as determined by the
> > requested address and data length. If an operation starts on one flash
> > and ends on the other, the core needs to split it into two separate
> > operations and adjust the data length accordingly.
> 
> I'm sorry, that was not my understanding, cf the initial RFC:
> 
> 	Subject: [RFC PATCH 0/3] Dual stacked/parallel memories bindings
> 	Date: Fri, 12 Nov 2021 16:24:08 +0100
> 
> 	"[...] supporting specific SPI controller modes like Xilinx's
> 	where the controller can highly abstract the hardware and
> 	provide access to a single bigger device instead [...]"
> 
> Furthermore, I rapidly checked the Zynq7000 TRM, it suggests that the
> controller is capable of addressing the right memory itself based on the
> address, especially in linear mode?

Yes, this is true only when operating in Linear Mode. In this mode, the 
Zynq 7000 can only perform read operations. Erase and write operations 
are possible only in I/O mode, so while operating in I/O mode the CS pins 
must be manually asserted by the driver according to the address and data 
length
> 
> 	https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Dual-SS-
> 4-bit-Stacked-I/O
> 
> 	"The lower SPI flash memory should always be connected if the
> 	linear Quad-SPI memory subsystem is used, and the upper flash
> 	memory is optional. Total address space is 32 MB with a 25-bit
> 	address. In IO mode, the MSB of the address is defined by
> 	U_PAGE which is located at bit 28 of register 0xA0 . In Linear
> 	address mode, AXI address bit 24 determines the upper or lower
> 	memory page. All of the commands will be executed by the device
> 	selected by U_PAGE in I/O mode and address bit 24 in linear
> 	mode."
> 
> Anyway, you may decide to go down the "pure software" route, which is
> probably easier from an implementation perspective, but means you're
> gonna have to argue -again- in favor of the representation of a purely virtual
> device that is not hardware.

Yes, that's correct, but I was planning to manage it through a new layer rather 
than using mtd-concat. As Tudor mentioned, I will start a new email thread 
outlining my proposal so we can resume the discussion on the patch moving 
forward.

Regards,
Amit
> 
> Cheers,
> Miquèl