Common Miscdevice, Platform_device, platform_driver in kernel drivers

Recently looking at the driving model, is the more confused, the previous contact is more than a few character drivers, the character-driven framework has a certain understanding. Later, because I want to realize the creation of the device file in the drive, and understand again, the Sysfs file system and the Udev equipment file system inevitably involve the driving model. However, it was found that the driving model had nothing to do with the previous contact character driver.
Like whatThe main content of the previous character driver is to implement the functions in the file_operations structure., then the application device number, register the character device,There's no device-driven model involved .。 In the drive model, Device_driver does not involve the function of device operation, file_operations, etc., only some power management, hot plug related functions. Platform_device is also mainly in the management of resource, so feel the two are not okay, it is also very strange why two sets of things to achieve, and the two can not be matched up.
Later saw some of the kernel driver source, found that many are usedMiscdevice, Platform_device, Platform_driverImplementation, and the process is similar:

1.registering Platform_device During the system initialization phase, mainly adding the resource list of devices corresponding to the deviceSo that the system can manage the resources occupied by the equipment uniformly;
2, realize platform_driver and register, in this part, need to realize the main have platform_driver structure ofProbeAnd alsoRemove, Shutdownand other functions related to hot swap and power management.
3. Then register Platform_driver (Platform_driver_register) in the module initialization function (XX_INIT)

whichacquisition of equipment Resources (Platform_get_resource)Such asio memory, IO port, interrupt number, request (request), physical address to Virtual address mapping (IOREMAP), Misc_device registration (misc_register), clock Acquisition (Clk_get) and enable (Clk_ Enable)Are implemented in the probe function, the probe function is executed after platform_driver registration, or when a new device is added, Platform_device and Platform_driver match (by name). The registration process differs from the character driver that was previously contacted.
For Misc_device, the implementation of the device operation function and the character device are filled with the file_operations structure and then registered in the module initialization function (Misc_register).
For the platform drive model, it seems that Platform_device is responsible for the equipment resources, platform_driver responsible for power management and resource applications, interrupt registration and other device initialization and startup related operations, and then is the device operation method (File_ Operations) Registration (Misc_register or cdev_add), Cdev or Misc_device is responsible for file_operations.

But there are still many questions:
1. Where is the application of the device number, and how is it placed in the devices structure in the drive model?
2, Platform_driver structure and the device_driver structure in which there are probe, remove, shutdown, and so on, why in the outer layer to put the repetition of things, what is the relationship between the two?
3, Misc_register realization in the end and Platform_device_register will call Device_add, so in the device driver model is not two device and device_driver corresponding, and the actual physical equipment is only one?
4, it seems that the driving model is the actual device and drive abstraction, extract their information into the kernel object Kobject, and then according to their relationship between classification, hierarchical management (build a tree), by these objects, by the system Management equipment resources registration application, The release and actual drive (file_operations) registration time (which can be hot-swappable, plug-and-play) and power management (the system can determine the order in which the device is closed according to the device tree, Device->device_driver->shutdown).
So device-driven model, device is only used to set up the plant tree, will eventually be based on the structure of the device_driver in the power management function to achieve a reasonable power switching order?
And the function of hot plug, and device and the matching process of device_driver, and is not related to the plant tree hierarchy relationship?
(The above is the current thinking of not understand the place, the missing place remembered will add again.) Another day to find a teacher to ask, too complicated! ）


===============================================
Recent research on Linux device driver has encountered confusion, please hero come to the idea.
Linux device model: bus_type, device, Device_driver
In the Linux device Driver Model chapter, in the device model, all devices are connected by bus.
To add a device DevA, you must specify the Bus_type domain of its device structure, initialize the other domain, and then call Device_register (&deva) to DevA the device
Registers to the specified bus.
To add the device driver Drivera, you must also specify the Bus_type domain of its device_driver struct, initialize the other domain, and then call Driver_register (&drivera).
Register the driver on the bus.
If the driver Drivera and the device Deva match successfully, that is, the call to the probe function succeeds, the symbolic link between them is established, and the device is bundled with the driver.
In fact, I see the Linux source code is heavily used Platform_device,
struct Platform_device {
const char * name;
U32 ID;
struct device dev;
U32 num_resources;
struct resource * resource;
};
And
struct Platform_driver {
Int (*probe) (struct platform_device *);
Int (*remove) (struct platform_device *);
void (*shutdown) (struct platform_device *);
Int (*suspend) (struct Platform_device *, pm_message_t State);
Int (*suspend_late) (struct Platform_device *, pm_message_t State);
Int (*resume_early) (struct platform_device *);
Int (*resume) (struct platform_device *);
struct Device_driver driver;
};
As can be seen from the structure, Platform_device is a device derived, Platform_driver is device_driver derived
Also add device Platformdeva, when initializing the platform_device structure's dev domain, does not initialize its bus_type domain, but actually adds the device to the Sys\bus\platform\devices directory,
Where you can see this part of the code in the source code.
Also add drive Platformdrva, when initializing the driver domain of the platform_driver struct, does not initialize its bus_type domain, but actually adds the driver to the Sys\bus\platform\drivers directory,
Where you can see this part of the code in the source code.

And also
struct Miscdevice {
int minor;
const char *name;
const struct File_operations *fops;
struct List_head list;
struct device *parent;
struct device *this_device;
};
With the character type device
struct Cdev {
struct Kobject kobj;
struct module *owner;
const struct File_operations *ops;
struct List_head list;
dev_t Dev;
unsigned int count;
};
As can be seen from the structure, Miscdevice is a device derived, which differs from Platform_device:
1. Platform_device information resource of the resources used in the equipment.
2, Miscdevice in the use of the device file_operations.
From the device driver source code:
The first step
static struct Platform_device At91sam9260_adc_device = {
. Name = "AT91_ADC",
. id =-1,
. Dev = {
. Platform_data = &adc_data,
},
. resource = Adc_resources,
. num_resources = Array_size (adc_resources),
};
static struct resource spi0_resources[] = {
[0] = {
. Start = At91sam9260_base_spi0,
. end = At91sam9260_base_spi0 + Sz_16k-1,
. Flags = Ioresource_mem,
},
[1] = {
. Start = At91sam9260_id_spi0,
. end = At91sam9260_id_spi0,
. Flags = IORESOURCE_IRQ,
},
};
Add this device to the system, register the device's resources
Platform_device_register (&at91sam9260_adc_device);


Step Two:
static struct File_operations At91_adc_fops = {
. Owner = This_module,
. IOCTL = At91_adc_ioctl,
. Read = At91_adc_readdata,
. open = At91_adc_open,
. Release = At91_adc_release,
};
static struct Miscdevice At91_adc_dev = {
. minor = Misc_dynamic_minor,
. Name = "ADC",
. FoPs = &at91_adc_fops,
};
To add this device to the system, register the device's usage
Misc_register (&at91_adc_dev);


Step Three:
static struct Platform_driver At91_i2c_driver = {
. Probe = At91_adc_probe,
. remove = __devexit_p (At91_adc_remove),
. Suspend = At91_adc_suspend,
. Resume = At91_adc_resume,
. Driver = {
. Name = "AT91_ADC",
. Owner = This_module,
},
};
Register this device driver
Platform_driver_register (&at91_i2c_driver);

These three structure relationships:
(base class)
Kobject--------------------
/     \                      \
/       \                      \
Device Cdev Driver
/\ (Device-driven operation method) \
/       \                              \
Miscdevice Platform_device Platform_driver
(Device-driven operation method)                   (Resource of the device) (Device-driven)
My question:
1, when the letter-type device driver, I generally only use the CDEV structure, using this method, as if the device can not be displayed in the SYSFS.
2. Whether the Miscdevice supports character devices and block devices, if it uses it how to identify block devices or character devices.
3, Miscdevice, Platform_device, Platform_driver can be used as a common device-driven method, registered equipment resources by Platform_device
Platform_driver Register device driver, Miscdevice registered device use method.

===============================================
The above is an online search of a post, and my questions are somewhat similar, and in some places I do not understand.
This post reproduced a lot, but few people reply, the reply is also no substantive content.
But this classmate tidy part still is relatively clear, worth to see!

For your safety, please only open URLs with reliable sources

Common Miscdevice, Platform_device, platform_driver in kernel drivers