From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43BD1C433E0 for ; Fri, 12 Feb 2021 20:59:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 05AD964DEC for ; Fri, 12 Feb 2021 20:59:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231956AbhBLU6o (ORCPT ); Fri, 12 Feb 2021 15:58:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231513AbhBLU6Y (ORCPT ); Fri, 12 Feb 2021 15:58:24 -0500 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94BE6C0617A7 for ; Fri, 12 Feb 2021 12:58:01 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id n195so735644ybg.9 for ; Fri, 12 Feb 2021 12:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CqAzPT6VwnPBuxPka3afIBXbnCQbD8+pdFwxBKcHhXQ=; b=uBTJQG+mWgC2KaNYo1bb3HfZG5kNKJ7vb1CkEXXuyZyIlMIUmRy7u+Ui98xv5m6wXD R7N5LfNkcmh1NQ9NxgRQP3cWOkQFo7SAC+qn3I64HrXBzaGyP8UoGVC/bj+K+cZ8nSWe YQAtaHJyorTUUKIOxX53zOw5ATfxwx2KVYuQOmCF02rn7CG0N1rPqvKrBgWPiLi45FON shvjdCt7F02vXc8OsQJNlQ5Dg8hPGX1Xh3uWdinc2aBX3WWsUPVTakWNa4yKxhzAKQdV EuNXoz2GuhV1z+hCYh7JVx2iqHGoG2X6f6zTTF5209mcejt6xlzEddhC7ShsSohFBkLy xwLQ== 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=CqAzPT6VwnPBuxPka3afIBXbnCQbD8+pdFwxBKcHhXQ=; b=XKAqjezEE6gRDvoicN43nq3ZgQDlyfg0MFOZu8g3CZnVsWB4eyO6nzUhhUofCQjRtY Yl4xCCyhq3Yk+MpIXHvN47h0W4IRqxKfy4TJJGYovC1mj2Ep/nPOrhZQFeoXYho+r4lW ea1sS9OUCinZ5zOIlK5OB2hhSO1mjX7tgGOjee91i/Ifp7uCsaRIx3dmRNe9SPkpzuPH MCy82RC9hxGGLx8/SQecK6TKC8wta+39l8KJNEg/ooJyhpSLconH0a6K5dno4QC8uFRx TXoUHKwpjM5zssY0Tb/vZYakGKCHlLjh5CsW33c2xAZgfAuqc1xd5Xqpeco8ZYPXNsIt Tgvw== X-Gm-Message-State: AOAM531DR5AlAVur1ovU8gi2ka1oY/BqCuitbmAfTHShjIZ4bTuRx0l6 UReFT/t0yQ7fUJKpxpJPuJ8cxXvWHBgJwr2A/88qZw== X-Google-Smtp-Source: ABdhPJwK0fc2ml/1MYUHRvi8x2ga/wmAbYgOqo2Dy3Txjf3hoDchCtA5qthJoSF2yZyW//AH/pAR//MQ+c+2yrZOeqg= X-Received: by 2002:a25:718b:: with SMTP id m133mr6949864ybc.412.1613163480367; Fri, 12 Feb 2021 12:58:00 -0800 (PST) MIME-Version: 1.0 References: <20210205222644.2357303-1-saravanak@google.com> In-Reply-To: From: Saravana Kannan Date: Fri, 12 Feb 2021 12:57:24 -0800 Message-ID: Subject: Re: [PATCH v4 0/8] Make fw_devlink=on more forgiving To: Geert Uytterhoeven Cc: Jonathan Corbet , Greg Kroah-Hartman , "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , Len Brown , Len Brown , Pavel Machek , Michael Turquette , Stephen Boyd , Rob Herring , Frank Rowand , Marc Zyngier , Thomas Gleixner , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Linux PM list , linux-clk , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , ACPI Devel Maling List , Marek Szyprowski , Android Kernel Team , Linux-Renesas Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Feb 12, 2021 at 12:15 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Fri, Feb 12, 2021 at 4:00 AM Saravana Kannan wrote: > > On Thu, Feb 11, 2021 at 5:00 AM Geert Uytterhoeven wrote: > > > 1. R-Car Gen2 (Koelsch), R-Car Gen3 (Salvator-X(S), Ebisu). > > > > > > - Commit 2dfc564bda4a31bc ("soc: renesas: rcar-sysc: Mark device > > > node OF_POPULATED after init") is no longer needed (but already > > > queued for v5.12 anyway) > > > > Rob doesn't like the proliferation of OF_POPULATED and we don't need > > it anymore, so maybe work it out with him? It's a balance between some > > wasted memory (struct device(s)) vs not proliferating OF_POPULATED. > > Rob: should it be reverted? For v5.13? > I guess other similar "fixes" went in in the mean time. > > > > - Some devices are reprobed, despite their drivers returning > > > a real error code, and not -EPROBE_DEFER: > > > > Sorry, it's not obvious from the logs below where "reprobing" is > > happening. Can you give more pointers please? > > My log was indeed not a full log, but just the reprobes happening. > I'll send you a full log by private email. > > > Also, thinking more about this, the only way I could see this happen is: > > 1. Device fails with error that's not -EPROBE_DEFER > > 2. It somehow gets added to a device link (with AUTOPROBE_CONSUMER > > flag) where it's a consumer. > > 3. The supplier probes and the device gets added to the deferred probe > > list again. > > > > But I can't see how this sequence can happen. Device links are created > > only when a device is added. And is the supplier isn't added yet, the > > consumer wouldn't have probed in the first place. > > The full log doesn't show any evidence of the device being added > to a list in between the two probes. > > > Other than "annoying waste of time" is this causing any other problems? > > Probably not. But see below. > > > > - The PCI reprobing leads to a memory leak, for which I've sent a fix > > > "[PATCH] PCI: Fix memory leak in pci_register_io_range()" > > > https://lore.kernel.org/linux-pci/20210202100332.829047-1-geert+renesas@glider.be/ > > > > Wrt PCI reprobing, > > 1. Is this PCI never expected to probe, but it's being reattempted > > despite the NOT EPROBE_DEFER error? Or > > There is no PCIe card present, so the failure is expected. > Later it is reprobed, which of course fails again. > > > 2. The PCI was deferred probe when it should have probed and then when > > it's finally reattemped and it could succeed, we are hitting this mem > > leak issue? > > I think the leak has always been there, but it was just exposed by > this unneeded reprobe. I don't think a reprobe after that specific > error path had ever happened before. > > > I'm basically trying to distinguish between "this stuff should never > > be retried" vs "this/it's suppliers got probe deferred with > > fw_devlink=on vs but didn't get probe deferred with > > fw_devlink=permissive and that's causing issues" > > There should not be a probe deferral, as no -EPROBE_DEFER was > returned. > > > > - I2C on R-Car Gen3 does not seem to use DMA, according to > > > /sys/kernel/debug/dmaengine/summary: > > > > > > -dma4chan0 | e66d8000.i2c:tx > > > -dma4chan1 | e66d8000.i2c:rx > > > -dma5chan0 | e6510000.i2c:tx > > > > I think I need more context on the problem before I can try to fix it. > > I'm also very unfamiliar with that file. With fw_devlink=permissive, > > I2C was using DMA? If so, the next step is to see if the I2C relative > > probe order with DMA is getting changed and if so, why. > > Yes, I plan to dig deeper to see what really happens... Try fw_devlink.strict (you'll need IOMMU enabled too). If that fixes it and you also don't see this issue with fw_devlink=permissive, then it means there's probably some unnecessary probe deferral that we should try to avoid. At least, that's my hunch right now. Thanks, Saravana > > > > - On R-Mobile A1, I get a BUG and a memory leak: > > > > > > BUG: spinlock bad magic on CPU#0, swapper/1 > > > > > Hmm... I looked at this in bits and pieces throughout the day. At > > least spent an hour looking at this. This doesn't make a lot of sense > > to me. I don't even touch anything in this code path AFAICT. Are > > modules/kernel mixed up somehow? I need more info before I can help. > > Does reverting my pm domain change make any difference (assume it > > boots this far without it). > > I plan to dig deeper to see what really happens... > > 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