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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35156C04E69 for ; Wed, 16 Aug 2023 12:38:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244737AbjHPMhg (ORCPT ); Wed, 16 Aug 2023 08:37:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244388AbjHPMhK (ORCPT ); Wed, 16 Aug 2023 08:37:10 -0400 Received: from mail.3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E851D1FDC; Wed, 16 Aug 2023 05:37:09 -0700 (PDT) Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 3514AA06; Wed, 16 Aug 2023 14:37:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1692189428; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vJfh6GC8aHch959POkYyqkTUnj4NnXdjMKw7FcRwKoc=; b=u8hsom4F23QN+Q0vmRp43G18VGyk4NagNu0MBrNjIj82pxXy7IdgNV1LyTKVVledQSz0Mr yWqNrOj03deQUT0jvO8ZmrKfCDriYz9ymRcOGi9FU2T5d0Wbs/p088U7l0anJN/JvEFOu0 gEvQd+3d60Qg3aElZTBAvP9OJPTrCzb1vUnAhZJGSMps6CWM1kQ58UFp+laD9NR5/rcw1n C1tWsUsHbPCaeKpN9GnRRcpO5a6NkVK9RA7baa99xytvA59XKaUtFl0ZpgUs+d54oRVXFg NgpVc/pmdUwmfzBl1mXRHjIQvgjjrtSl+fT8m9Qo4GCuwQtGVtSDq9dtjW841A== MIME-Version: 1.0 Date: Wed, 16 Aug 2023 14:37:07 +0200 From: Michael Walle To: Tudor Ambarus Cc: Hsin-Yi Wang , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , Bjorn Andersson , Pratyush Yadav , "Miquel Raynal )" , "Richard Weinberger )" , "Vignesh Raghavendra )" , Rob Herring , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, AngeloGioacchino Del Regno , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, cros-qcom-dts-watchers@chromium.org, Andy Gross , Konrad Dybcio Subject: Re: [PATCH v2,1/2] mtd: spi-nor: giga: gd25lq64c: Disable quad mode according to bus width In-Reply-To: <0011a25a-e096-73ac-9800-9d8e35efdc8b@linaro.org> References: <20230816104245.2676965-1-hsinyi@chromium.org> <6702bac712daab13698b9bb9ad81d49e@walle.cc> <5911201a-f703-abbd-3c7b-769f70df08a8@linaro.org> <80ec748f37f40ae5c3c3c5d1602681b3@walle.cc> <0011a25a-e096-73ac-9800-9d8e35efdc8b@linaro.org> Message-ID: X-Sender: michael@walle.cc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi, >>>> like a fundamental problem and that commit 39d1e3340c73 ("mtd: >>>> spi-nor: >>>> Fix clearing of QE bit on lock()/unlock()") is broken in that >>>> regard. >>> >>> what's wrong with the mentioned commit? >> >>         } else if (nor->params->quad_enable) { >>                 /* >>                  * If the Status Register 2 Read command (35h) is not >>                  * supported, we should at least be sure we don't >>                  * change the value of the SR2 Quad Enable bit. >>                  * >>                  * We can safely assume that when the Quad Enable >> method is >>                  * set, the value of the QE bit is one, as a >> consequence of the >>                  * nor->params->quad_enable() call. >>                  * >>                  * We can safely assume that the Quad Enable bit is >> present in >>                  * the Status Register 2 at BIT(1). According to the >> JESD216 >>                  * revB standard, BFPT DWORDS[15], bits 22:20, the >> 16-bit >>                  * Write Status (01h) command is available just for >> the cases >>                  * in which the QE bit is described in SR2 at BIT(1). >>                  */ >>                 sr_cr[1] = SR2_QUAD_EN_BIT1; >>         } else { >>                 sr_cr[1] = 0; >>         } >> >> "We can safely assume that when the Quad Enable method..". We cannot, >> if we >> don't have 4 I/O lines. The quad_enable is just the op how to do it, >> but not >> *if* can do it. It seems to be missing the same check as the >> spi_nor_quad_enable(). But I'm not sure if it's that simple. >> > > I see. Then extending the if condition should do the trick, as > spi_nor_write_16bit_sr_and_check() is called after setup. Something > like: > > if (spi_nor_get_protocol_width(nor->read_proto) == 4 && > spi_nor_get_protocol_width(nor->write_proto) == 4 && > nor->params->quad_enable) > > Is this what Hsin-Yi is hitting? Hopefully :) -michael