On Sun, Apr 24, 2022 at 06:49:10PM +0200, Guenter Roeck wrote: > On Wed, Apr 06, 2022 at 02:43:20PM +0200, Mårten Lindahl wrote: > > Several of the manuals for devices supported by this driver describes > > the need for a minimum wait time before the chip is ready to receive > > next command. > > > > This wait time is already implemented in the driver as a ltc_wait_ready > > function with a driver defined wait time of 100 ms, and is considered > > for specific devices before reading/writing data on the pmbus. > > > > But this driver uses the default pmbus_regulator_ops for the enable/ > > disable/is_enabled functions. By using these functions it bypasses the > > wait time recommendations for several of the devices managed by the > > driver (ltc3880/ltc3882/ltc3883/ltc3884/ltc3886/ltc3887/ltc3889/ltm4664/ > > ltm4675/ltm4676/ltm4677/ltm4678/ltm4680/ltm4686/ltm4700/ltc7880). > > > > Lets add driver specific regulator enable/disable/is_enabled ops which > > takes the wait time into consideration for the specified devices, by > > overriding pmbus_read_byte_data with internal ltc_read_byte_data. > > > > Signed-off-by: Mårten Lindahl <marten.lindahl@xxxxxxxx> Hi Guenter! Thanks for your comments. > > This patch solves the wrong problem. The real problem is that the > regulator code in the PMBus core writes direcetly into the chip > and doesn't use the driver functions to do it if needed, and that > the PMBus core does not support a chip-specific write_byte_data function > (because so far it wasn't needed). That needs to get fixed, and then > we won't need chip specific regulator functions. Good point. I will add support for driver callback functions in pmbus core and remove the ltc2978 enable/disable/is_enabled functions. Kind regards Mårten > > Thanks, > Guenter
