Hi Tim, AFAIK we don't have a PMIC with battery regulator in the mainline yet. So you don't have a reference to base on it.
You don't need to create a single file with all functions on it, you can create separated file for each specific function. This is how MC13892 is implemented on Linux (please don't look the source code, it is GPL), this chip is a PMIC with regulator, battery charger and LEDs control. I think for ACT8945A should be included a regulator at drivers/power/supply/ and will implement the functions from <nuttx/power/regulator.h> and will register itself with regulator_register(). Also you will include the battery charger logic at driver/power/battery/ as a separated act8945_batchr.c to avoid mixing things and will export itself as /dev/bat0. But you will need to use spinlock when accessing the I2C bus inside these drivers to avoid both drivers trying to use it while a transfer is in progress. BR, Alan On 9/6/22, TimH <t...@jti.uk.com.invalid> wrote: > I'm writing a driver for the Quorvo ACT8945A device. This is a combined > 7-output programmable regulator AND Li-ion battery charger, all in one. > > > > I see there are existing "regulator.h" and "battery_charger.h" driver > templates. > > > > Would my best approach to be to create a driver using a new (e.g.) > "battery_charger_regulator.h" template combining that existing > functionality > or is there another, preferred, approach? > > > > Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or > something else? > > > > Then, once that is decided, I seem to have a mental block when it comes to > device initialisation vs registering. > > > > In my mind, registering should just create the /dev/xxxx entry and > initialise the relevant structs, but not touch the device itself? But some > drivers do go on to actually set up the device, whereas I think that should > be a separate "init" function called independently of the "register" > function, or a specific ioctl perhaps? What is the best practice here? > > > > Thanks, > > > > Tim. > > > >