Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201107224727.11015-1-sudipm.mukherjee@gmail.com> <20201108082317.GA40741@kroah.com>
In-Reply-To: <20201108082317.GA40741@kroah.com>
From:   Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Mon, 9 Nov 2020 10:14:46 +0000
Message-ID: <CADVatmN8SbZWVGf_xe_K1g7M9ArHXF8TUhYyBgQcydBF4_zp9g@mail.gmail.com>
Subject: Re: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     "Rafael J . Wysocki" <rafael@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Shawn Guo <shawnguo@kernel.org>,
        Stephen Boyd <sboyd@kernel.org>,
        Dong Aisheng <aisheng.dong@nxp.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Greg,

On Sun, Nov 8, 2020 at 8:23 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Sat, Nov 07, 2020 at 10:47:27PM +0000, Sudip Mukherjee wrote:
> > When CONFIG_MXC_CLK_SCU is configured as 'm' the build fails as it
> > is unable to find device_is_bound(). The error being:
> > ERROR: modpost: "device_is_bound" [drivers/clk/imx/clk-imx-scu.ko]
> >       undefined!
> >
> > Export the symbol so that the module finds it.
> >
> > Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells binding support")
> > Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> > ---
> >
> > resending with the Fixes: tag.
> >
> >  drivers/base/dd.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > index 148e81969e04..a796a57e5efb 100644
> > --- a/drivers/base/dd.c
> > +++ b/drivers/base/dd.c
> > @@ -353,6 +353,7 @@ bool device_is_bound(struct device *dev)
> >  {
> >       return dev->p && klist_node_attached(&dev->p->knode_driver);
> >  }
> > +EXPORT_SYMBOL(device_is_bound);
>
> EXPORT_SYMBOL_GPL() please, like all the other exports in this file.
>
> Also, wait, no, don't call this, are you sure you are calling it in a
> race-free way?  And what branch/tree is the above commit in?

I have not checked fully but since it is being called from probe() I
assume the lock will be held at that time.
This is from linux-next and the original commit is in "for-next"
branch of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
repo. I came across this problem while doing my daily allmodconfig
builds. The build log is at
https://travis-ci.com/github/sudipm-mukherjee/linux-test/jobs/429382451#L24431


-- 
Regards
Sudip