Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3508200pxb; Wed, 14 Apr 2021 07:07:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxIR5+5xbpfo/gyomHxYoYkqahF15FCkgNDzufDiNyzvZ91rqHtYl4do0WlQFsYsyvSz6R X-Received: by 2002:a05:6000:250:: with SMTP id m16mr44074590wrz.325.1618409257800; Wed, 14 Apr 2021 07:07:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618409257; cv=none; d=google.com; s=arc-20160816; b=igQNPnbaL/taTlel5U/Xak8EfbD5AzFlulTPm10qxgveFtSNj3J3Or5IoRYX5n8i2n T44xB8KcfECjH3hbo5Mv0A+TlFcF1TCcThRhPv5UmCpfm/ELHlQPiq3KoqYDvUytc8P5 IsUE2V0wSPKy8gmMNKOCvXcwtuHdM+K31mgenA4bi69PE8b5MNVsaKXC/qN8axEoVloP l9pEftd4FeRRST0mRNMnt6U5OWN6ho7OUia+rzY/kNhDxeQZW95+yYar1kDA99PUX2/9 btWuqmFIrUYrgpE2nCNGHXIfhd+A1KD4vrk1zpDaWE57yArsSkbGe7nYJwZFSDlbc+or qQnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5FpXG6BxL1eix7ZuvEbTaKFw6E4r9hjxDvOS4dYSkAY=; b=Ol4xU1BfJ2O8L0P3w1eAxAFUx+ReLRHJ738PKuQjG6tZpR89E+Ncq5YgjyBaGo8yZ9 VFmXdzGVFn8jv4le/l2tOG8FEo18YqvuCmVJjGW+8eItlKcPRXrUaEbfLYZKDyWFZUw/ oMfZXzB+hoHa7BiHnvieHb/t9yIWk/8xURc7GjGvNX7irm/n5QxG3dKtM2PycLTGmzip ZLApQ5mfu+RBDo/YYbXFJ1fR8HIF16I8biGavSeeQ8JKCjPzZ+SiHXZSTtKkst/NydYb avZWsFJMeMCAeT1naZnT1EK1j9eSAYq2DBm1FeI8HWIMN8JN5RoB35Tl60jMqZ551ZUv qreg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="ZrC/mbRq"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga16si4742373ejc.102.2021.04.14.07.07.14; Wed, 14 Apr 2021 07:07:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="ZrC/mbRq"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346600AbhDNGyA (ORCPT + 99 others); Wed, 14 Apr 2021 02:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349530AbhDNGxr (ORCPT ); Wed, 14 Apr 2021 02:53:47 -0400 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A82B9C061574 for ; Tue, 13 Apr 2021 23:53:26 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id t140so13703709pgb.13 for ; Tue, 13 Apr 2021 23:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5FpXG6BxL1eix7ZuvEbTaKFw6E4r9hjxDvOS4dYSkAY=; b=ZrC/mbRqviwCrp5s59OqqAyhvEdMRY3USfk7e6ubgSvZVNx2+4IzlpYBZnp6NjL6nJ EQAbg1Wrn0hW8AwBhkp8kJbeWwvXuo8eLX5AA66ahZgvxqh/xIPVYbYadIMrumBClMOg t5OxvcggD/+s7eVHhjKwCFsyK0Iutbox1Fco8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5FpXG6BxL1eix7ZuvEbTaKFw6E4r9hjxDvOS4dYSkAY=; b=dMB2CFp30uazp2XSi18zJ9poJSqjjZmveNoK4AoZ6AmKyYloIX+0fdGlEHeMLGuY1x 1yZEZ8dXDazXqZ3uHfWb+2nZCnFiYmKQV4IMmF3o8tLz1FEqyquQgki3XwlUXYx8BSTT kNZXwsnMmXo3NNEbbhubMArMBGAXKIC6SHkZ9VvhiM4VmLPY3uSheFPAlfXPWjpjgNdb yCSj0eGrr7lFyUgV4P8KUuhwjkAy1zQZD4sXWbll7GJXHIXsnpDTBJzbUjl7iLojDggu elj79eU6ReEGb3XvECX4ZPq9SHCwyMOCiIQ1J//BTRh9S52lBB+r2lTWE6Zg5kBYsAkw YaJw== X-Gm-Message-State: AOAM5323q3hXv/M2tpK2t/z4uqTZGdbmqIqyLqcPanIoNpANZIPp2/DA 41NoJkvhG2AP4nvA0kCYMZ3aaraz4kcdjPa/BPyApA== X-Received: by 2002:a63:525c:: with SMTP id s28mr35660389pgl.317.1618383206183; Tue, 13 Apr 2021 23:53:26 -0700 (PDT) MIME-Version: 1.0 References: <20210413120210.3671536-1-ikjn@chromium.org> <51761f1db840c51bad17f5f275b4ce1a@walle.cc> In-Reply-To: <51761f1db840c51bad17f5f275b4ce1a@walle.cc> From: Ikjoon Jang Date: Wed, 14 Apr 2021 14:53:15 +0800 Message-ID: Subject: Re: [PATCH] mtd: spi-nor: macronix: Add block protection support to mx25u6435f To: Michael Walle Cc: linux-mtd@lists.infradead.org, Miquel Raynal , Pratyush Yadav , Richard Weinberger , Tudor Ambarus , Vignesh Raghavendra , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org HI Michael, thanks for the review. On Tue, Apr 13, 2021 at 8:26 PM Michael Walle wrote: > > Hi Ikjoon, > > Am 2021-04-13 14:02, schrieb Ikjoon Jang: > > This patch adds block protection support to Macronix mx25u6432f and > > mx25u6435f. Two different chips share the same JEDEC ID while only > > mx25u6423f support section protections. And two chips have slightly > > different definitions of BP bits than generic (ST Micro) > > implementation. > > What is different compared to the current implementation? Could you give > an example? Two chips have different definitions on BP and T/B bits. - 35f has 4 BPs without T/B, BP3 behaves like T/B bit. - 32f has 4 BPs plus T/B on CR. # MX25U6435F BPs | BP3=0 | BP3=1 --------------------- 000 | None | 1/2 001 | 1/128 | 3/4 010 | 1/64 | 7/8 011 | 1/32 | 15/16 100 | 1/16 | 31/32 101 | 1/8 | 63/64 110 | 1/4 | 127/128 111 | 1/2 | All # MX25U6432F BPs | T/B=0 | T/B=1 --------------------- 0000 | None | None 0001 | 1/128 | 1/128 0010 | 1/64 | 1/64 0011 | 1/32 | 1/32 0100 | 1/16 | 1/16 0101 | 1/8 | 1/8 0110 | 1/4 | 1/4 0111 | 1/2 | 1/2 1xxx | All | All It seems that 35f has a unique definition on bottom protections than others. Assuming there's no way to distinguish between mx25u6435f and 32f, This patch simply takes the common parts only - BP[2:0] without using T/B or BP3 at all. But the current swp implementation implies that "BP with all ones" is to be 'all' protection while in this approach it's 1/2, A hidden BP3 should be involved for 'all' protection. > > > So this patch defines a new spi_nor_locking_ops only for macronix > > until this could be merged into a generic swp implementation. > > TBH, I don't really like the code duplication and I'd presume that it > won't ever be merged with the generic code. Agree, I hope I could make a more generalized version into swp.c. Honestly I expected that I just needed to add one line of SPI_NOR_HAS_LOCK to flash_info to support mx256432f (this was the main purpose of my patch) before I read the datasheets. :) > > You also assume that both the WPSEL and T/B bit are 0, which might not > be true. Please note that both are write-once, thus should only be read. yep, that also should be considered, I'm thinking just not to support WPSEL=1 case for now. > > See also: > https://lore.kernel.org/linux-mtd/346332bf6ab0dd92b9ffd9e126b6b97c@walle.cc/ > Thanks, let me try it. > -michael