Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1103072imm; Wed, 23 May 2018 10:18:12 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpJPtln5+a7kiTZ6ww92yfQWA96eoIV/y3EF/tFhtXegiQoMZP2hAIN82dc4zVYJ0akHS8Y X-Received: by 2002:a63:6e05:: with SMTP id j5-v6mr3031723pgc.150.1527095892297; Wed, 23 May 2018 10:18:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527095892; cv=none; d=google.com; s=arc-20160816; b=GR1TfkbD+QaEaF8XHrijuRauyRXLxxSAxit44UPvFtCdoKG0TlSD/RJP7XSmWwaYip mzRRfVAVHiEKBcXfCmb5rMxhSrJ7y8IeCnIJvQeeV5vfEX9Gnlw23cAtJkWl8QnrRH3D HCjirL1WUDcVoTmh93CV7UwyG7UOWX+tMqhyok4YkUzUP4+TuuDVZzHRuWJNiA8w2TvV OT7Lyni75558mtFqIWDOY5XqzShsV8BUJyloPKRVA5ZX+y9sSkfWmNbiQJ+NS6oH4JdB Qp/ssuvv+dRZJqPXGB5P47638kvIc5S2zFZeMytvvLBNWwFxNNB1mwjhrsAmYmGaebCI I0sQ== 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:dkim-signature :arc-authentication-results; bh=NpN5tDRaglGONcHp+1PnQJ5B9ZsvxqyIljCgEckeVtU=; b=qcqxtCi2HSqn7ENTETVg2n2EWAnd3en/REbJCpADE4mX3ByTpi7JsNm1H/C+og0wDm +dZGTjTsxM8OZI/OnSAbhrSUuJuBrprgIfllVgKobR8OQfBAgmZbL+nRLa0a7lHSB7Y6 UEBhA5Y9K0KOsXO5fmndlTSyGxT7SLAfZxsRbhtJxgf7qNFsqZAHTqZNl4wUfAZ83QrP UaeHd6e4BnZueiXqDkGoYfGqyfhwbavNyLk5mBCZ45kEgL5t7tHkxX302BEa6Z/qtL85 00Noonxlh9IGjrxB2PznnFmghTzL26gLGzVE2uxKoja+MUK6qwsTUQmIsWlM47a96Pz7 0YtQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=n7hWbp34; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1-v6si14957132pge.307.2018.05.23.10.17.57; Wed, 23 May 2018 10:18:12 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=n7hWbp34; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933855AbeEWRRl (ORCPT + 99 others); Wed, 23 May 2018 13:17:41 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:44900 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933767AbeEWRRk (ORCPT ); Wed, 23 May 2018 13:17:40 -0400 Received: by mail-wr0-f194.google.com with SMTP id y15-v6so27852057wrg.11 for ; Wed, 23 May 2018 10:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NpN5tDRaglGONcHp+1PnQJ5B9ZsvxqyIljCgEckeVtU=; b=n7hWbp34omZmFZSQhfUp9dA+ixtsI1K9GGRm7wUTwpmhJcSVXx9OSsGGsYclm/KL4u rL+PU68GS+IgaFyxANsZWHPg9ynI46t6GpdPsQajrRzodXaZR/JWfvxuNFqrmrRG2liH 1QUlsCrmVTEFvbU+T+u6pWLyQpsxUDiJGY53C8tNkNvylhwEj3nUQWKt7vfab5tbDgG0 NdotcrXMkbasEmXFe6C1lDomauQoM4gVEYoZ7DaF67saN7eCi5hIXp2lG9QBIqegoMMH MGr38z0ZLRVJYs+50RT9+G3Rgcuwa9SGQcwMzZ7+EugGSHv6JFeyiWi0kIfe61aqyN+V y2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NpN5tDRaglGONcHp+1PnQJ5B9ZsvxqyIljCgEckeVtU=; b=KrC2+aBFo1b9XqsuWsvOtUQ5DV2H+nNKeLnNH2I/JuCEHRxusgjQAa5k1oROcc8ptp w1AQLj4us1yLOJenCKPkESAicmjx8apczah/g3Vfcqm2k5OBAdTtPVZX/GvdAXfyn1Cv Z0PUtPD4/+slkFksAQQdDJbuXHUKRnL70Zt7SKFd9GwlfYJlRkj+yzffBts1qrCUto9V KyHZ4NdhNEMiPcq/nwmC7NLvfaZlHpC6LC6dHLJW8iCdW+JdHW9xbsQPGtixTWA6za2O XWOAwnnbv4c0gYdJqG6C/6rNFnzoxPJggRDa0OYf08XJt7BQuBaSjOSf6U1lLTbzapH6 4vNg== X-Gm-Message-State: ALKqPwf7fCo7oATR0+5cH6Mn+DGo+Km6EFofyNbO4hp4RRQqOcrw1eIy b3bNtx5boK/lxN1YLTp+P58= X-Received: by 2002:adf:860d:: with SMTP id 13-v6mr3465699wrv.12.1527095859296; Wed, 23 May 2018 10:17:39 -0700 (PDT) Received: from [192.168.1.4] (ip-86-49-107-50.net.upcbroadband.cz. [86.49.107.50]) by smtp.gmail.com with ESMTPSA id o138-v6sm3235488wmg.10.2018.05.23.10.17.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 10:17:38 -0700 (PDT) Subject: Re: [RFC PATCH] mtd: spi-nor: add support to non-uniform SPI NOR flash memories To: Tudor Ambarus , cyrille.pitchen@microchip.com, dwmw2@infradead.org, computersforpeace@gmail.com, boris.brezillon@bootlin.com, richard@nod.at Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, nicolas.ferre@microchip.com, Cristian.Birsan@microchip.com 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> <66b2b859-72db-33cc-75ae-2493a4aad235@microchip.com> From: Marek Vasut Message-ID: Date: Wed, 23 May 2018 14:54:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <66b2b859-72db-33cc-75ae-2493a4aad235@microchip.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/23/2018 02:52 PM, Tudor Ambarus wrote: > Hi, Marek, Hi, > 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. Some RLE encoding might help here ? > How about enforcing the length to be multiple of mtd->erasesize, like we > do in uniform_erase? With this, the problem disappears. What is the erase size for the 4k-sector 256MiB flash ? -- Best regards, Marek Vasut