Many thanks.
On 7/9/07, Greg KH <greg@xxxxxxxxx
> wrote:
I am trying to understand how drivers got linked to their devices at start-up and during hot plugging with an example of PCI.
but why it is said in LDD book "every PCI motherboard is equipped with PCI aware firmware and at system boot up it performs configuration transaction with every PCI peripheral" ? who else will do otherwise ? kernel ? Specifically I am trying to understand who fills in the device structure, since they must be filled before we register any driver.
Matching of driver with device.
where else is list maintained then ? How would one match the driver with their device if system doesnt maintain any such list.
So are you saying that /sbin/hotplug is never called ? Isn't the list of module you are talking about is in /lib/modules/KERNEL_NAME/modules.pcimap
Can you please give the sequence of steps (combine the overall picture) stating how device got configured with their drivers at boot time and hotplugging ? I am finding it difficult to combine the whole picture in to one. Thanks in advance.
On Tue, Jul 03, 2007 at 03:17:35PM -0700, Kamal gupta wrote:
> Hi
>
> I got the answers to most of my questions except one thing. Would be glad if
> anyone can give some hint.
>
> Here is what I understood (very briefly), please feel free to point out if I
> am wrong:
What specifically are you looking to understand here? PCI device and
bus initialization or the more "generic" driver core bus and driver
interaction? They are two separate things.
I am trying to understand how drivers got linked to their devices at start-up and during hot plugging with an example of PCI.
> When system initializes, firmware scans for all the devices,
Depends on the architecture.
but why it is said in LDD book "every PCI motherboard is equipped with PCI aware firmware and at system boot up it performs configuration transaction with every PCI peripheral" ? who else will do otherwise ? kernel ? Specifically I am trying to understand who fills in the device structure, since they must be filled before we register any driver.
> assigns address regions and soon,
Again, depends on the architecture.
> then comes the driver registration phase where driver matching takes
> place, which finally calls the probe function (which can reassign the
> address regions, if wants to),
No, it can't reassign pci address regions here, they are already fixed.
- What do we mean by this then (taken from Understanding_networking_internal)
Hardware initialization
This is done by the device driver in cooperation with the generic bus layer (e.g., PCI or USB). The driver, sometimes alone and sometimes with the help of user-supplied parameters, configures such features of each device as the IRQ and I/O address so that they can interact with the kernel.
> I think IRQ configuration takes place here only.
No, that happens when you call pci_enable_irq().
> Once matched, we are done.
Done with what?
Matching of driver with device.
> Since it creates the id table in registration phase, these entries are
> stored in /lib/modules/KERNEL_NAME/modules.pcimap for user space hot
> plugging.
No, no one uses those tables anymore, they are still there for backward
compatiblity with 2.4 kernels. We should delete them soon.
where else is list maintained then ? How would one match the driver with their device if system doesnt maintain any such list.
> When ever system detects the new device, kobject_hotplug invokes
> call_usermodehelper which invokes /sbin/hotplug with a input parameter
> PCI and environment variable describing the device. This /sbin/hotplug
> program then do the matching and we are done.
Not really, all that callout does is call 'modprobe' with the module
alias given to it by the kernel, which then walks the list of module
aliases and loads all modules that match. Then the kernel does the
matching of driver to device with the call to the individual driver
probe() functions until it finds a match.
So are you saying that /sbin/hotplug is never called ? Isn't the list of module you are talking about is in /lib/modules/KERNEL_NAME/modules.pcimap
> My question is, I looked at the probe.c whose functions (scan slot and scan
> bus) are used by the hotplug directory. I think what is happening here is,
> each of the core files define enable slot function which configures the
> device and use the functions in probe file. Then there is top file,
> pci_hotplug_core which calls this enable slot in power_write_file function.
> Can anyone please explain what is happening here ? and if hot-plugging is
> there via /sbin/hotplug ? why this ?
Ok, I think you are getting PCI hotplug mixed up with the more generic
function of just loading and binding pci drivers to devices. PCI
hotplug is to enable and disable PCI devices at runtime, if you have the
special hardware to allow this to happen. These drivers control the
special hardware to do this.
> PS: Potentially, there is no device initialization phase for PCI (unlike
> net_dev_init defined in *net/core/dev.c*), since firmware BIOS already did
> that stuff. Am I right ?
I do not understand the question.
Can you please give the sequence of steps (combine the overall picture) stating how device got configured with their drivers at boot time and hotplugging ? I am finding it difficult to combine the whole picture in to one. Thanks in advance.
Again, what specifically are you trying to understand here?
thanks,
greg k-h
--
Kamal Kant Gupta
