Re: pci_probe function is atomic?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 04, 2009 at 09:16:54PM +0530, arun c wrote:
> On Mon, May 4, 2009 at 8:19 PM, Greg KH <greg@xxxxxxxxx> wrote:
> > On Mon, May 04, 2009 at 12:47:44PM +0530, arun c wrote:
> >> Hi all,
> >>
> >> I have a dual core system(I am running kernel  2.6.22, 2.6.16, or 2.6.27  ),
> >> where I can put a maximum of 8 similar PCI cards.
> >>
> >> So in my driver I register ('pci_register_driver()') with device ID and
> >> vender ID(same for all 8 cards).
> >>
> >> I need to access a global data from the probe functions. If there are
> >> 8 PCI devices detected probe function is called one after another?
> >>
> >> or is there any chance that they execute in parallel?
> >
> > Yes, in the future (and in some types of configurations today), it could
> > execute in parallel.
> >
> > Just use a lock to control access to your shared global data structure.
> >
> > But you might wish to revisit your usage of global data, why can't it be
> > a per-device field that is dynamically created for every individual
> > device?  That would scale much better, right?
> 
> I am using a character device interface to talk to my devices.
> only one character driver controlling all the PCI devices.

Only 1?  That seems like a design mistake :)

> Even if I use per-device fields, I need to store these pointers some
> where right?

What's wrong with the per-device structure the kernel gives you?  That
is how it is supposed to be done.

> lock
> global_array[index++] = pointer_to_pci_data_of_just_now_probed_device;
> unlock

Ick, no, don't do that!

> Other wise I must be calling register_chrdev() in all the device probes and fill
> the chrdev private data field. This will end up in too many major no.
> for just one
> type of device, I think that is not fair.
> 
> So I thought I can escape without locks even if I use global data, if the
> pci_probe function is atomic!!!!!!!!!!

disconnect might not be atomic either, right?

And again, you might wish to rethink your design decisions, it doesn't
seem to match up with the "traditional" PCI driver design for Linux.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux