Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp802663imm; Wed, 23 May 2018 05:54:35 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqhqj+WMz6uFeLS6oziZSz0dvbNE15Sh6SWQLvxLbThKMY+D3fRw8dIr7ql8QvDZeHueF9l X-Received: by 2002:a17:902:8bc4:: with SMTP id r4-v6mr2820873plo.381.1527080075268; Wed, 23 May 2018 05:54:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527080075; cv=none; d=google.com; s=arc-20160816; b=ZnpVPDjatBlH2qzsTgyvc+C6R+t8Jiy+CePPnDx1y4qCn4sMUcJ1pdDnVZ7WZZryGD WSZMnVAIqqmOEO8h7AvkB+/gzRTflFt1ShhsxNITuIPR+MteJDmvmSGh0Q+cG0VB0fTz DDckalCVfP/m5ps1tpMV+1aaNlGleBj5zxhk54zSDxdIK0aS9JZMtx4vXmAKDnCt9OJ0 bwBslNXjWmKbmruYhmpsHcBH2/O8StZOqjwrDee3TSayfmGylU8h4IuIIUgAPB/3hEpS 7Dsbk0ngYiRR0fsEhNn9hshNLtoXfCjghE/lIw3QELfDa1XosgAwJHiIXPs05rcN5w0/ dbZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Zkt0K/6ss7j7I2YyXEorl9Y+PURebcdIyVy6WtDvjtk=; b=ZdM6R4wn7OZI320Z1y1d/iWBmWNJRSd/HwPJofHG3R2wnYPr639rPnida1hs2+dbKx AmNY5tcp5P+hX+nAYZ/dRz2NJPybdgCTr9ilaoMlC8o6tQ24Vy1GNm2Mx6kGL0HZmOLU uSgr0FZENCSsukwlzxzNtU0ObLYTHSyns5Fz8k/HjgtMQ6J27mH3gU1ugT5DKbPHBbTS jC/vHqIsm6q3IAWcNVYU3uLrm/sVN8ibK4X+egI6L4z85DBN9KkR1l+9PXjplBtx8zXg xJCFVsnL8MheO77x1SDwJM9xt82yXQ1d+655/A88mkJX7TIQB3gp28WdKPzZpHbUm2el rlgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w127-v6si18801365pfd.313.2018.05.23.05.54.20; Wed, 23 May 2018 05:54:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932876AbeEWMwV (ORCPT + 99 others); Wed, 23 May 2018 08:52:21 -0400 Received: from esa4.microchip.iphmx.com ([68.232.154.123]:3099 "EHLO esa4.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932089AbeEWMwU (ORCPT ); Wed, 23 May 2018 08:52:20 -0400 X-IronPort-AV: E=Sophos;i="5.49,433,1520924400"; d="scan'208";a="14264235" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa4.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2018 05:52:19 -0700 Received: from localhost.localdomain (10.10.76.4) by chn-sv-exch02.mchp-main.com (10.10.76.38) with Microsoft SMTP Server id 14.3.352.0; Wed, 23 May 2018 05:52:18 -0700 Subject: Re: [RFC PATCH] mtd: spi-nor: add support to non-uniform SPI NOR flash memories To: Marek Vasut , , , , , CC: , , , References: <20180518093233.24241-1-tudor.ambarus@microchip.com> <89d45190-95b0-b780-b219-e6c6adcb6147@gmail.com> <4cd7d47a-fd56-6b54-3b38-262adf46a97f@microchip.com> <123e50da-e49e-f876-bdb4-2719f7f7640a@microchip.com> From: Tudor Ambarus Message-ID: <66b2b859-72db-33cc-75ae-2493a4aad235@microchip.com> Date: Wed, 23 May 2018 15:52:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Marek, On 05/23/2018 12:56 PM, Marek Vasut wrote: [...] >>> [...] >>> >>>>>> + while (len) { >>>>>> + cmd = spi_nor_find_best_erase_cmd(map, region, addr, len); >>>>>> + if (!cmd) >>>>>> + return -EINVAL; >>>>> What would happen if you realize mid-way that you cannot erase some >>>>> sector , do you end up with partial erase ? >>>> Is this possible? In non-overlaid regions, the address is aligned with >>>> at least one of the erase commands, else -EINVAL. For overlaid regions >>>> alignment doesn't matter. But yes, if this is possible, in this case, >>>> this proposal will do a partial erase. >>> Shouldn't we fail up front instead ? >> It will be great if we can do this without having performance penalties. >> Can we loose the conditions for the last erase command? If one wants to >> erase 80k chunk starting from offset 0 and only 32k and 64k erase type >> are supported, can we erase 96k? > No. But can you maybe build a list of erase commands to be executed once > you validate that the erase can be performed for example ? My second choice was an array witch saves u8 opcode and u32 erasesize. There are flashes of 256MB, in the worst case scenario with 4k erase type, we will end up with 64K entries. How about enforcing the length to be multiple of mtd->erasesize, like we do in uniform_erase? With this, the problem disappears. Thanks, ta