[RFClue] pci_get_device, new driver model

[RFClue] pci_get_device, new driver model

[William D Waddington]

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.

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?

If I just give in to the new driver model how/when do I associate
instance/minor numbers with boards found?  Is it ever possible for
ordinary PCI boards to be (logically) removed and re-added w/out
removing the driver?  If so, how to maintain association between
a particular board and minor number?

I don't have any control over the tools available on the user's
target host.

Pointers to code supporting multiple boards per driver would be
very helpful.

Not subscribed but lurking.  Thanks,
Bill
-- 
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Re: [RFClue] pci_get_device, new driver model

[Alan Cox]

On Gwe, 2005-10-07 at 09:18 -0700, William D Waddington wrote:
> 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?

If you are saving the pci device point then yes you should. If you are
using pci_module_init() and the hotplug interface instead then it may
not be neccessary.

> If I just give in to the new driver model how/when do I associate
> instance/minor numbers with boards found?  Is it ever possible for
> ordinary PCI boards to be (logically) removed and re-added w/out
> removing the driver?  If so, how to maintain association between
> a particular board and minor number?

Its up to you how you implement this. One requirement I suspect would be
that the boards have unique serial numbers. Most drivers do not retain
state if someone unplugs a board, moves it and plugs it back in. Instead
they report the old device as "gone" and let user space sort it out

[RFClue] pci_get_device, new driver model

[William D Waddington]

Alan Cox wrote:
> On Gwe, 2005-10-07 at 09:18 -0700, William D Waddington wrote:

>>If I just give in to the new driver model how/when do I associate
>>instance/minor numbers with boards found?  Is it ever possible for
>>ordinary PCI boards to be (logically) removed and re-added w/out
>>removing the driver?  If so, how to maintain association between
>>a particular board and minor number?
> 
> 
> Its up to you how you implement this. One requirement I suspect would be
> that the boards have unique serial numbers. Most drivers do not retain
> state if someone unplugs a board, moves it and plugs it back in. Instead
> they report the old device as "gone" and let user space sort it out

I don't have unique serial #s available, but my question wasn't clear.

Is it ever possible that the hotplug stuff will try to remove and re-add
one (or all) of my boards when there _hasn't_ been a physical change or
power cycle/reboot/driver reload/whatever.

As long as the driver gets reloaded following any logical or physical
system change I will just go through the instance/minor assignment
again.  What I don't want is /dev/idr0 /dev/idr1 turning into /dev/idr2
/dev/idr3 because someone tickled the hotplug controls.

Still not quite clear how to assocuiate instance/minor #s with boards.
Do I just keep a global counter and bump it each time probe (or init)
gets called for each board?  Hence my worry above.

Thanks for the quick reply.

Bill (not sure if this will thread OK)
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Re: [RFClue] pci_get_device, new driver model

[Alan Cox]

On Gwe, 2005-10-07 at 10:18 -0700, William D Waddington wrote:
> Is it ever possible that the hotplug stuff will try to remove and re-add
> one (or all) of my boards when there _hasn't_ been a physical change or
> power cycle/reboot/driver reload/whatever.

Only if the user does it deliberately.

> Still not quite clear how to assocuiate instance/minor #s with boards.
> Do I just keep a global counter and bump it each time probe (or init)
> gets called for each board?  Hence my worry above.

It really is up to you. Most drivers just issue the first free minor
number.

Alan

Re: [RFClue] pci_get_device, new driver model

[Greg KH]

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

Re: [RFClue] pci_get_device, new driver model

[Greg KH]

On Fri, Oct 07, 2005 at 02:45:04PM -0700, Greg KH wrote:
> > If I just give in to the new driver model how/when do I associate
> > instance/minor numbers with boards found?

Oh, and if you don't convert to the new driver model, your driver will
just die a horrible death on pci hotplug systems, as it has no way to be
notified that the device was removed.

thanks,

greg k-h

Re: [RFClue] pci_get_device, new driver model

[Greg KH]

On Fri, Oct 07, 2005 at 03:03:25PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2005 at 02:45:04PM -0700, Greg KH wrote:
> > > If I just give in to the new driver model how/when do I associate
> > > instance/minor numbers with boards found?
> 
> Oh, and if you don't convert to the new driver model,

And it's not "new" at all, it's been there since 2.3 days, so it's not
like you haven't had enough warning...

thanks,

greg k-h

[RFClue] pci_get_device, new driver model

[William D Waddington]

I'm missing something fundamental, and beg your indulgence.

My current 2.6 drivers support multiple indentical PCI boards.
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.




Not subscribed but lurking,
Bill
-- 
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch