Re: USB Subsystem

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

 



On Tue, Apr 14, 2009 at 1:35 PM, Arjun Joshi <arjun.joshi@xxxxxxxxxxxxxx> wrote:
> Hi All,
>
> I am new to this mailing list and to the linux kernel. So the question below
> might seem a little simple. Ok here goes..
>
> I read that "struct bus_type" object is registered with the driver core when
> the specific  subsytem is loaded in the kernel.
>
> Now in context of USB, I want to know at which point is the USB subsystem
> loaded in the kernel  and what will be the next sequences of registrations
> in the driver core?
>

it is in drivers/usb/core/usb.c:


1088 subsys_initcall(usb_init);

which insert the function usb_init() to be called during subsystem
initialization.

tracing further, inside usb_init():

1018         retval = bus_register(&usb_bus_type);
1019         if (retval)
1020                 goto bus_register_failed;
1021         retval = bus_register_notifier(&usb_bus_type, &usb_bus_nb);
1022         if (retval)
1023                 goto bus_notifier_failed;
1024         retval = usb_host_init();
1025         if (retval)
1026                 goto host_init_failed;
1027         retval = usb_major_init();
1028         if (retval)
1029                 goto major_init_failed;
1030         retval = usb_register(&usbfs_driver);
1031         if (retval)
1032                 goto driver_register_failed;
1033         retval = usb_devio_init();
1034         if (retval)
1035                 goto usb_devio_init_failed;
1036         retval = usbfs_init();
1037         if (retval)
1038                 goto fs_init_failed;
1039         retval = usb_hub_init();

and the function call usb_register(&usbfs_driver) gave rise to the
earliest usb message in dmesg output as below:

278 usbcore: registered new interface driver usbfs
279 usbcore: registered new interface driver hub
280 usbcore: registered new device driver usb
281 PCI: Using ACPI for IRQ routing

hope these helped.

> In the linux kernel the "struct device" or "struct device_driver" object are
> embedded in a higher layer structure. What is the reason for designing the
> kernel in the above way?
>

it is called drivers model.   Meant for function calls propagation
downwards, as objects are registered below one another.   And it aimed
to be generic enough to be used across many variation in hardware
types.

read this (in kernel source):

Documentation/driver-model:

porting.txt  platform.txt  overview.txt  interface.txt  driver.txt
devres.txt  class.txt  bus.txt  binding.txt  device.txt

-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux