I previously had a thought about the platform driver as well as normal device driver like :
- Platform driver is for those devices that are on chip. and ,
Normal device driver are for those that are interfaced to the proccesor chip. before coming across one i2c driver.
But here, I am reading through multi function i2c driver defined as platform driver. I had gone through https://www.kernel.org/doc/Documentation/driver-model/platform.txt. But still could not get clear idea to come to an conclusion on how to define drivers, like for both onchip as well interfaced devices. I went through this link too.. http://meld.org/discussion/general-discussion/platform-driver-vs-ordinary-device-drivers
Please somebody explain.
Your references are good but lack a definition of what is a platform device. There is one on LWN. What we can learn from this page:
Platform devices are inherently not discoverable, i.e. the hardware cannot say "Hey! I'm present!" to the software. Typical examples are i2c devices,
kernel/Documentation/i2c/instantiating-devices
states:Platform devices are bound to drivers by matching names,
So basically, the question "is it a platform device or a standard device?" is more a question of which bus it uses. To work with a particular platform device, you have to:
Not true (in theory, but true in practice). i2c devices are not onChip, but are platform devices because they are not discoverable. Also we can think of onChip devices which are normal devices. Example: an integrated PCI GPU chip on a modern x86 processor. It is discoverable, thus not a platform device.
Not true. Many normal devices are interfaced to the processor, but not through an i2c bus. Example: a USB mouse.
[EDIT] In your case, have a look to
drivers/usb/host/ohci-pnx4008.c
, which is a USB host controller platform device (Here the USB host controller is not discoverable, whereas USB devices, which will connect to it, are). It is a platform device registered by the board file (arch/arm/mach-pnx4008/core.c:pnx4008_init
). And within its probe function, it registers its i2c device to the bus withi2c_register_driver
. We can infer that the USB Host controller chipset talks to the CPU through an i2c bus.Why that architecture? Because on one hand, this device can be considered a bare i2c device providing some functionalities to the system. On the other hand, it is a USB Host capable device. It needs to register to the USB stack (
usb_create_hcd
). So probing only i2c will be insufficient. Have a look toDocumentation/i2c/instantiating-devices
.Minimal module code examples
Maybe the difference will also become clearer with some concrete examples.
Platform device example
Code:
Further integration notes at: https://stackoverflow.com/a/44612957/895245
See how:
-M versatilepb
machine description, which represents the SoCcompatible
device tree property which matchesplatform_driver.name
in the driverplatform_driver_register
is the main register interfacePCI non-platform device example
See how:
vendor:device
ID (QEMU_VENDOR_ID, EDU_DEVICE_ID
on example). This is baked into every device, and vendors must ensure uniqueness.device_add edu
anddevice_del edu
as we can in real life. Probing is not automatic, but can be done after boot withecho 1 > /sys/bus/pci/rescan
. See also: Why is the probe method needed in Linux device drivers in addition to init?