Received: by 10.192.165.148 with SMTP id m20csp2376182imm; Sun, 6 May 2018 13:21:14 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrb28ObZgr/W/r+rMfjIONXizdZjJ7Szu3cO46HYOx5YvEA/ITnCpvr118ccyW3eGj+h77U X-Received: by 2002:a65:4502:: with SMTP id n2-v6mr27412491pgq.95.1525638074732; Sun, 06 May 2018 13:21:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525638074; cv=none; d=google.com; s=arc-20160816; b=eAxbL5thSIRv92ahwCHiQfNNaY/B44wZA01/Iw18JPdDYt0MN3+5so7PZJ0ezsKkHC ApscQFKypoILL6SsF3YZhR64F/l3KhoZk6DjKHeqPj/pAwbLSUTe+kq8jBB9/8ISs8qt Xph75njtR03kP9V0VvnB5mQ1AbZsAeT2ValgXRRhyKSLonCnN7TDbmSsdX+2dy66dlmh bt0rbjpDPup2SWLvQ+Ei5buDVJrWTdMFL8j+W9Tpmd++f5pNZl93DcytEB29ybxbR+Qe 0P+0Ah1xF0nON/27anzo6xYdw1ZLrNMkg1D+jI1GIHLg2IvMeKIDhSSMY3yPFpwSyo04 t5Og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=Qvh0uLxgVa+shi42QJ/QCui2zXvhol/2Nqji42y0KJQ=; b=YtWPNRNGgo6uIK67Gqh6nL7T/rWzmR9HrIJm2+1ZLqwkRM1S7tQtqD6/Yidf4oHaJs afjfR5DczaKzdSkUuXsv6DTRMjxJeZyN9C3mM8MHrXp27My/qM7bzgUEecGwIl0vaE4x SKE8SR3DG60mJV4hwuoFsTlSE72xdpRXTyKXKdxvFaM9PWrVPqVSW4yfgYt1iLoCbR8k L6NZGrBHYE95LioqiTxBRyUzCVR5eGXcQkkeeTJHDiGyUFeN65pM7mvPcOvSNeNtZJDZ cuQVK6qsvz9Bj/WtZEPl1cPCfqRQlBnMRZFqajWjHDpB3nBAHsHj6tAGMVM9CIjXiuyX p/Mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=xV2xm+8v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b17-v6si4902132pgv.196.2018.05.06.13.21.00; Sun, 06 May 2018 13:21:14 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=xV2xm+8v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751910AbeEFUUb (ORCPT + 99 others); Sun, 6 May 2018 16:20:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:55110 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751782AbeEFUU3 (ORCPT ); Sun, 6 May 2018 16:20:29 -0400 Received: from localhost (unknown [104.129.198.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 35CD821841; Sun, 6 May 2018 20:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1525638029; bh=qHpYM6hvxV12Evy1vweOFvJcFCppQFILjUck3HB8eVU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xV2xm+8v0EYLO+x8jd2YlxMlrZleCrGu3r4NsWiwZ/i68eJGtiCOiviS1BroD0TyT dZDb9gjNtxS3OsKMso5FyaAWQawNynUburuQLby/bORX/GaZG530Bh/VKc76IZ0+3/ niKDDIDd0brYAyH4qefy4Sv+6DUXVtvjx2I7cXbQ= Date: Sun, 6 May 2018 13:20:18 -0700 From: Greg Kroah-Hartman To: Finn Thain Cc: Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nubus: Unconditionally register bus type Message-ID: <20180506202018.GC8924@kroah.com> References: <5aee5ed3.1c69fb81.19d98.ef06SMTPIN_ADDED_MISSING@mx.google.com> <20180506045530.GA5328@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 06, 2018 at 04:00:15PM +1000, Finn Thain wrote: > On Sat, 5 May 2018, Greg Kroah-Hartman wrote: > > > On Sun, May 06, 2018 at 11:47:52AM +1000, Finn Thain wrote: > > > Loading a NuBus driver module on a non-NuBus machine triggers the > > > BUG_ON(!drv->bus->p) in driver_register() because the bus does not get > > > registered unless MACH_IS_MAC(). Avoid this by registering the bus > > > unconditionally using postcore_initcall(). > > > > > > Cc: Greg Kroah-Hartman > > > Reported-by: Michael Schmitz > > > Tested-by: Stan Johnson > > > Fixes: 7f86c765a6a2 ("nubus: Add support for the driver model") > > > Signed-off-by: Finn Thain > > > --- > > > drivers/nubus/bus.c | 3 ++- > > > drivers/nubus/nubus.c | 5 ----- > > > include/linux/nubus.h | 1 - > > > 3 files changed, 2 insertions(+), 7 deletions(-) > > > > > > diff --git a/drivers/nubus/bus.c b/drivers/nubus/bus.c > > > index d306c348c857..27ca9f1a281b 100644 > > > --- a/drivers/nubus/bus.c > > > +++ b/drivers/nubus/bus.c > > > @@ -63,7 +63,7 @@ static struct device nubus_parent = { > > > .init_name = "nubus", > > > }; > > > > > > -int __init nubus_bus_register(void) > > > +static int __init nubus_bus_register(void) > > > { > > > int err; > > > > > > @@ -78,6 +78,7 @@ int __init nubus_bus_register(void) > > > device_unregister(&nubus_parent); > > > return err; > > > } > > > +postcore_initcall(nubus_bus_register); > > > > Why not just have an "bus is registered" flag in your driver register > > function that refuses to let drivers register with the driver core if it > > isn't set? > > Perhaps that should happen in the core driver_register() function. BUG_ON > is frowned upon, after all. Would that be acceptable? I don't understand what you mean here, perhaps make a patch to show it? > I found a few drivers that set a flag the way you describe, which could > then be simplified. > > But that pattern is rare. Most buses use the postcore_initcall() pattern, > and so my patch took the conventional approach. It all depends on link order, not necessarily the postcore stuff. > > And then fix your linking error, the bus should come first in link > > order, before your drivers :) > > > > I didn't encounter any errors. How shall I reproduce this? If you have not seen this error, then why change the code at all if it is working properly? Most busses do not need this as they have their link order set up correctly, no need to mess with stuff that is not broken :) thanks, greg k-h