Recently I've been reading through Linux usb-serial.c and generic.c, finding that the probe method of struct usb_driver is invoked when usb core detects a new device plugged.
However I couldn't find where the probe method of struct usb_serial_driver is called, seems that this method is used for some tty related setups. Actually, the template driver generic.c didn't implement this probe method.
In usb-serial.c, usb_serial_init() registered:
bus_register(&usb_serial_bus_type)
tty_register_driver(usb_serial_tty_driver)
usb_register(&usb_serial_driver)
usb_serial_generic_register(debug)
usb_serial_generic_register() just set the device's idVendor and idProduct in its generic_device_ids array. and also registered:
usb_serial_register_drivers(&generic_driver, serial_drivers)
it will register generic_driver to the usb_bus_type bus, so device_attach() will found it
you know, usb_serial_register will add driver to the global list:usb_serial_driver_list,
and register the driver to usb-serial bus.
The generic_driver is a middle lay for probe usb-serial drivers. Actually when the hub detected your usb device has been plugged in, then it will call hub_port_connect_change(core/hub.c), it will distribute current to device and enumerate the device. Last, it will get into usb_new_device(udev) and register the device: device_add(&udev->dev), create file node in /sysfs, and probe the corresponding driver. bus_probe_device() -> device_attach , so, the generic_probe will be called here, and then, it will match the device and call usb_serial_probe() -> search_serial_device() -> ... -> type->probe(), it will search the drive on usb_serial_driver_list, then probe the real serial driver.
Related
I'm studying linux device driver. currently, I understand flows of device driver approximatively, but I dont know how probe() function gets its arguments.
For example, here is my code and this is based on kernel 3.10.
static int gpio_led_probe(struct platform_device *pdev) {
struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
struct gpio_leds_priv *priv;
....
priv = gpio_leds_create_of(pdev);
....
}
As like this, the argument 'pdev' is using for various point of source. I'm understading when probe() called and it's role, but I cannot find where the data 'pdev' comes from.
thanks for read my thread, and sorry that my english is not good.
platform device specific data while probing comes from the platform setup code or from device tree.
you can find the related code in arch/arm/borad/device files
struct platform_device embedded with platform_data structure where you will pass the platform related data to the drivers.
in modern kernels platform data is passed to device drivers through device tree. device tree can be found in /arch/arm/boot/dts/your_device
You can provide the platform device information by filling the platform_device structure or you have to provide your device information in device tree, during system bootup, platform_device structure gets populated based on the device tree information.In latest kernel usually we use device tree to get the device information.
I'm creating my first PCIe driver for Linux and have a question regarding which structure to use for the pci_set_drvdata() function.
The PCIe hardware is built in house and we will be using DMA to send data to and from the device. It is not a sound card or any other subsystem which needs to be plugged into the kernel.
When I look at examples there seems to be a specific struct to fill in and then send to pci_set_drvdata().
What do I fill in for this case? Do I simply ignore this and send in a blank structure? The line I am referring to in any PCIe driver is:
struct structure_in_question *my_struct;
my_struct = kzalloc( sizeof(*my_struct), GFP_KERNEL) );
This is usually found in the probe() function.
That function is used for associating with the device private data that cannot be supplied any other way. If there is no such data then the function should simply not be used.
It is a convenient way for example to save a pointer to a local dynamically allocated device context in the device probe callback and then retrieve it back with pci_get_drvdata in the device remove callback and do a proper cleanup of the context.
Before registering a PCI driver, we have to initialize struct pci_driver and pass it to pci_register_driver. One of fields of the structure is a pointer to driver's probe function.
My question is - when the kernel calls driver's probe routine. Is it guaranteed to be right after the call to pci_register_driver or may happen any other time? What is determining this behaviour?
UPDATE
pci_register_driver is a macro expanded into __pci_register_driver, which in turn calls driver_register, and driver_register calls bus_add_driver.
There's a following code in bus_add_driver:
if (drv->bus->p->drivers_autoprobe) {
error = driver_attach(drv);
if (error)
goto out_unregister;
}
driver_attach will call bus_for_each_dev with argument __driver_attach, which will invoke driver_probe_device
And driver_probe_device ultimately calls really_probe:
if (dev->bus->probe) {
ret = dev->bus->probe(dev);
The one thing I'm not sure about, is if the flag drivers_autoprobe gets set for pci_bus.
After the PCI core within your linux kernel has enumerated your device during the link training phase (this occurs by default at boot), it will gather information about the End Point devices connected to it, this includes the Vendor id, and the device id. The PCI core will then iterate through all of the drivers that have been registered to it with the function `pci_register_driver' and see if the driver supports this vendor/device combination.
A driver identifies that it supports that vendor/device combination using the struct pci_device_id id_table field of the pci_driver structure.
A typical implementation would look something like this:
#define VENDOR 0xBEEF // vendor of EP device
#define DEVICE 0x1111 // device id of EP
static struct pci_device_id module_dev_table[] = {
{ PCI_DEVICE(VENDOR, DEVICE)},
{0, },
};
// PCI driver structure used to register this driver with the kernel
static struct pci_driver fpga_driver = {
.id_table = module_dev_table,
.probe = module_probe,
.remove = module_remove,
.suspend = module_suspend,
.resume = module_resume,
};
When the PCI core identifies your driver as a driver that supports a device on the bus, your probe function will then be called.
So to answer your question, NO, your probe function is not guaranteed to be called immediately after you register your driver, and almost certainly will not be. Your probe function will be called immediately after PCI core enumeration/Link training identifies a device which your driver supports.
When kernel detects a PCI device on PCI bus, kernel gets the device name based on the device tree. After this kernel scans through list of registered drivers if any of the drivers handle this device. If yes, then kernel will call probe of that particular driver.
In Linux, how do you create an input event interface with a user specified event number and map that to a specific device event?
I'm using the gpio-keys driver to translate key presses from a keypad. I define the keys to be used in my board configuration source file as shown below
static struct gpio_keys_button ev_keys[] = {
[0] = {
.type = EV_KEY,
.active_low = 1,
.wakeup = 0,
.debounce_interval = KEYS_DEBOUNCE_MS,
.code = KEY_MUTE,
.desc = "mute",
.gpio = PUSHBUTTON_MUTE,
}
};
and register this with the kernel.
And I enable the event interface and GPIO buttons when building the kernel.
Device Drivers ---> Input device support --> Event interface
Device Drivers ---> Input device support --> Keyboards --> GPIO buttons
This creates a node to the event at /dev/input/event0 to which the GPIO button events are mapped. In a system that uses only one event interface I can call poll() on the fd to /dev/input/event0 and everything works as expected.
Now, I have second peripheral on my system that uses /dev/input/event0 by default and I need to map the events from the gpio-keys driver to another event. Any suggestions on how I go about creating an event with a number/id I can specify and then map this to the gpio-keys events?
Thanks.
If you mean by "mapping" specifying the name of the /dev/input/eventX 'file', you should use Udev. The kernel assigns the number of the event device, it is a bad idea and probably impossible to try and force this number since you never know which other device may have gotten this number first.
My recommendation would be to let Udev create a symlink that points to your device; you can choose your own name and use that in your program (i.e. /dev/my_first_keypad). For example, my Wacom tablet is assigned /dev/wacom with the following udev rule:
KERNEL=="event*", SUBSYSTEM=="input", SUBSYSTEMS=="input", ATTRS{name}=="Wacom Volito", SYMLINK+="wacom"
The trick is to find the proper set of variables to exactly specify your keypad. If it is USB based, the vender/product ID are a good start. Otherwise, use udevadm info --export-db to get a full dump of the Udev database. Udev rules go in files in /etc/udev/rules.d/ or /lib/udev.d, depending on the Linux distribution you are using.
You can check System.map file for functions that register event interface. The one that comes first, usually gets lowest eventX number and later functions gets eventX number increased by one. IMO, its ok to rely on static device node file for embedded device where device configuration is static and is not going to change during operation, but generally you should use udev for you purposes.
As I understood after reading the chapter related to The Linux Device Model in the Linux Device Drivers 3rd Edition, when a new device is configured, the kernel (2.6) follows more or less this sequence:
The Device is registered in the driver core (device_register(), what includes device initialization)
A kobject is registered in the device model
It creates an entry in sysfs and provokes a hotplug event
Bus and drivers are checked to see which one matches with the device
Probe
Device is binded to the driver
My main doubt is, in step 1, when is device_register() called and what fields should already be set in the device struct?
Is it called by the bus to which the device is connected? Any example in the code?
Have I misunderstood anything? :)
PCI hotplug code is going to call pci_do_scan_bus() to go through all slots, see if we find a device/bridge and add them to our device tree :
unsigned int __devinit pci_do_scan_bus(struct pci_bus *bus) {
max = pci_scan_child_bus(bus) //scan bus for all slots and devices in them
pci_bus_add_devices(bus); //add what we find
...
}
The fields in struct device are actually filled up as part of call to pci_scan_child_bus(). Here's the call graph (sort of :)):
pci_scan_child_bus > pci_scan_slot (scan for slots on the bus) > pci_scan_single_device > pci_device_add > device_initialize.
Note that device_initialize() is the first part of device_register(). You will see that the fields of struct device are filled up in pci_device_add after the call to device_initialize(). You can find it under drivers/pci/probe.c in the kernel sources. The struct pci_dev will also be filled up which will later be used by the device specific driver.
The actual addition of the kobject to the device hierarchy happens in pci_bus_add_devices. Here's the call graph :
pci_bus_add_devices > pci_bus_add_device > device_add.
As you can see, this call flow completes the second part of the device_register() function.
So, in short, device_register() consists of : 1. Initialize device and 2. Add device.
pci_device_add does step 1 and pci_bus_add_device does step 2.
Files of interest are : drivers/pci/{pci.c,bus.c,probe.c}
In struct bus type there is pointer to function match, whose job is to match the driver associated with device. So when the device is associated with a bus, then as soon as the device is connected to bus then it is responsiblity of bus to search for the device.
Pls correct me if that is not the case.