public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Pratyush Yadav <p.yadav@ti.com>
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>,
	Michael Walle <michael@walle.cc>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH] mtd: spi-nor: intel-spi: Add support for second flash chip
Date: Wed, 26 May 2021 12:24:17 +0300	[thread overview]
Message-ID: <20210526092417.GA291593@lahna.fi.intel.com> (raw)
In-Reply-To: <20210526091250.GY291593@lahna.fi.intel.com>

On Wed, May 26, 2021 at 12:12:56PM +0300, Mika Westerberg wrote:
> Hi,
> 
> On Wed, May 26, 2021 at 12:44:16AM +0530, Pratyush Yadav wrote:
> > Hi,
> > 
> > On 25/05/21 07:03PM, Mika Westerberg wrote:
> > > Intel SPI flash controller has been supporting two chip selects long
> > > time already even if the most common configuration is to have single
> > > flash chip for the BIOS and related data. This adds support for the
> > > second chip select if we find out that there are two flash components
> > > (this information is available in the mandatory flash descriptor on the
> > > first chip). The second chip is exposed as is without any partition
> > > information with name "chip1". The first chip continues work as is.
> > > 
> > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > ---
> > >  drivers/mtd/spi-nor/controllers/intel-spi.c | 208 ++++++++++++++------
> > 
> > Aren't the drivers in controllers/ supposed to move to use SPI MEM? I 
> > don't know if this has been discussed before, but I would like all 
> > drivers in controllers/ to move to SPI MEM API at some point in the 
> > future. This would let us drop support for this "legacy" controller API 
> > from SPI NOR, cleaning up the core quite a bit. No more if (nor->spimem) 
> > needed anywhere.
> 
> What is SPI MEM? :) Looking at the mainline v5.13-rc3 controllers/ there
> is no single driver "converted" to SPI MEM, at least from a quick
> clance.
> 
> > I wonder what other folks think about this. I vote for freezing all new 
> > features in controllers/. If you want something new, move to SPI MEM.
> 
> I think at this point it is not reasonable to expect that all controller
> drivers move to your new framework that has not even landed the
> mainline ;-) Or did I miss something?

Oh, I see now this commit:

a314f6367787 ("mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework")

So "SPI MEM" means generic SPI subsystem for memory mapped devices.
Unfortunately Intel controller at least is not capable of running
generic SPI transactions. It only supports accessing SPI-NOR flashes and
for those there is small set of commands that supports. I don't think it
is even possible to convert the driver to generic SPI subsystem.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-05-26 11:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25 16:03 [PATCH] mtd: spi-nor: intel-spi: Add support for second flash chip Mika Westerberg
2021-05-25 19:14 ` Pratyush Yadav
2021-05-26  9:12   ` Mika Westerberg
2021-05-26  9:24     ` Mika Westerberg [this message]
2021-05-26  9:31       ` Michael Walle
2021-05-26 10:28         ` Mika Westerberg
2021-05-31 11:27           ` Mika Westerberg
2021-06-03 11:07             ` Mika Westerberg
2021-06-03 18:08               ` Pratyush Yadav
2021-06-04 11:28                 ` Mika Westerberg
2021-06-04 11:53                   ` Mark Brown
2021-06-04 14:10                     ` Mika Westerberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210526092417.GA291593@lahna.fi.intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@microchip.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox