From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.free-electrons.com ([62.4.15.54]) by bombadil.infradead.org with esmtp (Exim 4.89 #1 (Red Hat Linux)) id 1eYfw9-0006qy-0g for linux-mtd@lists.infradead.org; Mon, 08 Jan 2018 22:30:34 +0000 Date: Mon, 8 Jan 2018 23:30:10 +0100 From: Boris Brezillon To: Miquel RAYNAL Cc: David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Cyrille Pitchen , linux-mtd@lists.infradead.org, Robert Jarzmik , Kyungmin Park , Peter Pan , Frieder Schrempf , Ladislav Michl Subject: Re: [PATCH v4 3/3] mtd: Remove duplicate checks on mtd_oob_ops parameter Message-ID: <20180108233010.5d7e7c3f@bbrezillon> In-Reply-To: <20180108230455.10c0cb83@xps13> References: <20180108211542.11891-1-boris.brezillon@free-electrons.com> <20180108211542.11891-4-boris.brezillon@free-electrons.com> <20180108230455.10c0cb83@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 8 Jan 2018 23:04:55 +0100 Miquel RAYNAL wrote: > Hello Boris, > > On Mon, 8 Jan 2018 22:15:42 +0100 > Boris Brezillon wrote: > > > Some of the check done in custom ->_read/write_oob() implementation > > are already done by the core (in mtd_check_oob_ops()). > > Not sure this is relevant here as your series introduces changes for > the SPI NAND framework, but there are other places where these checks > are, IMHO, also redundant and could be removed. The "past end" string > when grepped in the MTD folder core returns a few more hits. > > In the NAND core: > - nand_do_read_oob() > - nand_read_oob() > - nand_do_write_oob() > - nand_write_oob() That's true for nand_read/write_oob(). The one in nand_do_write_oob() is still needed because mtd_check_oob_ops() allows OOB writes crossing a page boundary. Finally, I don't see any boundary checks in nand_do_read_oob(). > Maybe also in onenand_base.c, but I am less confident for this one: > - onenand_bbt_read_oob() Unfortunately no, this function is directly called from onenand_bbt.c, which means the MTD layer layer is completely bypassed. I also found boundary checks in onenand_mlc_read_ops_nolock(), but again, this function is called from do_otp_read() which is not going through mtd_check_oob_ops(). > > What do you think? I'll remove the extra checks in nand_read/write_oob(). For the other ones, one solution would be to expose mtd_check_oob_ops(), but I'll keep that for later.