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> 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. Thanks, Guenter
