Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp757652imm; Fri, 5 Oct 2018 11:13:29 -0700 (PDT) X-Google-Smtp-Source: ACcGV63wk9MqGtv+Yi8LLqTsvcwzIr2UV14oc/LTkds+My0DJJfHe9kvhRr1jZcpPtSTYQ1jnHaK X-Received: by 2002:a17:902:6909:: with SMTP id j9-v6mr12531622plk.196.1538763209931; Fri, 05 Oct 2018 11:13:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538763209; cv=none; d=google.com; s=arc-20160816; b=TXdP9rSVQu5dXxzUgzQiC1jawoFr1XLr4QvxPtADuf7xdRNiBTIg72DDT1HbLgYA04 DrpG53cYDljiLf1breVowCxtlU1PqA1G3b44iFn93mtfGFwN3NVjIUPJzKk8fB/LjHix 767jA4cUCe0VPgi1dIUY48EHpbauews89++RfYM83WNZOjt/NmdlOU9N1QyvdshRk756 3UZJvQHDMx8CHIMUzFF/AZXnPjCXVQ1eNcZOoitSBrUpv0L1kSZocehbH5VL9rktTq9Q h7Dj/Z6b2qAlPsM7/y0A3RF5OD/dcr9ALR2ur70SgNFLzG2n4PmDyJ2ZW35tfnmFVM76 +kbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=aFsDYgBglL/1P1wMwgpHMxzXFsKg0WwG6VaGB2Fv/5A=; b=iE0rCHtwLLUgcnd/ClDdffCRwq3JaJBqkdl8zyf1DLfcMOW3TeDmw3Bg8SMSPhkACz 4929CLVF3jAbgn9zMuWgAyFQ/tNfO4M9l08N1B7qEoN1QtJBt8KdsV3OcIMZMCzICyN7 PvrJqA7wrTzMcApCSLE9dJ+EbiZ69qp/yW8XRSFtNbrUpoU28wRElA3qj0kn5IptwE6R GD17I9+Ol5Mr7NrZT/itv9xzILFn0P1Anw3enGvl0CRraRCuHGuTg7tkr2qONActTSBo k0DRI5mqzKi55j21/XzZuGUPXMRImlK5Z4UTC/hkDmisG4DogMAxH2g51ch2Cnu82J4I PrWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Yk9jyO1G; 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 f9-v6si10481342plm.126.2018.10.05.11.13.13; Fri, 05 Oct 2018 11:13:29 -0700 (PDT) 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=Yk9jyO1G; 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 S1728772AbeJFBMz (ORCPT + 99 others); Fri, 5 Oct 2018 21:12:55 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:39721 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727957AbeJFBMy (ORCPT ); Fri, 5 Oct 2018 21:12:54 -0400 Received: by mail-lj1-f195.google.com with SMTP id p1-v6so8546004ljg.6 for ; Fri, 05 Oct 2018 11:13:01 -0700 (PDT) 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; bh=aFsDYgBglL/1P1wMwgpHMxzXFsKg0WwG6VaGB2Fv/5A=; b=Yk9jyO1GxmeGuyd5jQ6z01V3ntVGNpvVy2bWwSF+a3EFZKqDkb0kA+ep7wCnvi/r+u OWP51a+El4W8Ruga7W5LTLw0dH6zQO5nTL0h8E+0CS090OYoYRw7SxsRMsB5m5TgUFgx YI3FJOJYhBR92SG73GQdGo5SMuZTtk6H9nCg0wdT+azkaSmdgI1eGHRA19/nYZE/dVkf smVnSw3SgVFa/tRsbYk0z7GphsYU3FD0AarYZwaeGjuJxd/xVickhTMtIUlXEregTs5X p+RmQBr9mCcdiH3rvSFtc7CQTndb5SlLpgUvJyKa70hTTC2xtKLiK4I/D7sSTyUpxF4n /6SQ== 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; bh=aFsDYgBglL/1P1wMwgpHMxzXFsKg0WwG6VaGB2Fv/5A=; b=MyA+UzZJM5RiWmJNH9GDxVYSHrRYIQRXxFB9jrsRbDnOlnjl2LIFWuDAwTvhXjt+31 MKqO5bb8my41Sd/MNR2+SCd5mf+OOr7Zy2u34KuUZgZJJU2kYFiF2F9eBxfqqdYNbZXt H8qshvEjsYxvbRrnwROhLNqZlzAk34YPla9a5msQMGi+U+UpXM0m2hkQGKIhh2tF9zQZ 9oxk4DfjNVXBGI2gAXjoLi9D79irRKHqMO6f0Y5OKbaqDQ7zJotM2yTlaBAAjGRLxZTn M/9A5MDAuq4NmGgqhiiGH8Ron9yNG4XWlhP5FqQZU4iJJo1PkAcXg2jpnsX8vywIWEp6 AP6A== X-Gm-Message-State: ABuFfohJSYc83yar6J+TwhIgNLCGrnIf3aPU8x9eGRZ6vjCZDt57YjFN AyCnXMtXMiGNwztMs0W7GBs20A9s4fV2MVcAbMM= X-Received: by 2002:a2e:86ca:: with SMTP id n10-v6mr8941593ljj.90.1538763180242; Fri, 05 Oct 2018 11:13:00 -0700 (PDT) MIME-Version: 1.0 References: <20181004142942.11887-1-ricardo.ribalda@gmail.com> <20181004142942.11887-2-ricardo.ribalda@gmail.com> <20181005002125.12fd229f@bbrezillon> <20181005090811.6b7e9957@bbrezillon> <20181005103730.57d52e3c@bbrezillon> <20181005121235.7e64b64a@bbrezillon> <20181005141057.0f1b0a9b@bbrezillon> <20181005165234.468d2397@bbrezillon> <20181005182931.172b8f1c@bbrezillon> In-Reply-To: <20181005182931.172b8f1c@bbrezillon> From: Ricardo Ribalda Delgado Date: Fri, 5 Oct 2018 20:12:43 +0200 Message-ID: Subject: Re: [PATCH v10 10/10] mtd: maps: gpio-addr-flash: Add support for device-tree devices To: Boris Brezillon Cc: David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Zhouyang Jia , linux-mtd@lists.infradead.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Boris On Fri, Oct 5, 2018 at 6:29 PM Boris Brezillon wrote: > > On Fri, 5 Oct 2018 17:40:44 +0200 > Ricardo Ribalda Delgado wrote: > > > Hi Boris > > On Fri, Oct 5, 2018 at 4:52 PM Boris Brezillon > > wrote: > > > > > > On Fri, 5 Oct 2018 16:06:57 +0200 > > > Ricardo Ribalda Delgado wrote: > > > > > > > Hi again Boris > > > > > > > > > > > > On Fri, Oct 5, 2018 at 2:10 PM Boris Brezillon > > > > wrote: > > > > > > > > > > On Fri, 5 Oct 2018 14:04:52 +0200 > > > > > Ricardo Ribalda Delgado wrote: > > > > > > > > > > > Hi Boris > > > > > > On Fri, Oct 5, 2018 at 12:12 PM Boris Brezillon > > > > > > wrote: > > > > > > > > > > > > > > On Fri, 5 Oct 2018 11:54:18 +0200 > > > > > > > Ricardo Ribalda Delgado wrote: > > > > > > > > > > > > > > > Hi Boris > > > > > > > > > > > > > > > > Just seen that you already did the rebase at > > > > > > > > https://github.com/bbrezillon/linux-0day/commits/mtd/physmap-cleanup > > > > > > > > > > > > > > > > Thanks for that. > > > > > > > > > > > > > > > > I am about to test it in real hw (unless you want me wait) > > > > > > > > > > > > > > Sure, go ahead and test it. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Boris > > > > > > I had to change this on your patchset to have it working on hw: > > > > > > https://pastebin.com/78A7yhJ9 > > > > > > > > > > > > If you send the patchset to the mailing list I can review it patch by patch. > > > > > > > > > > > > Also > > > > > > mtd: maps: Prepare merging of physmap and physmap_of > > > > > > > > > > > > I do not think that can be bisected. (Not sure, I have to test it) > > > > > > > > > > Okay, I'll have a look. > > > > > > > > > > > > > > > > > I add the diff to the mail, but gmail will probably scramble the > > > > > > lines(yes I know I have to use other mail client) > > > > > > > > > > The diff looks good, I'll fix that an send a push a new version. > > > > > > > > Also fix on physmap_flash_remove > > > > > > > > physmap_data->exit(dev); must be called BEFORE > > > > map_destroy(info->mtds[i]); > > > > > > Hm, that's weird. That shouldn't happen. Do you have a non-NULL > > > ->exit()? Can you detail why you think ->exit() call is the cause of > > > this OOPS? > > > > > > > No idea. It was crashing at: > > https://github.com/bbrezillon/linux-0day/blob/mtd/physmap-cleanup/drivers/mtd/chips/cfi_cmdset_0002.c#L2839 > > cfi_cmdset_0002.c seesm to play with cfi->chips on its reset callback > > > > I added some printfs: > > > > if (!cfi), > > if (!chip) > > if (!cfi->chips) > > > > sometimes it crashed on one place, sometimes in another :S. Reading > > back our patch it seemed more logical (semantically :P) to > > destroy after exit and not the other way around. > > Actually no, it makes more sense to call ->exit() after destroying the > maps, because the platform-specific ->exit() implem might release > resources that are used during the destroy_map() operation. Another > reason to keep it in this order is that operations in the remove path > should be in the reverse order of those done in the probe path, and > ->init() is definitely called before map_probe(). > I think I know what might be the issue. on cfi_cmdset_002.c cfi_amdstd_reset can be called in parrallel to cfi_amdstd_destroy. maybe we should call unregister_reboot_notifier(&mtd->reboot_notifier); before cfi_amdstd_reset(mtd) need to try that on real hw with some strategical printfs :P. But that will ahve to wait til Monday Cheers > > > > I made that change and it stopped OOPsing at reboot. > > Maybe it's just a side effect, especially since I'm pretty sure your > physmap_data->exit() is NULL (assuming you do use DT to declare your > flash). > > > > > Havent had the time to dig deeper. But if it does not break anything > > on your side to invert destroy and exit please do so. It was not > > oopsing with my patchset. > > I'd like to understand what's happening before doing this change. As I > said, I fear this reordering just hides something else. -- Ricardo Ribalda