Re: [PATCH v1] driver core: Fix handling of fw_devlink=permissive

[Saravana Kannan]

On Tue, Apr 28, 2020 at 8:52 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Apr 16, 2020 at 11:25:47AM -0700, Saravana Kannan wrote:
> > On Tue, Mar 31, 2020 at 12:29 AM Greg Kroah-Hartman
> > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Mon, Mar 30, 2020 at 11:18:01PM -0700, Saravana Kannan wrote:
> > > > On Mon, Mar 30, 2020 at 10:43 PM Marek Szyprowski
> > > > <m.szyprowski@xxxxxxxxxxx> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On 2020-03-31 04:28, Saravana Kannan wrote:
> > > > > > When commit 8375e74f2bca ("driver core: Add fw_devlink kernel
> > > > > > commandline option") added fw_devlink, it didn't implement "permissive"
> > > > > > mode correctly.
> > > > > >
> > > > > > That commit got the device links flags correct to make sure unprobed
> > > > > > suppliers don't block the probing of a consumer. However, if a consumer
> > > > > > is waiting for mandatory suppliers to register, that could still block a
> > > > > > consumer from probing.
> > > > > >
> > > > > > This commit fixes that by making sure in permissive mode, all suppliers
> > > > > > to a consumer are treated as a optional suppliers. So, even if a
> > > > > > consumer is waiting for suppliers to register and link itself (using the
> > > > > > DL_FLAG_SYNC_STATE_ONLY flag) to the supplier, the consumer is never
> > > > > > blocked from probing.
> > > > > >
> > > > > > Fixes: 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option")
> > > > > > Reported-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> > > > > > Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx>
> > > > > > ---
> > > > > > Hi Marek,
> > > > > >
> > > > > > If you pull in this patch and then add back in my patch that created the
> > > > > > boot problem for you, can you see if that fixes the boot issue for you?
> > > > >
> > > > > Indeed, this fixes booting on my Raspberry Pi3/4 boards with linux
> > > > > next-20200327. Thanks! :)
> > > >
> > > > Hi Marek,
> > > >
> > > > Thanks for testing, but I'm not able to find the tag next-20200327. I
> > > > can only find next-20200326 and next-20200330. I was just trying to
> > > > make sure that next-20200327 doesn't have the revert Greg did. I'm
> > > > guessing you meant next-20200326?
> > > >
> > > > > Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> > > >
> > > > Thanks!
> > > >
> > > > Greg,
> > > >
> > > > Can you pull in my fix and then revert the revert?
> > >
> > > After 5.7-rc1 is out I will, thanks.
> >
> > Hi Greg,
> >
> > Just to clarify, this patch is a bug fix and I think this patch should
> > go into all the stable branches that support fw_devlink.
> >
> > The only risky change that you needed to wait on for 5.7-rc1 is the
> > patch [1] that sets fw_devlink=permissive by default. Well, a revert
> > of the revert of [1].
> >
> > [1] - https://lore.kernel.org/lkml/20200321210305.28937-1-saravanak@xxxxxxxxxx/
>
> I don't understand, what kernels should this go back to?  Your "Fixes:"
> line just shows for a 5.7-rc1 patch, nothing older.

That's all. I was just stating the obvious I guess -- to pull this
into all the releases that have the "Fixes" commit. Btw you had
reverted the "Fixes" commit. So you'll have to revert the revert and
then apply this patch. Hope that makes sense.

-Saravana