Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp3286576pxx; Mon, 2 Nov 2020 05:11:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwiIfTV9SjhDCkDwYPIiAG7cOS9b+bQyr6WXtVkW4j049KzaSqRXCV9VbpKTyHKn2zOCILj X-Received: by 2002:aa7:dd49:: with SMTP id o9mr16046314edw.143.1604322706528; Mon, 02 Nov 2020 05:11:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604322706; cv=none; d=google.com; s=arc-20160816; b=ga5aUlk8ZNlsqePdJdJELTWykklVNF/+GZot14CoFzQxPu+p73cU3K+z50VAzNJR9z t57yuKdSfXhGw7MsVbLTdJUA03Ih5Cy4Besc6Ace1cnCsmhUuQiIRnlFKpqy57M1RjX6 jENzHFGVTqtxxrZBwQqEJ8lYl5Tg3DQ9vbaL/OkuzLCpz/SxhkHkTXWj0yF9AQo0DoSc 5AIPayIS7HvYA+CLwBdMxAh/AvKOykborjWHTS/SAsBEjL1mLm4rlaUWenJ9FwuM3R/l M55F9fwrKb92aoevX9v1pnn0gRgA/+lhCNkE902nM9sLO0wVs9uBKjZPE/oW47dBPoBd EZog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=VL5UgoPpdGMKIUSeBzB2NSn/BwzXom0vxwKdmNfnRpk=; b=jwacKnQiiPIfrejvOjk39Uk9D8+zdw7EVRd6B4svX+Y5L9W5ILjoukekXuB/atsbvq dsJP7s/uHdp28p6EqSq3eZs1kwSQn5IU4sGVhZBSmbMH9SUwCZgPQTe1Zu2M/L344f26 AtBkxxR9avu5O3ikvfU0edNl/gVogenFpB089VUElRWkLo4dOVWzjBo800HfEyuBJXzJ XokAlN92xpopnJhxGia8I+MIBiT26EdSYgu5IsJlTF1LwrxBz9lCT3uUynLEHJMpjfCN IQS8tYvOHsA3mS/QaOVGGLHmgjD7+ShkSMqBGF61dJUMXD83ei7l7wFf7BFs4wXSQTaf sZ4w== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m13si8676865edi.66.2020.11.02.05.11.23; Mon, 02 Nov 2020 05:11:46 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728905AbgKBNHb convert rfc822-to-8bit (ORCPT + 99 others); Mon, 2 Nov 2020 08:07:31 -0500 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:50019 "EHLO relay9-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728359AbgKBNHb (ORCPT ); Mon, 2 Nov 2020 08:07:31 -0500 X-Originating-IP: 91.224.148.103 Received: from xps13 (unknown [91.224.148.103]) (Authenticated sender: miquel.raynal@bootlin.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id D7E9CFF803; Mon, 2 Nov 2020 13:07:26 +0000 (UTC) Date: Mon, 2 Nov 2020 14:07:25 +0100 From: Miquel Raynal To: Johan Jonker Cc: Yifeng , richard@nod.at, vigneshr@ti.com, robh+dt@kernel.org, devicetree@vger.kernel.org, heiko@sntech.de, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v13 2/8] mtd: rawnand: rockchip: NFC drivers for RK3308, RK2928 and others Message-ID: <20201102140725.66e7dcb1@xps13> In-Reply-To: <0b417fc2-3503-9bf6-914d-0f8b38df1914@gmail.com> References: <20201028095326.15562-1-yifeng.zhao@rock-chips.com> <20201028095326.15562-3-yifeng.zhao@rock-chips.com> <0b417fc2-3503-9bf6-914d-0f8b38df1914@gmail.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Johan, Yifeng Johan Jonker wrote on Mon, 2 Nov 2020 13:57:56 +0100: > Hi Yifeng, > > Don't poke with "ecc->bytes" ones it is set in rk_nfc_ecc_init(). It > will not be noted by the MTD frame work or userspace. I think there's > currently no way to let the user know that a different ECC must be used. > Neither can the user set ECC on the fly. > > Example R/W flow: > > nand_select_target() > chip->ecc.write_page_raw() > chip->ecc.write_page() > > [..] > > chip->ecc.read_page_raw() > chip->ecc.read_page() > nand_deselect_target() > > A write/read with: > > rk_nfc_read_page_hwecc() > rk_nfc_write_page_hwecc() > > or > > rk_nfc_read_page_raw() > rk_nfc_write_page_raw() > > must end up with the same result. If we can't archive that, then we > shouldn't offer RAW mode to the user for now. If Miquel agrees you > should just get the driver ready now without these 2 functions and round > things up. What about just not supporting the BootROM area if it was marked "reserved" by the BRom in the DT? Raw accessors is really a nice and basic feature that I would like to have in every new driver. Thanks, Miquèl