From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6E38BC3DA4A for ; Fri, 12 Jul 2024 09:55:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References: Subject:To:From:Cc:Message-Id:Date:Content-Type:Reply-To:MIME-Version: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VHgWyoWjIKaO1gLhmwyqxCG0NgL1aQmum5wsVrDPiiE=; b=Ykbmt3YgFIClwiZ6oz+oxsOmfx LmhK3F4oP6B+q4nCKo4tVs5Bv1ugjtX5IVVIqnEqt2m5a7x9chn6I0cPfvbs25oVlHq0T4YwtAg+Z M94U81aGWbBFVTFOldvs06LW2SL14WtSV9hfwYTcJ4n0IovlZREtHLO9zHXugOUJfFw6NcL9rRozA uH3d2e3b7moCsZidVyiEPiqotEKEBPfcSaJxY8eg03skWRYeDicyWwSxQCk1SCG680jxJHYlEYcbD ZBuR8w0IqULqok40Y9CTEzstK0r09Tj98d+fk0Tkw0IEKBnY9EEgvdKl4EDvCQTHO7y686kiGbVy6 Z/bOyyVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sSD03-0000000HCKj-0fEJ; Fri, 12 Jul 2024 09:55:35 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sSCzk-0000000HCEp-0P8x; Fri, 12 Jul 2024 09:55:17 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 77F63CE0B2D; Fri, 12 Jul 2024 09:55:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D3E2C32786; Fri, 12 Jul 2024 09:55:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720778112; bh=VHgWyoWjIKaO1gLhmwyqxCG0NgL1aQmum5wsVrDPiiE=; h=Date:Cc:From:To:Subject:References:In-Reply-To:From; b=ZecFFwwtAOOh80u9qYekts6l8YtCdGU8XuUm+MNK8HHev1vlPyexWEISjh0+hvUBG 1ayBH6kTc2hC/9xkViVT/C1PqnzHi4riccGduaeyeSKvkwWNNyNK1vXVteWzbt1xzR VeMkpwkv5WclR9EqxIEq7y2n9nPq+Xh43YnebkzySOHBlCgYKLuHkqvP2E749NDGXz tq0rfl7Fx9l0cwnOpwuMqjdhzkozLhZrEtSB6L3qszO87Ax1ukfa1qPYxR5xtR3R2g 8bgkzOCE0NwnVv6RLOhJWzXfNLbJbLBUOLv/Rb3Obak1Miezs+gsvrjIzqsi7SrFvn ahkJeQYZ4mzpA== Content-Type: multipart/signed; boundary=aee9b33c528211d8b06b0c46e19f7e654e98074c381b0b5a8e637c093686; micalg=pgp-sha384; protocol="application/pgp-signature" Date: Fri, 12 Jul 2024 11:55:08 +0200 Message-Id: Cc: , , "Rasmus Villemoes" , From: "Michael Walle" To: "Esben Haabendal" , "Tudor Ambarus" , "Pratyush Yadav" , "Miquel Raynal" , "Richard Weinberger" , "Vignesh Raghavendra" , "Nicolas Ferre" , "Alexandre Belloni" , "Claudiu Beznea" Subject: Re: [PATCH v3 00/15] mtd: spi-nor: macronix: workaround for device id re-use X-Mailer: aerc 0.16.0 References: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com> In-Reply-To: <20240711-macronix-mx25l3205d-fixups-v3-0-99353461dd2d@geanix.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240712_025516_498462_BBE20AB9 X-CRM114-Status: GOOD ( 13.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --aee9b33c528211d8b06b0c46e19f7e654e98074c381b0b5a8e637c093686 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi, On Thu Jul 11, 2024 at 3:00 PM CEST, Esben Haabendal wrote: > As a consequence, the SPI_NOR_SKIP_SFDP flag is no more, and all > drivers that have been doing optional SFDP is now marked explicitly to > do that using the SPI_NOR_TRY_SFDP. First, I haven't looked at your patchset at the moment. But I'd like to take the opportunity to discuss the following (and excuse me that I didn't had this idea before all your work on this). First, I'd like to see it the other way around, that is, doing SFDP by default and let the driver opt-out instead of opt-in. This will also align with the current "SFDP only driver", i.e. if a flash is not known we try SFDP anyway. Going forward, I'd say this is also the sane behavior and we don't have to add any flags if someone want to add support for an (older) flash with the same ID but without SFDP. With the current approach, we'd have to add the TRY_SFDP flag. Now we might play it safe and add that SPI_NOR_SKIP_SFDP to any flash which doesn't do the SFDP parsing (because it has size !=3D 0 and not any of the magic flags set) - or we might just go ahead and do the probing first for *any* flashes. Yes we might issue an unsupported opcode, but we already do that with the generic SFDP flash driver. So no big deal maybe (?). Vendors where we know for a fact that they don't have any SFDP (Everspin I'm looking at you), would of course set the SKIP_SFDP flag. -michael --aee9b33c528211d8b06b0c46e19f7e654e98074c381b0b5a8e637c093686 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iKgEABMJADAWIQTIVZIcOo5wfU/AngkSJzzuPgIf+AUCZpD9fRIcbXdhbGxlQGtl cm5lbC5vcmcACgkQEic87j4CH/gW0QF/aA10t5iors/5JcBokw9E47uTSzUvxCoi NSOzc/Px3FUg1ZGuj0lS82ccJeCIbR69AX4gt2bRjp5TWDp7clxAH0mAE0UWreMw ZHmZ6GClSkkuvrktzl8GLR5tFulIDA5Xabo= =LhXX -----END PGP SIGNATURE----- --aee9b33c528211d8b06b0c46e19f7e654e98074c381b0b5a8e637c093686--