From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753492AbcLGSZr (ORCPT ); Wed, 7 Dec 2016 13:25:47 -0500 Received: from mail-db5eur01on0135.outbound.protection.outlook.com ([104.47.2.135]:31605 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752729AbcLGSZq (ORCPT ); Wed, 7 Dec 2016 13:25:46 -0500 From: "Krzeminski, Marcin (Nokia - PL/Wroclaw)" To: Cyrille Pitchen , Marek Vasut , Cyrille Pitchen CC: "boris.brezillon@free-electrons.com" , "computersforpeace@gmail.com" , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "richard@nod.at" Subject: RE: [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write() Thread-Topic: [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write() Thread-Index: AQHST+SeJpqUrNK3/kubyc+piXCOiqD7RiuAgABNzACAADo5gIAAMbawgAB2IwCAAAn5gA== Date: Wed, 7 Dec 2016 13:50:11 +0000 Message-ID: References: <0078578d0f5d2402ac623afabf601d25998f84a9.1481044434.git.cyrille.pitchen@atmel.com> <096f8b4c-b00a-af89-e667-7385226c2e7e@gmail.com> <0b871c04-c105-ec94-441c-481e9773f19e@wedev4u.fr> <7dd7fecc-7f03-659a-ef00-a1ad69daceca@gmail.com> <530a690a-d0df-3e10-2c4d-f363d94f356a@atmel.com> In-Reply-To: <530a690a-d0df-3e10-2c4d-f363d94f356a@atmel.com> Accept-Language: pl-PL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcin.krzeminski@nokia.com; x-originating-ip: [131.228.2.29] x-ms-office365-filtering-correlation-id: 628096e3-d955-4878-2432-08d41ea7f70f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR0701MB2129; x-microsoft-exchange-diagnostics: 1;AM4PR0701MB2129;7:IhVctTLKvVc6GuHRbXzSfyUM8Hor8+0qBIlw9nvv+ikX9JXaGP+VCawYmjOWZGlO4GSMLwvIuIFQ4XgO8VIRYKRKxTgQLELf8gDGAc8FHf36A+kJ3+H6uNVCU0qIdNwjyuCqCSvy/PmO7GXLZmQrpSc+wLW7G3t2/y8COqBr8nqCbbL98vyDGmSpEPykijaCUKAuqLV4LrXswapH/8kuiRYfPPgLpWkHOw0f2qWW/OdRQ6G8T3mwWnJ4S+EFzNBbdVPySsFWjQwf1pp+ICF9aBwNbOrNLLp/kdigqc7CSeS8aRpqjOjjGyv3Oz2lcw0sBqepS9UeB69JTpc/qoqn+qTvl7UwT4WA2+HVWUk2Vx1B4RgK1j5icU6Io+4clKb3lTkHInPIzgQGjmC2SutP/XUP49UxJC3+uC/0s3iuLgHiqc73nMa7uJRq94y7nmTVvhI4Z40G6XNzaYkWsdIUmA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(82608151540597)(258649278758335)(58145275503218); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148);SRVR:AM4PR0701MB2129;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0701MB2129; x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(13464003)(24454002)(68736007)(9686002)(76576001)(3280700002)(2906002)(15650500001)(2420400007)(93886004)(3660700001)(39410400001)(54356999)(229853002)(39860400001)(6506006)(39850400001)(50986999)(39840400001)(7110500001)(106116001)(106356001)(189998001)(77096006)(105586002)(5890100001)(5001770100001)(97736004)(39060400001)(39450400002)(38730400001)(1720100001)(2950100002)(7846002)(7736002)(5660300001)(2900100001)(8936002)(76176999)(8676002)(101416001)(81156014)(81166006)(7696004)(86362001)(122556002)(10710500007)(74316002)(92566002)(66066001)(305945005)(3846002)(102836003)(4326007)(33656002)(6116002);DIR:OUT;SFP:1102;SCL:1;SRVR:AM4PR0701MB2129;H:AM4PR0701MB2130.eurprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2016 13:50:11.7977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2129 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uB7IPrk2023077 > -----Original Message----- > From: Cyrille Pitchen [mailto:cyrille.pitchen@atmel.com] > Sent: Wednesday, December 07, 2016 2:08 PM > To: Krzeminski, Marcin (Nokia - PL/Wroclaw) > ; Marek Vasut ; > Cyrille Pitchen > Cc: boris.brezillon@free-electrons.com; computersforpeace@gmail.com; > linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; > richard@nod.at > Subject: Re: [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in > spi_nor_write() > > Le 07/12/2016 à 07:21, Krzeminski, Marcin (Nokia - PL/Wroclaw) a écrit : > > Hi Cyrille, > > > >> -----Original Message----- > >> From: linux-mtd [mailto:linux-mtd-bounces@lists.infradead.org] On > >> Behalf Of Marek Vasut > >> Sent: Wednesday, December 07, 2016 4:07 AM > >> To: Cyrille Pitchen ; Cyrille Pitchen > >> > >> Cc: boris.brezillon@free-electrons.com; computersforpeace@gmail.com; > >> linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; > >> richard@nod.at > >> Subject: Re: [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in > >> spi_nor_write() > >> > >> On 12/07/2016 12:38 AM, Cyrille Pitchen wrote: > >>> Le 06/12/2016 à 20:00, Marek Vasut a écrit : > >>>> On 12/06/2016 06:14 PM, Cyrille Pitchen wrote: > >>>>> This patch removes the WARN_ONCE() test in spi_nor_write(). > >>>>> This macro triggers the display of a warning message almost every > >>>>> time we use a UBI file-system because a write operation is > >>>>> performed at offset 64, which is in the middle of the SPI NOR memory > page. > >>>>> This is a valid operation for ubifs. > >>>> > >>>> Is that a valid operation for all spi nors ? > >>>> > >>> > >>> AFAIK, yes, it is. First we need to erase a sector or a block, then > >>> we can send page program commands to write data into the memory. > We > >>> cannot write more than a page size within a single page program > >>> command but you can write less and start in the middle of a page if > >>> you > >> want. > >> > > Technically you can, but for some chips this warning is indeed right, > > and at least force the user to take a look. See this: > > > > > http://www.macronix.com/Lists/ApplicationNote/Attachments/1606/AN030 > 2V > > 1%20-%20MX25L_G%20Serial%20Flash%20Programming%20Guide.pdf > > > > This Macronix document recommends to align both the start offset and the > length to a 16-byte boundary. However the WARN_ONCE() macro only > checks the start offset but doesn't test the length. Also it tests a page-size > alignment, which is a stronger constraint than a 16-byte alignment. > > In the case of Macronix mx25l_g memories, when the UBI layer writes at > offset 64, the warning is a false positive, isn't it? They are also saying about writing full pages at once (chapter 5). > > Also WARN_ONCE() dumps the call stack making people think of a kernel > oops, displayed once per boot when mounting a ubifs partition. > > If the issue exists, printing a warning does not fix it. > If it generate to many noise and confuse users then this patch is really needed. Thanks, Marcin > So what should we do? > > Best regards, > > Cyrille > > > Thanks, > > Marcin > > > >> I wasn't aware this partial and even unaligned programming was > >> available on all chips, OK. > >> > >>> I don't know whether we could cross the page boundary if we start > >>> writing from the middle of a page as long as we write less data than > >>> a single page size. However spi_nor_write() don't do so, this is why > >>> it computes page_remain = min_t(size_t, nor->page_size - > >>> page_offset, len > >>> - i) > >> > >> No, I don't think we can, I believe the PP would wrap around and > >> program the same page from the beginning. > >> > >>> Well, now looking at the Spansion S25FL127S datasheet, the address > >>> is wrapped if we cross the page boundary: > >> > >> Yeah, this matches my mental model. > >> > >>> "Depending on the device configuration, the page size can either be > >>> 256 or 512 bytes. Up to a page can be provided on SI after the > >>> 3-byte address with instruction 02h or 4-byte address with > >>> instruction 12h has been provided. If the 9 least significant > >>> address bits (A8-A0) are not all 0, all transmitted data that goes > >>> beyond the end of the current page are programmed from the start > >>> address of the same page (from the address whose 9 least significant > >>> bits (A8-A0) are all 0) i.e. the address wraps within the page aligned > address boundaries. > >>> This is a result of only requiring the user to enter one single page > >>> address to cover the entire page boundary." > >>> > >>> Then from Adesto AT25DF321A datasheet: > >>> "If the starting memory address denoted by A23-A0 does not fall on > >>> an even 256-byte page boundary (A7-A0 are not all 0), then special > >>> circumstances regarding which memory locations to be programmed will > >>> apply. In this situation, any data that is sent to the device that > >>> goes beyond the end of the page will wrap around back to the > >>> beginning of the same page. For example, if the starting address > >>> denoted by > >>> A23-A0 is 0000FEh, and three bytes of data are sent to the device, > >>> then the first two bytes of data will be programmed at addresses > >>> 0000FEh and 0000FFh while the last byte of data will be programmed > >>> at address 000000h. The remaining bytes in the page (addresses > >>> 000001h through 0000FDh) will not be programmed and will remain in > >>> the erased state (FFh). In addition, if more than 256-bytes of data > >>> are sent to the device, then only the last 256-bytes sent will be > >>> latched into the > >> internal buffer." > >>> > >>> > >>> Besides, the wear leveling is handled by the ubi layer I guess, at > >>> the spi-nor level we write raw data. Maybe Richard and Boris could > >>> tell us more but talking with them I've understood that's it is > >>> normal for the ubi layer to write at offset 64. > >> > >> I'd understand RMW, but pure write seems a bit odd. > >> > >> > >> -- > >> Best regards, > >> Marek Vasut > >> > >> ______________________________________________________ > >> Linux MTD discussion mailing list > >> http://lists.infradead.org/mailman/listinfo/linux-mtd/ > >