All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michael Schmitz <schmitzmic@gmail.com>,
	Finn Thain <fthain@telegraphics.com.au>,
	Linux/m68k <linux-m68k@lists.linux-m68k.org>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nubus: Unconditionally register bus type
Date: Tue, 8 May 2018 09:41:55 +0200	[thread overview]
Message-ID: <20180508074155.GA8561@kroah.com> (raw)
In-Reply-To: <CAMuHMdX+utbGHOV1p_oFwaKigxGBMMgkC_v5hWCO4EoVXeqezg@mail.gmail.com>

On Tue, May 08, 2018 at 09:35:10AM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Tue, May 8, 2018 at 9:25 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, May 08, 2018 at 09:07:27AM +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 8, 2018 at 9:00 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Mon, May 07, 2018 at 09:51:12AM +1200, Michael Schmitz wrote:
> >> >> the BUG() was triggered by loading a Mac Nubus network card module on
> >> >> a multiplatform kernel running on an Amiga machine. Up to Finn's Nubus
> >> >> core rewrite (this February), we've seen no errors. Since then, Nubus
> >> >> drivers fail to register because the Nubus bus is only registered on
> >> >> Macs.
> >> >>
> >> >> Can't see link order involved here at all.
> >> >
> >> > The link order is totally involved here :)
> >> >
> >> > Link order determines the order in which init calls are run, so you need
> >> > to ensure that your bus code comes before any drivers that use that bus
> >> > code in link order.  That way, at init time, your bus is created first,
> >> > preventing this type of error to happen.
> >>
> >> The issue here is not due to link ordering, but due to the bus not being
> >> registered on a system that doesn't have that particular bus.
> >
> > But how can that happen if the bus code is not present in the system at
> > that point in time?  Hardware doesn't matter at all here.
> 
> The bus code is present in the system.
> The bus is just not registered by the NuBus bus driver if the hardware
> doesn't have a NuBus host.

Ah, that sounds like some "tight" coupling that other bus cores do not
have.  That's the confusion here that I have, sorry.

> >> Akin to booting a kernel on an old PC without PCI, and loading a driver
> >> module for a PCI network card. I guess that doesn't crash (because no one
> >> has a PC without PCI anymore? ;-)
> >
> > No, it should work just fine, try it!  :)
> >
> > The driver will not bind to anything, but the bus code should work
> > properly, as long as it is initialized before the driver tries to
> > register with that specific bus type.
> 
> Hence the NuBus bus code should register the bus irregardless of the
> presence of the NuBus host hardware.

Yes it should.  Shouldn't cause any problems as long as you don't have
any hardware specific code in your bus code.  Because of this, I don't
think the original patch would help at all here, as the error would
still be the same.

So add a "is bus registered" flag to your bus and all should be fine.

thanks,

greg k-h

  reply	other threads:[~2018-05-08  7:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-06  1:47 [PATCH] nubus: Unconditionally register bus type Finn Thain
2018-05-06  4:55 ` Greg Kroah-Hartman
2018-05-06  6:00   ` Finn Thain
2018-05-06 20:20     ` Greg Kroah-Hartman
2018-05-06 21:51       ` Michael Schmitz
2018-05-08  7:00         ` Greg Kroah-Hartman
2018-05-08  7:07           ` Geert Uytterhoeven
2018-05-08  7:25             ` Greg Kroah-Hartman
2018-05-08  7:35               ` Geert Uytterhoeven
2018-05-08  7:41                 ` Greg Kroah-Hartman [this message]
2018-05-08  8:01               ` Michael Schmitz
2018-05-06 23:57       ` Finn Thain
2018-05-07 12:53         ` Geert Uytterhoeven
2018-05-07 14:45           ` Greg Kroah-Hartman
2018-05-08  6:28             ` Geert Uytterhoeven
2018-05-07 23:44         ` Finn Thain
2018-05-08  6:32           ` Geert Uytterhoeven
2018-05-08  7:59             ` Finn Thain
2018-05-08  7:01         ` Greg Kroah-Hartman
  -- strict thread matches above, loose matches on Subject: below --
2018-05-06  1:47 Finn Thain
     [not found] <5aee5ede.1c69fb81.353b4.5021SMTPIN_ADDED_MISSING@mx.google.com>
2018-05-08  7:39 ` Geert Uytterhoeven
2018-05-08  8:27   ` Finn Thain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180508074155.GA8561@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=fthain@telegraphics.com.au \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=schmitzmic@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.