Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp650369imm; Fri, 5 Oct 2018 09:29:57 -0700 (PDT) X-Google-Smtp-Source: ACcGV62yhtHuXhhThCNfojzhFvlOMucrAeONba9bIKFR2l9ip91my+TkfyAe6ARoAAJvCDT3+6e1 X-Received: by 2002:a63:f744:: with SMTP id f4-v6mr11001348pgk.410.1538756997918; Fri, 05 Oct 2018 09:29:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538756997; cv=none; d=google.com; s=arc-20160816; b=UyhtZWl7XUO6qdRKRHmaB3bECxRd9nDRbA4OlMCOgrJV0msSSpVOtE1Td5DjHCCH3Y 7Xxg/Ds0RuQ099ZfcDavPeFBq091w1dXJK/3A7z+ISwM2QZavrwSdkgpUJBG5PW7+UL5 oZOlmVd1cnebE35t7BT+hsr0fVp0H+M6ZC9Fc9PxfFNwmg0wvUHNZRVFo6tbfohBYei1 xGcXRN3sc1Qcl+vmHy6LaRzEPIFGTNrxtlg+xwOSqZxJlY+op2Hk1BMQoCbectCBbNTw /IyckEqTEUtG914HMpnzSJ9mPUnwJob45C+hFm1/FRPPAYQShHN/S4DScePh5on7n18P eogQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=X+DsMSWJaz7oLaCwMhl9S2AIcR+fuqgSJUhZwcwbdVA=; b=ggTG0G6YsdiBl+FYFJzW1s36AL83hLYm3pAiN/Fi8yyIYCNAkni9beYu9XcuxXRHcc FYw3ZpSzxp/jzHHFzVvqye/f012bTkRDVzU+gnwedixk/u8geDk+zC4ZugSlJpJdediM V0fPA8HyckUBrfGwH1jXg0boUrKndT5ccitRiVSQEZAhNeIRmTPoTfpWJ4SCJ3PNweBl KBEv9JSRLgxdt+ODg3edbHmvkO3TuTsVs2ggQ0/lyTWMcGgu6cWQz3HWa6v46vWLHxSw 9VPNjrTTjv50v8LSPqqcEQcycBxOH5anUpUg8S/S7NZZ0+zObQDzVhsi42hFJw6DYLqT yuYA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 185-v6si9249187pff.270.2018.10.05.09.29.43; Fri, 05 Oct 2018 09:29:57 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728607AbeJEX3B (ORCPT + 99 others); Fri, 5 Oct 2018 19:29:01 -0400 Received: from mail.bootlin.com ([62.4.15.54]:52641 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727941AbeJEX3B (ORCPT ); Fri, 5 Oct 2018 19:29:01 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 3477520802; Fri, 5 Oct 2018 18:29:32 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (unknown [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id BC84F207CC; Fri, 5 Oct 2018 18:29:31 +0200 (CEST) Date: Fri, 5 Oct 2018 18:29:31 +0200 From: Boris Brezillon To: Ricardo Ribalda Delgado Cc: David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Zhouyang Jia , linux-mtd@lists.infradead.org, LKML Subject: Re: [PATCH v10 10/10] mtd: maps: gpio-addr-flash: Add support for device-tree devices Message-ID: <20181005182931.172b8f1c@bbrezillon> In-Reply-To: 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> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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.