Hello, On 09/09/2025 at 17:37:24 +0530, Jagan Teki <ja...@amarulasolutions.com> wrote:
> On Tue, Sep 9, 2025 at 3:43 PM Miquel Raynal <miquel.ray...@bootlin.com> > wrote: >> >> Hello, >> >> On 02/07/2025 at 11:23:13 +02, Miquel Raynal <miquel.ray...@bootlin.com> >> wrote: >> >> > These chips are internally made of two/four dies with linear addressing >> > capabilities to make it transparent to the user that two/four dies were >> > used. There is one drawback however, the read status operation is racy >> > as the status bit only gives the active die status and not the status of >> > the other die. For commands affecting the two dies, it means if another >> > command is sent too fast after the first die has returned a valid >> > status (deviation can be up to 200us), the chip will get corrupted/in an >> > unstable state. >> > >> > The solution adopted here is to iterate manually over all internal >> > dies (which takes about 30us per die) until all are ready. This approach >> > will always be faster than a blind delay which represents the maximum >> > deviation, while also being totally safe. >> > >> > A flash-specific hook for the status register read had to be >> > implemented. Testing with the flash_speed benchmark in Linux shown no >> > difference with the existing performances (using the regular status read >> > core function). >> > >> > As the presence of multiple dies is not filled in these chips SFDP >> > tables (the table containing the crucial information is optional), we >> > need to manually wire the hook. >> > >> > This change is adapted from Linux. >> > >> > Link: >> > https://lore.kernel.org/all/20250110-winbond-6-12-rc1-nor-volatile-bit-v3-1-735363f8c...@bootlin.com/ >> > Signed-off-by: Miquel Raynal <miquel.ray...@bootlin.com> >> >> Same question for this one, no feedback for the past 2 months, I'm not >> sure who's supposed to take these, Jagan and Vignesh you are marked M: >> in maintainers, any chances this can get it? > > Unfortunately, I was off quite some-time. Need little bit of time. > Vighnesh is off for years. In the meantime, Michael will help in > review but need help on testing. I didn't add Michael because he was not listed for this change, perhaps he should be added to the MAINTAINERS file? (or maybe I used an old version without noticing) I don't know if testing each every change carefully makes sense in this context. There have been many contributions probably worth the try (not mine, Mikhail's) which are hard if not impossible to test by a single person, while quite relevant. Reviewing seems quicker and more relevant? Thanks, Miquèl
