public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: mochel@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [BKPATCH] bus notifiers for the generic device model
Date: Wed, 4 Dec 2002 14:29:39 -0800	[thread overview]
Message-ID: <20021204222938.GA29519@kroah.com> (raw)
In-Reply-To: <200212041935.gB4JZ0p03464@localhost.localdomain>

On Wed, Dec 04, 2002 at 01:35:00PM -0600, James Bottomley wrote:
> greg@kroah.com said:
> > Why not have a call in the driver that notifies the bus specific core
> > of this?  Or just check the status of the return value of your "probe"
> > function that the bus provides.  See usb_device_probe() and
> > pci_device_probe() for examples of this. 
> 
> Well, I did do it this way for parisc.  However, I assumed from reading the 
> driver model docs that we were transitioning to using the generic driver probe 
> rather than doing probe interceptions like this.
> 
> Doing it like this just seems rather clumsy.  wouldn't it be better to 
> deprecate bus specific registrations in favour of the generic one?

I don't know.  Then for every bus specific driver, they would have to do
the "dereference the structure" logic before they can start to determine
if they should bind to this specific device.  That's all the PCI and USB
code really does, strip out the proper structures that are relevant to
the specific bus type, and then call the driver.

So in the end you would probably have a lot of duplicated code that
would be better off being in one place, like it is today :)

> There is another advantage to notifiers: they can be chained.  Certain bus 
> architectures need to do additional setup for things like pci devices.  They 
> would be able to do this by attaching a notifier.

That seems a bit overkill.  The bus specific code can add those
architecture setup hooks right now if it's needed, right?

thanks,

greg k-h

  reply	other threads:[~2002-12-04 22:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-04 17:09 [BKPATCH] bus notifiers for the generic device model James Bottomley
2002-12-04 17:56 ` Greg KH
2002-12-04 18:04   ` James Bottomley
2002-12-04 18:04     ` Patrick Mochel
2002-12-04 18:42       ` Jeff Garzik
2002-12-05  3:33         ` Patrick Mochel
2002-12-04 18:13     ` Greg KH
2002-12-04 19:35       ` James Bottomley
2002-12-04 22:29         ` Greg KH [this message]
2002-12-05  3:50           ` Patrick Mochel
2002-12-05 16:14             ` James Bottomley
2002-12-05 16:57               ` Jeff Garzik
2002-12-06 19:10               ` Patrick Mochel
2002-12-04 18:10   ` Mike Anderson
2002-12-04 18:52     ` Greg KH

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=20021204222938.GA29519@kroah.com \
    --to=greg@kroah.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox