Recommended blog posts:Linux Kernel "problem Gate"-learning issues and experience highlights
Recommended download:Methodology of essence edition of "Cultivation of Linux kernel"
In addition to the device model, there are three things that are indispensable for driver developers: the first is the protocol or standard spec, that is, the specification, such as the USB protocol specification; the second is the hardware datasheet, which is the manual of the hardware to be supported by your driver. The third is the source code similar to the driver in the kernel. For example, if you want to write a touch screen driver, you can refer to some touch screen drivers in the kernel.
SPEC, datasheet, and kernel source code are common for every developer, but they are common, therefore, many people are classified as neglected groups. In the process of development-driven development, the first thought of problems may be "how to solve the problem?" and "how nice it would be to have a cool person next to it", because the cool people are rare, so I know the value of cool people, and because spec, datasheet, and kernel source code are at your fingertips, I often cannot understand their importance in solving problems.
Of course, I do not devalue the value of the ox. I advocate that it is not good to rely on the oX. If you are lucky to have such scarce resources as the Ox, you must make good use of them and take a lot of detours, saving a lot of time for exploration. Most people are still not lucky in their lives. Therefore, it is better to rely on yourself and use your resources to find a solution to the problem.
The key to these three seemingly common things is to make good use of them instead of having them. Let's talk about USB, how the USB driver communicates with the USB device, how it communicates, and what problems occur during the communication process are described in the USB spec, only Datasheet of the device knows how many types of configurations are supported by your USB device and how many endpoints are included. The spec of the Protocol and the datasheet of the device are the best references. Most of the problems encountered during driver development and debugging can be found in some of their corners. The driver source code of similar devices in the kernel is the best template. For many hardware devices, you can find the driver code of the same device in the kernel for reference implementation, you can even copy or share most of the code and only make local modifications, such as the touch screen drivers in the drivers/input/touchscreen directory, many codes between them are similar or even the same.
If you want to not only write drivers, but also read the source code of certain bus and devices in the kernel and study their implementation mechanisms, the spec of the Protocol is even more important, they are everywhere in the code. You need to have a general understanding of the Protocol Specification before reading the code. In terms of image, spec is the theoretical basis, kernel code is the specific implementation, and the theory is understood. It is almost the same as reading the code.