All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Malat <oss@malat.biz>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Pratyush Yadav <p.yadav@ti.com>,
	linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Rob Herring <robh+dt@kernel.org>,
	Tudor Ambarus <tudor.ambarus@microchip.com>
Subject: Re: [PATCH] spi-nor: sfdp: Allow configuring unknown flashes using SFDP
Date: Thu, 27 May 2021 17:45:08 +0200	[thread overview]
Message-ID: <20210527151702.GA4807@ntb.petris.klfree.czf> (raw)
In-Reply-To: <64dd1df6-0ace-702b-f205-a7c7d4d12697@ti.com>

On Thu, May 27, 2021 at 07:22:19PM +0530, Vignesh Raghavendra wrote:
> >>> This change allows adding a support for flashes with correct SFDP
> >>> without recompilation of the kernel by setting sfdp-compatible property
> >>> in their node. Alternatively, sfdp_compatible module option can be used
> >>> to list JEDEC IDs of flashes, whose SFDP can be trusted. Star "*" can
> >>> be used to match all JEDEC IDs.
> >>
> >> I have skimmed through the patch. Before I look at it more closely, I 
> >> want to understand the use case for this patch. Why would you not want 
> >> to recompile the kernel when adding support for new hardware? Do you 
> >> want the ability to support flashes on devices that have already been 
> >> deployed in the field? Is it something that comes up frequently?
> > In my case the kernel is loaded from a USB mass storage device, which
> > can be preproduced and on stock (with the kernel already on it). With
> > my patch I can change the flash vendor without the need of updating
> > the image on already existing USB mass storage devices.
> > 
> > The patch is also useful for people who use distribution kernel as they
> > will not have to wait until (and if) the distribution updates it.
> 
> Don't need separate DT property or cmdline argument. There is no way to
> know if the SFDP tables are 100% valid when kernel is working with a
> "generic flash".
> Flashes are often replaced with newer revisions of the part that may/may
> not have valid SFDP tables.
> 
> So just rely on SFDP, when no valid entry is found in the manufacturer's
> flash_info[] while printing out a warning to user that this is just best
> effort support.

OK, I will rework it to fallback to SFDP by default. I put the safeguard
there to avoid a case when one has a flash requiring workarounds and then
does a kernel downgrade to a release where the flash is not known and uses
it. Should I make an opposite flag sfdp-incompatible or do we consider this
a theoretical scenario not worth of addressing in the code?
  Petr

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

  parent reply	other threads:[~2021-05-27 17:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 16:07 [PATCH] spi-nor: sfdp: Allow configuring unknown flashes using SFDP Petr Malat
2021-05-21  9:55 ` Pratyush Yadav
2021-05-21 11:53   ` Petr Malat
2021-05-27 13:52     ` Vignesh Raghavendra
2021-05-27 13:54       ` Pratyush Yadav
2021-05-27 15:45       ` Petr Malat [this message]
2021-05-28 11:56         ` Vignesh Raghavendra

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=20210527151702.GA4807@ntb.petris.klfree.czf \
    --to=oss@malat.biz \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.