Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp3858154ima; Mon, 4 Feb 2019 06:24:35 -0800 (PST) X-Google-Smtp-Source: AHgI3IayVpPNs1sgzfmSiYosH9M/Rq9QLaozGGBwYxtndn+dFZuQj6IMBChYQ8PTDZdLBJMQdJU5 X-Received: by 2002:a63:2109:: with SMTP id h9mr13082890pgh.277.1549290275673; Mon, 04 Feb 2019 06:24:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549290275; cv=none; d=google.com; s=arc-20160816; b=JJKfBU6w1swZ5HyreEQ35WwT9yiKgCnjnelNHCTKbtRcMi78Ac50hg9FUIp8GcslIP Zy4YpGNdAd7e9slnoXBr6FPFowCk5/d05QjZbTF60Iz+QX4m9yudMpfcqvkaxX4W6vkz HF/5iiimIzyLCpPzLp0C2Ecv+QteK7wyF9BKrdxOMeyoQl+SCNxUNzs7/gfC+s1saGHZ 3e+a0bOpnBvIYkja2fHlunnsyEOVoZdzk9Oi0CfD4NBEwBbNs/g/oG7J7dojlViKXl+0 3OlZiyyiJVDmkmpnumtKinttJdNDkymz4eGazHHeZoUah/RUb3o9VdHUNTnt2xSC6eTg AzHg== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=wB9H8jqgyz2EUqzphuqcub7WdveCpX3EBCAZf+vLVx4=; b=jgN0KpEIMD1AWbzFx5K+ieO5Wso3ROMqOSyN7rK+2qTXoz3Nia49/c/NNyISZ3yCH9 p+8sMK09eX1mptNJKucP+r/YbKP3qkhzwgguxSTCON+kZxeY2TsMtHPWNHmCtjUWvHk5 mWJNbwlmEulWhYZWOcJl8jlEMsWu/DiUIfdb/Bky9oqp9IFV8uz/O+OwBPPZI66yjXAv LOX+Dij5Au60Yql4IuoqwuvfUpQrzyKgS8Np98FNIo/AcHNsChyKSrHRztgMT0xgpzhQ N3+RNfppRqci72wf74tgdcmbyjtG8l7zEJn8nA7HEdwuL/8tqvpp6d4CSBUglY7IeNcv eZgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GRsDgUA8; 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 v25si164514pfj.139.2019.02.04.06.24.19; Mon, 04 Feb 2019 06:24:35 -0800 (PST) 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=GRsDgUA8; 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 S1730539AbfBDMdE (ORCPT + 99 others); Mon, 4 Feb 2019 07:33:04 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:37476 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730138AbfBDMdD (ORCPT ); Mon, 4 Feb 2019 07:33:03 -0500 Received: by mail-pf1-f196.google.com with SMTP id y126so6701243pfb.4 for ; Mon, 04 Feb 2019 04:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wB9H8jqgyz2EUqzphuqcub7WdveCpX3EBCAZf+vLVx4=; b=GRsDgUA85radMr1fM2vbdJcXWXvtABynpRRs/x6Oeuap4jre1TrUXoWEAg/ZxGcQdE 9gM4+IO2UzQYIP0TBy9gOG0d+E5DHvU+5UX4AObEK2YpaZ9r3UuedO8lWSLc9uTNOLCZ OzfuIEmylIfE/dVnKRUOTehkTw5WylYnk0sBgD7SnG6W9fI8BvkaND3VGOCafAiFRxHx rudWzpUGTvt227tBJC6XxoVlkFvGPtYDJ4EKxApLvRI1XTo0M4IWn/DRqHkn792SwK/U S9TCbLOddmbFLXhn7ic0hzSrdylwB401xKHRYyCnTzBt+pLajVRBhiPcbCzfyHTJshGD PV0g== 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:content-transfer-encoding; bh=wB9H8jqgyz2EUqzphuqcub7WdveCpX3EBCAZf+vLVx4=; b=o+DDZr+scA98oGH0202Rl2ykXLmOsIrj8whkjAPQiVkS1W10yYwPpSmzc1xiWToEtl cMoxjNI3b9e7MzYEZEeXpURUlVMuWotoIdEhtHoKizk/XL0VHO0UIzKwbWa0+HPHUSCr 9yBraL0+PeDPr4LHhV1AMudc4sX6RxaZZzOcPUk9vWjMTJpn6J5PAEI+YLDWo2K/yius siobnsQnReDafALRuM7wfLeCImp/ry8voSEZj9qVg+c3vVzjGecqxhF2OEqlyhAgZG5U NPJz8HRKUq+fzWvRdJLerpb+Jt6tc3S4Z8dksK4b2M51tt0LI0T0T1lxTLboevUoZdge wo3A== X-Gm-Message-State: AHQUAubuqCKhjo6pMs9/HPQ4hNLsad18cqiNlb43ye0/r7zm6XpUTLfo ac2oIabk3MvUnTyY1oQ6Ya+9OKBrdMLxuIjmFsk= X-Received: by 2002:a63:ac1a:: with SMTP id v26mr12925120pge.293.1549283582574; Mon, 04 Feb 2019 04:33:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Emil Lenngren Date: Mon, 4 Feb 2019 13:32:50 +0100 Message-ID: Subject: Re: [PATCH 2/2] mtd: spinand: micron: Support for all Micron SPI NAND flashes To: "Shivamurthy Shastri (sshivamurthy)" Cc: Boris Brezillon , Miquel Raynal , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Chuanhong Guo , Richard Weinberger , Schrempf Frieder , Marek Vasut , Frieder Schrempf , Brian Norris , David Woodhouse , "Bean Huo (beanhuo)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Den m=C3=A5n 4 feb. 2019 kl 12:18 skrev Shivamurthy Shastri (sshivamurthy) : > > Driver is redesigned using parameter page to support all the Micron > SPI NAND flashes. > > Parameter page of Micron flashes is similar to ONFI parameter table and > functionality is same, so copied some of the common functions like crc16 > and bit_wise_majority from nand_onfi.c. > > This driver is tested using MT29F2G01ABXGD, MT29F4G01ABXFD, MT29F8G01ADXF= D, > MT29F1G01ABXFD. > > -static const struct spinand_info micron_spinand_table[] =3D { > - SPINAND_INFO("MT29F2G01ABAGD", 0x24, > - NAND_MEMORG(1, 2048, 128, 64, 2048, 2, 1, 1), > + deviceinfo.memorg.eraseblocks_per_lun =3D > + params->blocks_per_lun * params->lun_count; > + deviceinfo.memorg.planes_per_lun =3D params->lun_count; > + deviceinfo.memorg.luns_per_target =3D 1; > + deviceinfo.memorg.ntargets =3D 1; > + __le32 blocks_per_lun; > + u8 lun_count; > + u8 addr_cycles; > + u8 bits_per_cell; > + __le16 bb_per_lun; I have a question about the lun_count. As it is now, the planes_per_lun parameter is initialized to 2 in NAND_MEMORG. In your patch, it is instead initialized from the "lun_count" property from the parameter table. But I looked at a datasheet I found by a simple Google search (https://www.google.se/search?q=3Dmicron+nand+spi+datasheet), the first hit is to the 1 Gb flash MT29F1G01AAADD. That device clearly has two planes per lun (you need the "plane select" bit in the requests), but still, according to the parameter page data structure, byte 100, Number of logical units is set to 01h. Also, the "blocks per lun" count, which is called "blocks per unit" is 1024, which should be 512 if this parameter really meant "blocks per plane" and the calculation in the patch was correct. As a reference, the 2 Gb version of the Macronix flash (http://www.macronix.com/Lists/Datasheet/Attachments/6866/MX35LF2GE4AB,%203= V,%202Gb,%20v1.5.pdf), also has two planes per lun. It also sets byte 100, Number of logical units to 01h. So what I'm wondering is of course if this parameter is the correct one to use for planes_per_lun. I tried to locate the correct "planes per lun" parameter in the table, but didn't find anyone. Maybe it's the unfortunate fact that "planes per lun" isn't exposed in the parameter table? /Emil