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.3 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,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 88630C10F29 for ; Wed, 27 Jan 2021 00:59:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5D5A82068D for ; Wed, 27 Jan 2021 00:59:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404743AbhA0Az0 (ORCPT ); Tue, 26 Jan 2021 19:55:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394533AbhAZSRm (ORCPT ); Tue, 26 Jan 2021 13:17:42 -0500 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61CD5C061756 for ; Tue, 26 Jan 2021 10:17:02 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id x78so17623790ybe.11 for ; Tue, 26 Jan 2021 10:17:02 -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=C63W8Y93BecXXNue/Bt+pWJEqyrzx0Hg2TryKJ8xF3U=; b=sIcUAWDvgO5KukWwqZJd2E/uyHM7Mwiuujj/xRIJmAqOEKjNZ/LDqryjCMHouSf+d2 tf8WOOX6A6ROU0JzpV7ZplsXpA32diogSjKpYjY7aVNBEay/uqM1ZDZaWetg1H7sPo1b v1/iaAIDy5XXh3IToXwNgfm7YTvUsmbXECeLZu19sP7C9tswdUHxrpbQyM8tPfnNMPwt vslKnigoR6jEFlTl1qSzODTjHJ7qoO6763loZuCXJxPfWEWdMGXlUXM/Kqv4SJdyoflc mzCDyfvN6PeMRmWfDRqKT6iqTsWnZDXFNxOICuB+3L7vVMqKA5sDjMCdg5fAM0fk5fn7 0zzQ== 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=C63W8Y93BecXXNue/Bt+pWJEqyrzx0Hg2TryKJ8xF3U=; b=PAExhdWFV2tSfbq1I6r3vB4bDzoeYg/TX8H11ku5Fl3mlvE4ExGpMmAp4WzVNRq977 0KIvijn5e07w+cfL75ekeV7J6F6OIAG/X0f5KHuzVSduC5bptCfVAlm3XamWt6bWmQki HhDwF101yf96LfnKrU2cpr/R2rTEQ5L0TCgsB6lqHVVqaJruaGIxWdJcyN/sxjeBvZL7 JT12wZdo5U4wn7KGRvFviLAQfdRVdNwOJCSh8qpgkj0ebdF6F41HFNY6oY8Xs+icNOBU 1hFSbjN1bf6BOwTOuOzAwd7/qJezgdsmn0QwiGegL6Y70bhGavIdQtyPifZH0cLGNTjj mYdQ== X-Gm-Message-State: AOAM531pNowL8EaG1KEJkrHY8+ZSIkm2Ez07qATQq7DYyD2BjUTyH1O4 AhUMZIRz3CLQtVggAOwB4wCshypJxV41DQ8Q9w35+g== X-Google-Smtp-Source: ABdhPJyKBxbNwKUWs/G+whnZ2vm5Q3D8MJv7kvnkBA1M/xXs+yzBq5YtqbfmfAIzYvaozMNBN7cAp0S7OJeN5pkLzLo= X-Received: by 2002:a25:8b8b:: with SMTP id j11mr9347224ybl.310.1611685021454; Tue, 26 Jan 2021 10:17:01 -0800 (PST) MIME-Version: 1.0 References: <20210122193600.1415639-1-saravanak@google.com> In-Reply-To: From: Saravana Kannan Date: Tue, 26 Jan 2021 10:16:25 -0800 Message-ID: Subject: Re: [PATCH v2] gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default To: Andy Shevchenko Cc: Linus Walleij , Bartosz Golaszewski , Greg Kroah-Hartman , Marc Zyngier , Jisheng Zhang , Kever Yang , "kernel-team@android.com" , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2021 at 1:40 AM Andy Shevchenko wrote: > > > > On Friday, January 22, 2021, Saravana Kannan wrote: >> >> There are multiple instances of GPIO device tree nodes of the form: >> >> foo { >> compatible = "acme,foo"; >> ... >> >> gpio0: gpio0@xxxxxxxx { >> compatible = "acme,bar"; >> ... >> gpio-controller; >> }; >> >> gpio1: gpio1@xxxxxxxx { >> compatible = "acme,bar"; >> ... >> gpio-controller; >> }; >> >> ... >> } >> >> bazz { >> my-gpios = <&gpio0 ...>; >> } >> >> Case 1: The driver for "foo" populates struct device for these gpio* >> nodes and then probes them using a driver that binds with "acme,bar". >> This driver for "acme,bar" then registers the gpio* nodes with gpiolib. >> This lines up with how DT nodes with the "compatible" property are >> typically converted to struct devices and then registered with driver >> core to probe them. This also allows the gpio* devices to hook into all >> the driver core capabilities like runtime PM, probe deferral, >> suspend/resume ordering, device links, etc. >> >> Case 2: The driver for "foo" doesn't populate struct devices for these >> gpio* nodes before registering them with gpiolib. Instead it just loops >> through its child nodes and directly registers the gpio* nodes with >> gpiolib. >> >> Drivers that follow case 2 cause problems with fw_devlink=on. This is >> because fw_devlink will prevent bazz from probing until there's a struct >> device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO >> supplier). Once the struct device is available, fw_devlink will create a >> device link with gpio0 device as the supplier and bazz device as the >> consumer. After this point, since the gpio0 device will never bind to a >> driver, the device link will prevent bazz device from ever probing. >> >> Finding and refactoring all the instances of drivers that follow case 2 >> will cause a lot of code churn and it is not something that can be done >> in one shot. In some instances it might not even be possible to refactor >> them cleanly. Examples of such instances are [1] [2]. >> >> This patch works around this problem and avoids all the code churn by >> simply setting the fwnode of the gpio_device and creating a stub driver >> to bind to the gpio_device. This allows all the consumers to continue >> probing when the driver follows case 2. >> > > Do we need to unregister it at __exit initcall? > What side effects would be of the stub driver presence on the GPIO bus? Any traverse on it will work as before? I checked. There is no __exit initcall. -Saravana