ZeroPhone hardware would benefit from having corresponding Linux drivers. Why?
It makes it easier to interface to ZeroPhone hardware - both to users and to existing software
It also makes ZeroPhone compatible with a range of existing software
You can implement more critical features (like undervoltage shutdown) in a way that is less likely to glitch
You can also implement features inside the driver itself - they're going to be faster, more reliable and won't depend on external binaries (like Bash and Python scripts do)
It would also allow for un-tying ZeroPhone from its software - allowing the user to easily avoid using the existing APIs and software (like ZPUI)
Current situation
The MCP23017 chip uses the mcp23x08 Linux driver (working, but it only takes care of GPIOs, not the actual functions attached to them)
The 5V step-up (that controls the USB) is not exposed to the kernel, so it has no idea when the USB port power is turned on or off (usually, a kernel driver is used, for example, Raspberry Pi has one AFAIK)
RGB LED is only available through sysfs GPIO or Python API - not so good (though there's not yet a good API for RGB LEDs, we could use the individual LED API)
However, what will happen when we switch to APA102, which is digitally-controlled and has proper PWM support?
Power management FET is switched on by a script It's working, but not fully, and it's a hack (which is undesirable)
In addition, it doesn't support turning the power off on shutdown
There's charger detection (using a resistor divider). However, it only really is accessible through the Python API so far.
There's a thermistor for sensing overheating of the phone, which is interfaced to ZP through a comparator (Delta version).
GSM modem RST, DTR and RING lines are exposed, but not used
How can we use them with ofono? Do we even need a Linux driver for those?
Charger input has undervoltage detection (Delta version). It could be somehow signalled to the kernel, but as of now there's no software support.
5V output has undervoltage (and, as a result, overcurrent) detection (Delta version). Again, it could be somehow signalled to the kernel (and maybe the USB output could be shut off), but there's no software support yet.
GSM UART can be disabled by the 74HC125 IC on the board. However, there's no software control of that whatsoever yet.
The ATMega328P has the keypad connected to it and it's controlled through I2C. However, there's no Linux driver for it yet - which means that it can't be used from, say, X.
It also has a vibromotor (not yet supported in ATMega firmware). I don't know if Linux has a defined interface for using those, but it would be cool.
There's an ADC, measuring VSYS, it would be great to expose that to the kernel (not yet supported in ATMega firmware)
There's also an user-exposed ADC that should be easily accessible to users - making it accessible through a driver would achieve that goal (not yet supported in ATMega firmware)
There are two user-accessible GPIOs that are accessible through I2C. They could easily be exposed to sysfs. (not yet supported in ATMega firmware)
Those GPIOs both have PWM support (not yet supported in ATMega firmware); I'm wondering if this could be easily interfaced as well.
Problems
How do we implement cross-revision compatibility? Delta revision will have an EEPROM on I2C1, but I'm not sure that's enough.
Specifically, when you compare Delta rev. to Gamma rev., new features are added and pin mapping is changed
ZeroPhone hardware would benefit from having corresponding Linux drivers. Why?
Current situation
mcp23x08Linux driver (working, but it only takes care of GPIOs, not the actual functions attached to them)Problems
Tracking the status
Links