I am writing a virtio driver for a device that is seen in the original driver as a platform device, that is the parent of a character device in the device tree.
In the tutorials that I followed, The virtio drivers are always done for "regular" character devices.
I wanted to create my virtio driver for it to expose a fake platform device as a parent of a "regular" character device.
My question is this one: Should I detect my virtual device in the regular way using the probe function and then create my platform device inside of it or is there a recommended way or order to create both (the platform device and the character device (child))?
When we get the virtio device and trigger the associated probe, we can then register a platform driver and then add some platform devices correponding to your needs.
And your device will appear as a platform device instead of a virtio_device in the guest OS.
Related
I am new to Linux device driver. During reading books, I learnt that a match between a device and a driver usually happens under a bus driver, providing that the bus driver is registered to the core in the first place. The bus driver maintains two lists, one for devices on the bus, and the other for drivers for the devices on the bus. whenever a device or driver is registered with the bus driver, the bus driver is reponsible to find a match (via compatible string in case of DTS) between the device (or driver) and a driver (or devices).
In the device tree passed to kernel, it seems that there is no place to specify the bus_type of each device. Then how kernel knows to register a device to a proper bus?
Take platform bus for example, I have a pinctrl driver, from the log I know that the pinctrl driver's probe() is invoked, which implies that a match has happened under platform bus...but in DTS there is no place to specify my, say, pinmux device node is on platform bus (although the compatible string matchs).
I have a device with SPI bus which is connected via PCIe to a linux machine. I'm developing a simple SPI driver for this device. With spi_register_master I can create a SPI master (it is listed under /sys/class/spi_master/spixxxx).
For accessing the bus I would like to use spidev from the userland, but I have not found a way to register a spidev device at runtime. All ways I have found use the device tree to insert the information into the linux kernel.
Is there some way to create spidevdevicesat runtime?
Edit: I suppose it is the same problem with all protocol drivers and not limited to spidev.
I am trying to understand Linux USB Device drivers, most of the documentation speaks about the USB Device decoded into
configuration
interface
Endpoint
Linux only supports one configuration. Are these hardware entities or simply data present in the driver of the data which it passes on USB Device detection
When referring to a USB device, the terms "configuration", "interface", and "endpoint", are all properties of the device. They can be changed if you are able to reprogram the device, but if not then you can just think of them as part of the hardware.
The device has binary chunks of data called "descriptors" which the computer fetches so the computer can know what configurations, interfaces, and endpoints the device has.
You can learn all about those items and their descriptors by reading the USB 2.0 specification:
https://usb.org/document-library/usb-20-specification
Wanted to know how a device is detected in Linux? What exactly is the workflow of the device driver in device detection?
It is the Kernel's job to detect devices as it has the lowest level access to the available hardware. When the Kernel scans through all available addresses it maintains a list of Vendor and Device IDs.
To use PCI bus devices as an example, there is a Vendor ID and a Device ID associated with all PCI devices.
Device drivers are written in such a way as to identify to the Kernel what kinds of devices the driver is able to control. Drivers may advertise that they can handle more than one vendor and device type combination.
The Kernel will allocate a driver to each device based on these IDs. A similar process is in place for USB devices. Older technologies like legacy devices (serial ports, parallel, ps2 mice/keyboards) will have explicitly hardcoded methods of associating particular drivers with devices.
You can use the Linux commands lsusb and lspci to see the available devices and IDs on your system.
So in direct answer to your question - the device driver usually does nothing to detect the device, at least in the first instance. Once the driver is associated with a device (by the Kernel) the driver will likely do further interrogation of the device to ensure it contains the right firmware or is the right hardware revision, etc.
I am new to working on virtual USB device simulation in Linux. So far I have installed the virtual host control (vhci) libraries as per this tutorial (http://sourceforge.net/p/usb-vhci/wiki/Home/) and can see a virtual USB device being created which has some typical specifications that the library implements (Bus 05 in the image with the vendor and product IDs being "dead" and "beef" respectively).
However I want the created virtual device to have the specifications of a real device I have at hand (a mouse, for example).
So how to enumerate and initialize a virtual USB device with the same credentials as another device?
The kernel module (vhci-hcd) is only a (virtual) host controller that you can attach virtual devices to.
If you want to emulate eg a mouse you should get the libusb_vhci from the same source, and look into the examples. These are bare minimum starting points that does nothing except for the basic usb device handling. You'll have to extend this with all descriptors and protocol handling for a USB HID mouse or whatever you want to emulate.
http://www.usbmadesimple.co.uk/ums_5.htm should be a good starting point.
you can use lsusb and in particular lsusb -D to dump the descriptors of devices you have connected.