Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751286AbdIKI6k (ORCPT ); Mon, 11 Sep 2017 04:58:40 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:37825 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751035AbdIKI6i (ORCPT ); Mon, 11 Sep 2017 04:58:38 -0400 X-Google-Smtp-Source: ADKCNb44F5MFC6S6b965n+inIG7jUGn3VIsY4qtcVYTYPyN55gOSK1kmSw430rObIENZwpm62vi/j+ryTdwXVHQ4LPQ= MIME-Version: 1.0 In-Reply-To: References: <20170907185456.4631-1-cyrille.pitchen@wedev4u.fr> From: Geert Uytterhoeven Date: Mon, 11 Sep 2017 10:58:36 +0200 X-Google-Sender-Auth: KHIa4PpiAp-l9ePrfY56-S2thdI Message-ID: Subject: Re: [DEBUG] mtd: spi-nor: dump DWORDs of the Basic Flash Parameter Table To: Cyrille Pitchen Cc: Marek Vasut , MTD Maling List , Brian Norris , David Woodhouse , Boris BREZILLON , Richard Weinberger , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1931 Lines: 53 Hi Cyrille, On Thu, Sep 7, 2017 at 9:28 PM, Cyrille Pitchen wrote: >> Can you apply this patch on your tree then report me what was printed, please? >> I have an idea of the root cause of your issue then a potential work-around >> but I first need to validate my assumption to confirm that the work-around >> would actually work. +m25p80 spi0.0: DWORD1 = 0xffffffff +m25p80 spi0.0: DWORD2 = 0xffffffff +m25p80 spi0.0: DWORD3 = 0xffffffff +m25p80 spi0.0: DWORD4 = 0xffffffff +m25p80 spi0.0: DWORD5 = 0xffffffff +m25p80 spi0.0: DWORD6 = 0xffffffff +m25p80 spi0.0: DWORD7 = 0xffffffff +m25p80 spi0.0: DWORD8 = 0xffffffff +m25p80 spi0.0: DWORD9 = 0xffffffff +m25p80 spi0.0: DWORD10 = 0x00000000 +m25p80 spi0.0: DWORD11 = 0x00000000 +m25p80 spi0.0: DWORD12 = 0x00000000 +m25p80 spi0.0: DWORD13 = 0x00000000 +m25p80 spi0.0: DWORD14 = 0x00000000 +m25p80 spi0.0: DWORD15 = 0x00000000 +m25p80 spi0.0: DWORD16 = 0x00000000 +m25p80 spi0.0: BFPT version 1.0 (length = 9) > If you could also dump the value of the 'addr' argument of > spi_nor_read_sfdp_dma_unsafe() just before the for () loop below in the > very same function. Actually, I suspect the SFDP tables of your SPI NOR +m25p80 spi0.0: addr = 0x448 > memory sample to have been programmed with invalid values, neither > compliant with the JEDEC JESD216 specification nor with the Cypress > datasheet for this memory part. Sounds plausible. I get the same values when disabling DMA, so it's not due to bad DMA handling. All Renesas boards I have local or remote access to have spansion,s25fl512s. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds