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: <D33S9T73M6ND.G7CCJ4PDVYQU@walle.cc>
Date: Wed, 31 Jul 2024 16:11:05 +0200
From: "Michael Walle" <michael@...le.cc>
To: "Michal Simek" <michal.simek@....com>, "Mahapatra, Amit Kumar"
 <amit.kumar-mahapatra@....com>, "Tudor Ambarus" <tudor.ambarus@...aro.org>,
 "broonie@...nel.org" <broonie@...nel.org>, "pratyush@...nel.org"
 <pratyush@...nel.org>, "miquel.raynal@...tlin.com"
 <miquel.raynal@...tlin.com>, "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>
Cc: "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "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>,
 "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

> > All I'm saying is that you shouldn't put burden on us (the SPI NOR
> > maintainers) for what seems to me at least as a niche. Thus I was
> > asking for performance numbers and users. Convince me that I'm
> > wrong and that is worth our time.
>
> No. It is not really just feature of our evaluation boards. Customers are using 
> it. I was talking to one guy from field and he confirms me that these 
> configurations are used by his multiple customers in real products.

Which begs the question, do we really have to support every feature
in the core (I'd like to hear Tudors and Pratyush opinion here).
Honestly, this just looks like a concatenation of two QSPI
controllers. Why didn't you just use a normal octal controller which
is a protocol also backed by the JEDEC standard. Is it any faster?
Do you get more capacity? Does anyone really use large SPI-NOR
flashes? If so, why? I mean you've put that controller on your SoC,
you must have some convincing arguments why a customer should use
it.

> > The first round of patches were really invasive regarding the core
> > code. So if there is a clean layering approach which can be enabled
> > as a module and you are maintaining it I'm fine with that (even if
> > the core code needs some changes then like hooks or so, not sure).
>
> That discussion started with Miquel some years ago when he was trying to to 
> solve description in DT which is merged for a while in the kernel.

What's your point here? From what I can tell the DT binding is wrong
and needs to be reworked anyway.

> And Amit is trying to figure it out which way to go.
> I don't want to predict where that code should be going or how it should look 
> like because don't have spi-nor experience. But I hope we finally move forward 
> on this topic to see the path how to upstream support for it.

You still didn't answer my initial question. Will AMD support and
maintain that code? I was pushing you towards putting that code into
your own driver because then that's up to you what you are doing
there.

So how do we move forward? I'd like to see as little as core changes
possible to get your dual flash setup working. I'm fine with having a
layer in spi-nor/ (not sure that's how it will work with mtdcat
which looks like it's similar as your stacked flash) as long as it
can be a module (selected by the driver).

-michael

Download attachment "signature.asc" of type "application/pgp-signature" (298 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ