Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 8 May 2018 17:59:52 +1000 (AEST)
From:   Finn Thain <fthain@telegraphics.com.au>
To:     Geert Uytterhoeven <geert@linux-m68k.org>
cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-m68k <linux-m68k@lists.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nubus: Unconditionally register bus type
In-Reply-To: <CAMuHMdUCEc0n1R6-=8fcw2xng7ETPUEs86PhC_0=1jY_AYV6Bg@mail.gmail.com>
Message-ID: <alpine.LNX.2.21.1805081638020.30@nippy.intranet>
References: <5aee5ed3.1c69fb81.19d98.ef06SMTPIN_ADDED_MISSING@mx.google.com> <20180506045530.GA5328@kroah.com> <alpine.LNX.2.21.1805061544550.8@nippy.intranet> <20180506202018.GC8924@kroah.com> <alpine.LNX.2.21.1805070930240.8@nippy.intranet>
 <alpine.LNX.2.21.1805080904460.8@nippy.intranet> <CAMuHMdUCEc0n1R6-=8fcw2xng7ETPUEs86PhC_0=1jY_AYV6Bg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 8 May 2018, Geert Uytterhoeven wrote:

> > This example is the sort of flag removal that I had in mind --
> >
> > diff --git a/drivers/base/driver.c b/drivers/base/driver.c
> > index ba912558a510..4ee22fb3db92 100644
> > --- a/drivers/base/driver.c
> > +++ b/drivers/base/driver.c
> > @@ -148,7 +148,8 @@ int driver_register(struct device_driver *drv)
> >         int ret;
> >         struct device_driver *other;
> >
> > -       BUG_ON(!drv->bus->p);
> > +       if (!drv->bus->p)
> > +               return -ENODEV;
> 
> If this is meant to handle the case where the device driver is registered
> before the bus is registered, while the latter can still happen later,
> then you want to return -EPROBE_DEFER.
> 

Returning -EAGAIN might be appropriate if driver_register() could 
reasonably expect the bus to come into existence.

However, a separation of concerns would seem to imply that the driver core 
has no way of knowing whether that might happen.

Anyway, this discussion is academic. The patch was only meant to 
illustrate a way to remove code instead of adding it, while achieving the 
same goal.

I'm not proposing this patch. I don't claim to understand all of the 
considerations that apply here. I'm certain there are situations where 
BUG_ON is appropriate. This may be one of those situations.

-- 

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
>