From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (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 353642E22B5 for ; Thu, 13 Aug 2026 06:48:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786603743; cv=none; b=jZD/sEh6ZM2QRBjg+YiMwMNZ2HXo6CiEafBO298bvrpzL2E/oRCN19Zx+tsNlew+5pLPn6eDhC/TDmZK4sROlkJjryRCauZa9+VymfPVYHcvEi5Wl8d0R7f6MtcVxV5uaJ2pu+mae3YKvG38WztzTWlMb7eGYg/jVelplVBd8fg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786603743; c=relaxed/simple; bh=k0WFzS2DkZp5+l62dmOllST4a45BLpR+80dQj6AzQRU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=T7M1FwwXOCDgCQSDcRqfPcYqnMBrsv5ZsQrg9qLw54hJRU3+a5gU8V45E2RDaT9AfBiw3O/KOX74YZHCDut7YeKIqyWoEaQ+U/168zQ4iZFB1LrEPGlyj0cDnkRzAHr9MR7q+5WkxNcz7dwP6ME+ZC4zMhbuFqzTarixpHBVbKk= 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=kHnbYAlS; arc=none smtp.client-ip=185.246.85.4 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="kHnbYAlS" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 2826F4E411E0; Thu, 13 Aug 2026 06:48:57 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id DD5D7602B8; Thu, 13 Aug 2026 06:48:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 7A4BE11C4D998; Thu, 13 Aug 2026 08:48:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1786603732; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=QztDvkrTOg0tEXWNbD2tiy7gnCiVPZ43TKonFLmn7bc=; b=kHnbYAlS6UqhcwdOwgGOP74hfnHrXY2AsAMHvoze4HBxrKEvGcxVDI9kMCYpekCrovDO4e kVyXuddoTiACTZZUmdhHbpihKi37X+ARnGVREMu21/UagqJPv36T9kin0Q5qPmt0LCJxbR NZ72MhRr54qIMZhZNiVEUTUrHnf6XOFPTfF/L2Eb27rh3OUmDsPTY8LHF7d4qpVEg2Gski t2kO0pYaJ4JFStDj5WAOEW7/rZSqHh37OarSzLa41sxDODcimZ+GDKnExP7CJ+03NsHm7m I480TA8oeiESBt9/KBVVl78zdyvvWLh65c+WpSxshlTKOEBRerfZBvt38t9cfA== From: Miquel Raynal To: "han.xu" Cc: Richard Weinberger , Vignesh Raghavendra , Peter Pan , Boris Brezillon , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Han Xu Subject: Re: [PATCH] mtd: spinand: Enable QE on all dies In-Reply-To: (han xu's message of "Wed, 12 Aug 2026 11:34:26 -0500") References: <20260807-spinand_qe-v1-1-c102c79834a3@nxp.com> <87qzk6s8yr.fsf@bootlin.com> User-Agent: mu4e 1.12.12; emacs 30.2 Date: Thu, 13 Aug 2026 08:48:47 +0200 Message-ID: <87v79eldm8.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 X-Last-TLS-Session-Version: TLSv1.3 >> > + /* >> > + * QE is a per-die setting on some devices. Program each target >> > + * individually when enabling or disabling quad I/O mode. >> > + */ >> > + for (target = 0; target < nand->memorg.ntargets; target++) { >> > + ret = spinand_select_target(spinand, target); >> > + if (ret) >> > + return ret; >> > + >> > + ret = spinand_upd_cfg(spinand, CFG_QUAD_ENABLE, >> > + enable ? CFG_QUAD_ENABLE : 0); >> > + if (ret) >> > + return ret; >> >> If there is an issue in the middle of the loop, the chip will become >> unusable. Perhaps we should reset the dies to the !QE state and return >> an error to continue in degraded (single) mode if that happens? > > > Single-lane is the most basic op - if the QE set_feature write fails, the link > is broken and single-lane won't work anyway. And falling back needs the vendor's > own 1S op stored somewhere, but those variant tables are discarded after probe. > So it likely requires refactoring struct spinand_device to cache them. Given that, > maybe just keep the current return-error implementation. Ack.