Fundamental Design Flaw of the Device Driver Model?
===================================================
Sorry for the misleading subject, its purpose is to draw your attention :-)
The ideas below are preliminary and I hope I'm not making serious mistakes
here.
This question has actually been around in my mind for several months, when
I started to work on some devices with multiple functions. Specifically, a
Power Management IC (PMIC in short in the following text) usually includes
LEDs support (charging, indication...) audio, touch screen, power monitoring,
LDOs, DC-DC bucks, and possibly some others.
The initial two ideas came into my mind were:
1. separate the functions into multiple devices, write a driver for each
of these devices
2. a big all-in-one driver
Pros and Cons
Solution (1) is obviously more attractive: better modularization and
structure, work can be incrementally done, individual patches can go
through each subsystem's git tree, reviewed by dedicated people, and
so on.
One thing I'm not so happy with solution (1) is: you have to create
intermediate devices in order that the dedicated sub-device drivers
to match up. E.g.
==== pmic.c =============================================================
...
pmic_add_subdevs(void)
{
for all sub-devices on this pmic:
pdev = platform_device_alloc(sub-device-name, sub-device-id)
platform_device_add(pdev);
...
}
pmic_probe(struct i2c_client *client)
{
...
pmic_add_subdevs();
...
}
struct i2c_driver pmic_driver = {
.probe = pmic_probe,
...
}
==== pmic.c =============================================================
==== pmic-subdev.c ======================================================
static int sub_device_driver_probe(struct platform_device *sub_device)
{
... ...
}
static struct platform_driver pmic_subdev_driver = {
.name = sub-device-name,
.probe = ...
