public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: William D Waddington <william.waddington@beezmo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFClue] pci_get_device, new driver model
Date: Fri, 7 Oct 2005 14:45:04 -0700	[thread overview]
Message-ID: <20051007214504.GA11545@kroah.com> (raw)
In-Reply-To: <43469FB8.50303@beezmo.com>

On Fri, Oct 07, 2005 at 09:18:00AM -0700, William D Waddington wrote:
> CRAP, I think this one got sent when half written - sorry about that.
> 
> I'm missing something fundamental, and beg your indulgence.  Read LDD 3,
> googled, and looked around in the code (but not in the right places...)
> 
> My current 2.6 drivers support multiple identical PCI boards per host.
> The init code spins on pci_find_device and assigns instance/minor
> numbers as boards are found.  Load script insmods the driver,
> gets the major # from /proc/devices, and creates the /dev/ entries
> on the fly.

Ick, don't do that.

> If I convert to pci_get_device, it looks like subsequent calls in the
> loop "put" the previously "gotten" device.  I need the pci_dev struct
> to persist for later use (DMA, etc).  Do I take an additional bump to
> the ref count for each board found before looping, and "put" each when
> the driver is unloaded?

When you save the pointer off, you need to increment the count.

> If I just give in to the new driver model how/when do I associate
> instance/minor numbers with boards found?

It doesn't matter.  Use udev to handle your device naming for you, it
can associate any type of name with any type of device you have, and you
can do it by topology, location, serial number, or the phase of the
moon.

> Is it ever possible for ordinary PCI boards to be (logically) removed
> and re-added w/out removing the driver?

Yes, on hotplug pci systems.  You can fake this out by testing with the
fakephp driver if you don't have this kind of hardware.

> If so, how to maintain association between a particular board and
> minor number?

Again, use udev, that's what it is there for.

Hope this helps,

greg k-h

  parent reply	other threads:[~2005-10-07 21:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-07 16:18 [RFClue] pci_get_device, new driver model William D Waddington
2005-10-07 17:28 ` Alan Cox
2005-10-07 17:18   ` William D Waddington
2005-10-07 18:36     ` Alan Cox
2005-10-07 21:45 ` Greg KH [this message]
2005-10-07 22:03   ` Greg KH
2005-10-07 22:04     ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2005-10-07 15:56 William D Waddington

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=20051007214504.GA11545@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=william.waddington@beezmo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox