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 D3EABC433E9 for ; Sat, 6 Feb 2021 20:48:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A054964E5D for ; Sat, 6 Feb 2021 20:48:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229621AbhBFUs2 (ORCPT ); Sat, 6 Feb 2021 15:48:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229625AbhBFUsZ (ORCPT ); Sat, 6 Feb 2021 15:48:25 -0500 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81078C061788 for ; Sat, 6 Feb 2021 12:47:45 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id w204so10545103ybg.2 for ; Sat, 06 Feb 2021 12:47:45 -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=+hjAXsPVbgElgRdj+BZ+6MVnNMTVzcYGHrvtwU1AcCs=; b=PivZDf7vbfBH6bSgHRaWMYMP8xN20P+lGSInQZfjmRrebl4zG19XOD81h4xHPsxfvN rrEa3VG5KM++VddLx0G0hTtcKmO3HR5nuYYQszPGx7j17MOYIXpprrMbnqMjHCQ16gnh vAAp8M7sh5ngMRXLEvCnpR0SE2eLb/b831luTAfpCMUIl/+mJcASqjF/vSQElaBpCa5G ILxRh/y64IoVeO+zKE/zafs6iW5iGJpNWNeiVO4o5xdYwVvhVcqNHRaL4XC6XStW1r/E jU8CFfUhqfItkbmKMgW8wP9A8yilwS0e3PFFDVjJn3PIqvllgunktYiSTLq9+arpDImJ yCYw== 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=+hjAXsPVbgElgRdj+BZ+6MVnNMTVzcYGHrvtwU1AcCs=; b=OJ9pnljLy6zb7jQWeEi7/zHBiRWGEaAgDmHi/ewLLsuib5FWPXZGxlxVelcQjdFpxt 3/BUAfQ2vk48gFZDT5OoN7NcZNXBxMHAyEQcMPbRH3jHcxpOjzjO5o2ugdHjs5v4/PCM 8a9MULL9BpBNG+l2KJLLvkpMGuYYfD5cEQLUcDUcHsEZMK0MHusjSwnYgTQlPHKsADBK kPKK9W+Jcu5LOfGWV1CjQtHpBv4pDn4CRbBxoq/fZqJazlj2tFz+VX31FH+JlInihloY 1ethDggnVx8GIpLNCkvmA0fDTHbJ/DVHK0yvVPAghhpTCZsGVnAEmmte0i5ZqfRtsUSC 2+hQ== X-Gm-Message-State: AOAM531L8PDbN9haF+5vWonbPrqiYRGMbYo6I4pvPgg2DUbo/DfWN6Uq MZilF6FotxSiw7FucFI8vsOA7XbzgV8FNIMYkAPQZw== X-Google-Smtp-Source: ABdhPJyL0NcBX/RigrI99Osm8m1ZvOqxCkoIvfHxGEI93KNtJj0ymk4vExKY8KweKVKWPIOdql7mDcRKQHJIMzVuTpU= X-Received: by 2002:a25:b74c:: with SMTP id e12mr16000102ybm.20.1612644464464; Sat, 06 Feb 2021 12:47:44 -0800 (PST) MIME-Version: 1.0 References: <20210205222644.2357303-1-saravanak@google.com> In-Reply-To: From: Saravana Kannan Date: Sat, 6 Feb 2021 12:47:08 -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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Sat, Feb 6, 2021 at 11:41 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Fri, Feb 5, 2021 at 11:26 PM Saravana Kannan wrote: > > There are a lot of devices/drivers where they never have a struct device > > created for them or the driver initializes the hardware without ever > > binding to the struct device. > > > > This series is intended to avoid any boot regressions due to such > > devices/drivers when fw_devlink=on and also address the handling of > > optional suppliers. > > Thanks for your series! > > > Patch 5 sets up a generic API to handle drivers that never bind with > > their devices. > > > > Patch 6 through 8 update different frameworks to use the new API. > > > driver core: fw_devlink: Handle suppliers that don't use driver core > > irqdomain: Mark fwnodes when their irqdomain is added/removed > > PM: domains: Mark fwnodes when their powerdomain is added/removed > > clk: Mark fwnodes when their clock provider is added/removed > > I take it this is an automatic alternative for letting drivers set the > OF_POPULATED flag manually? The frameworks can still continue setting it to avoid creating dead "struct devices" that'll never be used. This new flag handles cases where the device is already created, but will never bind to a driver. So, they are meant to do slightly different things, but the end result is removing the need for individual drivers to set OF_POPULATED (and Rob hates that too). > Is this actually safe? It's not uncommon for a driver to register > multiple providers, sometimes even of different types (clock, genpd, > irq, reset[1], ...). This flag is just an indication that the fwnode has been initialized by a driver. It's okay if the flag gets set multiple times when a driver is registering with multiple frameworks. It's also okay if the flag is cleared multiple times as the driver is uninitializing the hardware (although, this is very unlikely for drivers that don't use device-driver model). When we actually try to create device links, we just check if this happened without a driver actually binding to this device. There's no "probing" race because the "status" I check goes through NO_DRIVER -> PROBING -(registering happens)-> BOUND -> UNBINDING -(deregistering happens) -> NO_DRIVER. So if the fwnode flag is getting set as part of the driver's probe function, the "status" value will never be NO_DRIVER. > Can you be sure consumer drivers do not start probing while their > dependency is still busy registering providers? The code only acts on that flag when trying to create device links from the consumer to the supplier. This is just a way to tell "hey, don't bother creating a device link, this supplier will never bind". So it just avoids blocking the consumer. Doesn't really make the consumers probe earlier than they would have. > [1] Which brings my attention to the fact that devlink does not consider > "resets" properties yet. > Yeah, we can add that and other bindings as we go. -Saravana