From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 EA0FE72631 for ; Mon, 24 Nov 2025 08:50:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763974237; cv=none; b=AgiNSrOMmtHpx7VM8wJaorv9Q0/oBvmQHta7aPAU6e4aOrzbzN1O7iDGv8YV9ng1CKlbHE1Tzkfh39gGzEQu/o9GNQyegxNXFtu4Q88d0S7u6VNJ2iS6br+qxhN/X5C7Ff3IFWSOL1aSfMkaBxlprMerND50vkS/HZuSo6DqdUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763974237; c=relaxed/simple; bh=nZ5XJHT6b6jo0JMJAgi257X1GZmJ6tQvUT4N0yyiC+U=; h=Mime-Version:Content-Type:Date:Message-Id:To:Subject:Cc:From: References:In-Reply-To; b=cfNnbF1XnYwYDZGjjVkjEf2BO5JnEq/40Pw532UUKiSOlA169UI5Bji+qWY3Jz1JsOlbCxiKUzTpYI5FMnLBx3LA5LmnVc0bNLxWpDci3fvQ3BXJLIGnH8bUwu379ddmL4B9KuJKqrBceAsvSBYQJaRVJcGNB3Nefc01YuHL3GM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MKa5CCwK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MKa5CCwK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1F03C4CEF1; Mon, 24 Nov 2025 08:50:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763974236; bh=nZ5XJHT6b6jo0JMJAgi257X1GZmJ6tQvUT4N0yyiC+U=; h=Date:To:Subject:Cc:From:References:In-Reply-To:From; b=MKa5CCwKcUOYlf1AXmhUo6IAFW8+DslNPhxHjgQigf7qstRZQUel9phhR5xYzTrnc U4pkH552xZRNV5bSp8rx1ajHFy9xe13jzE3ymR57M9n7gSiEG9lLV9VzUcyViJU1K5 mRZjeDsTqP+XNzeeAZwFcrgB7OX0e3H0OBGXVXChotDd711AkZSuBJ5jqK4iH7HfRG ZWep8RSaF13+WLZWq+rYj76HkeLEb/J0n4qyKO9zKc4RqkJC19y8ckfo/Y0EyIwodM XmKdSDUsNyWDdcIAhChHWWoE87D+ECzg77SQqkWFW0vRkKDM2wl940pjtICBa3Hjmb 3fIGhIFbNMUNw== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: multipart/signed; boundary=936d147121f3cbc70ca7a52323f099e93918d9f04cfc98dca8630d4a857f; micalg=pgp-sha384; protocol="application/pgp-signature" Date: Mon, 24 Nov 2025 09:50:27 +0100 Message-Id: To: "Miquel Raynal" Subject: Re: [PATCH] mtd: spi-nor: Fix w25q01jv flags Cc: "Marc Olberding" , "Tudor Ambarus" , "Pratyush Yadav" , "Richard Weinberger" , "Vignesh Raghavendra" , , From: "Michael Walle" X-Mailer: aerc 0.20.0 References: <20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com> <87jyzfzwpw.fsf@bootlin.com> <87bjkrzvk7.fsf@bootlin.com> In-Reply-To: <87bjkrzvk7.fsf@bootlin.com> --936d147121f3cbc70ca7a52323f099e93918d9f04cfc98dca8630d4a857f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 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 (firs= t >>> 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-v3= -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. -michael > >> [1] https://docs.kernel.org/driver-api/mtd/spi-nor.html#minimum-testing-= requirements >> >>> >>>> .fixups =3D &winbond_nor_multi_die_fixups, >>>> }, { >>>> .id =3D SNOR_ID(0xef, 0x50, 0x12), >>> >>> Thanks, >>> Miqu=C3=A8l --936d147121f3cbc70ca7a52323f099e93918d9f04cfc98dca8630d4a857f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iKgEABMJADAWIQTIVZIcOo5wfU/AngkSJzzuPgIf+AUCaSQcUxIcbXdhbGxlQGtl cm5lbC5vcmcACgkQEic87j4CH/iT8QF+LY0WWwF1vuL3tDvq9wEHkNHwFMeuYn89 irBj2dPTSbq/h1QLcTLWRx46g8jFB/jSAXoCN/ljYV8oI98R8bamIhSvjOUlSIsL QaZLtiQgcr7CsE9hZc00JkdDGxfWoc+beWc= =PtPP -----END PGP SIGNATURE----- --936d147121f3cbc70ca7a52323f099e93918d9f04cfc98dca8630d4a857f--