Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAGETcx8z4dn1j05Za6nfDeC3v4r1yo30Nqu=1K2BEsvLcqqybQ@mail.gmail.com>
 <CACRpkdaXJh_Qc-DuD7SFsZPM9GBMUgnoufcFKsy3BPUYFHMHWQ@mail.gmail.com>
 <CAGETcx-io_5tVbRBfuB-qOwm4tV0A5FR82Q21Z1dJcLbAOkd=A@mail.gmail.com> <CACRpkdb1-F1CP0AAbS5FHoDRFdX-bS2m0NOfQm9nVcery+cW4Q@mail.gmail.com>
In-Reply-To: <CACRpkdb1-F1CP0AAbS5FHoDRFdX-bS2m0NOfQm9nVcery+cW4Q@mail.gmail.com>
From:   Saravana Kannan <saravanak@google.com>
Date:   Sun, 26 Jun 2022 23:10:01 -0700
Message-ID: <CAGETcx85JYX2ktGvEWTUn60-BQ40-5w0SwKjHtSePDAt=DA7kw@mail.gmail.com>
Subject: Re: Default async probing for DT based systems
To:     Linus Walleij <linus.walleij@linaro.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Kevin Hilman <khilman@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Android Kernel Team <kernel-team@android.com>,
        Linux PM <linux-pm@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Jun 25, 2022 at 11:09 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Jun 17, 2022 at 8:01 PM Saravana Kannan <saravanak@google.com> wrote:
> > On Fri, Jun 17, 2022 at 1:21 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Thu, Jun 16, 2022 at 5:25 AM Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > > Since fw_devlink=on is the default behavior and fw_devlink understands
> > > > approximately 24 DT bindings,
> > >
> > > How can I see which these are, in the kernel tree?
> >
> > device/of/property.c has an array of these binding handling functions
> > in of_supplier_bindings[].
> >
> > Most of the functions there are created using DEFINE_SIMPLE_PROP() or
> > DEFINE_SUFFIX_PROP() that's also in the same file.
>
> Thanks!
>
> We already have some device links in pin control, it's an opt-in for
> drivers, used e.g in drivers/pinctrl/stm32/pinctrl-stm32.c
> where you see
> pctl->pctl_desc.link_consumers = true;
> how does that
> play with this? Double device links at different levels?

Depends on what device you use for the supplier.

If it's the true device that probes and registers with the pinctrl
framework, then there won't be any double device links. It'll actually
be helpful because fw_devlink uses these attempts initiated by the
driver to confirm the dependencies it inferred from DT -- so when it
infers a cycle, it'll keep the links that drivers have attempted and
"ignore" the rest of the links in the cycle when it comes to probe
ordering.

If you use the devices the pinctrl framework creates on the gpio-bus
as the supplier for the device link, then yes, it'll be additional
device links. I'm not sure how useful they are on top of the ones
fw_devlink creates with the true device. If you don't need to do any
special suspend sequence for each of the individual gpio-devices, then
I'd recommend just creating one with the true device as the supplier.

-Saravana

>
> I had a patch to just enforce device links on all pinctrl resources,
> but it seemed over the top:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=consumer-link-enforce&id=73441cf773ed91bff0e7f66614d391b2514188bf
>
> Yours,
> Linus Walleij