Sorry for the delay. I had network problems for the last few days. Seems that my ISP's having a really bad year :-(
Balaji Rao wrote: > What are the other parts that we need to seperate out ? The more, the better :-) There is actually very little in this device that is shared - only I2C communication, interrupts, and global state. The worst that could happen if you're too enthustiastic about separating subsystems is that you might realize that some subsystems are too tightly connected for separation. That in turn may reveal unnecessary connections (I've listed a few below), so it's a good way to spot potential problems. > Do we need to > provide sysfs interfaces for , say led control and charger ? If you mean to use the device class APIs which in turn provide the sysfs interfaces, then yes. You'll notice that we have a few ugly spots in the driver, where it makes assumptions about how the chip is used, e.g., - that the LED driver drives a backlight (with a lot of suspend/resume handling) - that ADCIN1 is connected to USB ID pin - that we can also output USB power - generate various responses depending on how long the power button is held The backlight handling is a bit of a trouble spot, because user space and kernel sometimes have divergent ideas about what the state should be. At least moving all the backlight code into a separate file would help to make it clearer, and maybe we can pare it down later. ADC access is currently messy. I think it would be a lot clearer if each request included a callback function. E.g., charger detection could then live somewhere in platform-specific code and use the ADC without the PMU driver having to know anything else about it. Also interpret_charger_type_from_adc would be in the platform-specific code. configure_pmu_for_charger should go into platform-specific code as well - it gets the modes right, but has way too much platform knowledge about the 1A charger. I wouldn't mind seeing the fancy POWER/ONKEY button handling go entirely. A question for our user space folks: do you really need that, or could a little daemon or library do the job as well ? These are quite drastic changes. The PCF50633 driver has grown into being the "GTA02 schematics sheet 3" driver over time, so there's now quite a bit to untangle. Since this will affect various interfaces visible to user space, please make sure to document when sysfs files change name, when their semantics change, etc., so that our user space developers have plenty of time to prepare for a smooth migration. - Werner
