From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 560E32550D4 for ; Mon, 24 Nov 2025 09:15:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763975738; cv=none; b=U0BZpWM8S7D34ftW1PNeEjGcuS48qtUwqfsNs2R5xCKxDj+R8Dayntoi5ytb3MluvglHgjiGTcmdYh/JscOMu7teGtyndpOyi4CN7/WNVAqwJfDti6uCHWE+sc4u70ALaSz8HrxnE/WlYmv8FZ5CeIXF1fRSMNfrUoqEcgkiW3E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763975738; c=relaxed/simple; bh=1MJA9jUsBQe0qZcQzOnCGMVR0mKK0MIo0I6RwBPlCpg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=btqK5ZUwNIy5XmjsU0LLWQVuQQ5tvpTyaXiF3mxCsFdRiSb3x33CvNrAQoZPXr/jFJGShH04YgPrIWNlWTKYIn5HEt2y8gqbrAzG3l2F2b2VP/QuqCBApQWFkRMWgeNZJX6bTTlB+iY8D7un6GCnP5DVqhoCWV9xFw9pyoAV+pc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=HpnpNCbV; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="HpnpNCbV" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id E71D5C13998; Mon, 24 Nov 2025 09:15:10 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 640AF606FC; Mon, 24 Nov 2025 09:15:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 9D5AF103713AF; Mon, 24 Nov 2025 10:15:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1763975732; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=03OD2P7ERGBbMgJiyugvPdSPJyomRkhnTmtbVz/dSh0=; b=HpnpNCbVCEwC6zcDqvyAMfa0wevqDDYwnID803/o1/ZYO2X9sgXnfGlg6YxuRZsReGrPSr ZkocVNZdOQkdG8Mws2I91qKyek+7zXoH5FkA4vpRu2FQqhfGVx55zwfRONcOtR3AR8mOCE OxGWOkZjQsD5bxDK9YlRFepLYJ4b8U7HfrYkymd6yIZddecTunyOKrHvBp440Yh7cdOxnl KCana2Ac57SJNXctzJ4Zj3KhKQN2nHjJJe3R6qmtM3QCzrK7VAtuD++30a3+BH5SBqAlCT VZJPBbV7joyaK2E2DGd++X5wKQuSXiEa16WTsMj7+plr0s2xC8KR7NnqH9uIvw== From: Miquel Raynal To: "Michael Walle" Cc: "Marc Olberding" , "Tudor Ambarus" , "Pratyush Yadav" , "Richard Weinberger" , "Vignesh Raghavendra" , , Subject: Re: [PATCH] mtd: spi-nor: Fix w25q01jv flags In-Reply-To: (Michael Walle's message of "Mon, 24 Nov 2025 09:50:27 +0100") References: <20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com> <87jyzfzwpw.fsf@bootlin.com> <87bjkrzvk7.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Mon, 24 Nov 2025 10:15:28 +0100 Message-ID: <87wm3fyeof.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 On 24/11/2025 at 09:50:27 +01, "Michael Walle" wrote: > On Mon Nov 24, 2025 at 9:25 AM CET, Miquel Raynal wrote: >> Hi, >> >> On 24/11/2025 at 09:12:38 +01, "Michael Walle" wrote: >> >>> Hi, >>> >>>>> + .no_sfdp_flags =3D SECT_4K, >>>> >>>> This one is the right fix and should stand alone in its own patch (fir= st >>>> in the series if you add support for the block protection). >>> >>> Only if that flash really doesn't have SFDP. But since the entry >>> didn't have a size property the flash *must* have SFDP in the first >>> place. Otherwise it won't even be probed. Please provide a dump of >>> the SFDP tables, see [1]. >> >> SFDP data is in lore > > At least yours :) And if I decode that correctly by hand, it has the > 4k erase size bit set as well as the correct opcode 20h or 21h for > 4byte addressing. > >> , but not the params which are missing (?) Marc, can >> you compare with your data? >> https://lore.kernel.org/all/20250110-winbond-6-12-rc1-nor-volatile-bit-v= 3-1-735363f8cc7d@bootlin.com/ >> >>> Also please provide the contents of >>> /sys/kernel/debug/spi-nor/spiN.N/params. >>> >>> -michael >> >> My understanding (which may clearly be erroneous) is that most of these >> flashes support 4K blocks but somehow don't advertise it in their SFDP >> data, so every time we describe a chip we must remember to tick that >> flag. > > Which flag? SECT_4K? I don't think that will be used at all, does > it? It's only used in spi_nor_no_sfdp_init_params() which in turn is > only called in spi_nor_init_params_deprecated() (or if SKIP_SFDP is > set).=20 > >> I guess all^Wmost chips have 4k blocks compatibility support, but in >> general we prefer to use bigger blocks (the ones advertised in the SFDP >> data). Michael, am I being mislead by the decades of history that went >> through the spi-nor core? :) > > You mean CONFIG_MTD_SPI_NOR_USE_4K_SECTORS? But that has nothing to > to with the flashdb/sfdp parsing. Well I expect CONFIG_MTD_SPI_NOR_USE_4K_SECTORS to have no effect if the SECT_4K flag is unset. I believe Marc is using the same chip as I am, but enabled this option for compatibility reasons? But as you say, this 4K capability is advertised by "my" chip, so if Marc faces an issue with it, it may indicate that we are having an ID collision? Thanks, Miqu=C3=A8l