Received-SPF: pass (google.com: domain of linux-kernel+bounces-132696-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 5 Apr 2024 12:03:27 +0300
From: Dmitry Rokosov <ddrokosov@salutedevices.com>
To: Greg KH <gregkh@linuxfoundation.org>
CC: <quic_sridsn@quicinc.com>, <quic_mdalam@quicinc.com>, <ezra@easyb.ch>,
	<gch981213@gmail.com>, <miquel.raynal@bootlin.com>, <richard@nod.at>,
	<sashal@kernel.org>, <vigneshr@ti.com>, <kernel@salutedevices.com>,
	<rockosov@gmail.com>, <linux-kernel@vger.kernel.org>,
	<linux-mtd@lists.infradead.org>, Ezra Buehler
	<ezra.buehler@husqvarnagroup.com>, <stable@vger.kernel.org>, Martin Kurbanov
	<mmkurbanov@salutedevices.com>
Subject: Re: [PATCH v1] mtd: spinand: Add support for 5-byte IDs
Message-ID: <20240405090327.vowrj6aqjmmighs4@CAB-WSD-L081021>
References: <20240404121532.14755-1-ddrokosov@salutedevices.com>
 <2024040509-faceless-passerby-10ad@gregkh>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2024040509-faceless-passerby-10ad@gregkh>
User-Agent: NeoMutt/20220415

On Fri, Apr 05, 2024 at 08:37:48AM +0200, Greg KH wrote:
> On Thu, Apr 04, 2024 at 03:15:21PM +0300, Dmitry Rokosov wrote:
> > From: Ezra Buehler <ezra.buehler@husqvarnagroup.com>
> > 
> > [ Upstream commit 34a956739d295de6010cdaafeed698ccbba87ea4 ]
> 
> This commit is already in the following releases:
> 	6.6.24 6.7.12 6.8.3 6.9-rc1
> 
> > E.g. ESMT chips will return an identification code with a length of 5
> > bytes. In order to prevent ambiguity, flash chips would actually need to
> > return IDs that are up to 17 or more bytes long due to JEDEC's
> > continuation scheme. I understand that if a manufacturer ID is located
> > in bank N of JEDEC's database (there are currently 16 banks), N - 1
> > continuation codes (7Fh) need to be added to the identification code
> > (comprising of manufacturer ID and device ID). However, most flash chip
> > manufacturers don't seem to implement this (correctly).
> > 
> > Cc: <stable@vger.kernel.org> # 6.6.23
> > Cc: <stable@vger.kernel.org> # 6.7.11
> > Cc: <stable@vger.kernel.org> # 6.8.2
> > Signed-off-by: Ezra Buehler <ezra.buehler@husqvarnagroup.com>
> > Reviewed-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
> > Tested-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-2-ezra@easyb.ch
> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > ---
> > 
> > In the patch series [1] only one patch was marked with Fixes tag, that's
> > why the secon patch was not applied to 6.6.y, 6.7.y and 6.8y. It breaks
> > ESMT detection flow with logs:
> > 
> > [    0.770730] spi-nand spi0.0: unknown raw ID c8017f7f
> > [    0.772688] spi-nand: probe of spi0.0 failed with error -524
> > 
> > Please cherry-pick the second patch from the series to 6.6.y, 6.7.y and
> > 6.8.y.
> 
> What commit id is "the second patch" here?  The one referenced above?
> If so, again, this is already in a released kernel, so I'm confused as
> to what to do here.

Ah, I apologize for not checking versions 6.8.3 and 6.7.12. My test
environment was running on versions 6.8.2 and 6.7.11. Therefore, the
mistake was on my part. Please disregard the cherry-pick for those
versions, and thank you for quick reply!

-- 
Thank you,
Dmitry