On Fri, May 03, 2019 at 10:29:42AM +0200, Jorge Ramirez wrote: > On 5/3/19 08:26, Mark Brown wrote: > > On Thu, May 02, 2019 at 01:30:48PM +0200, Jorge Ramirez wrote: > > It seems a bit of a jump to add a new driver - it's just another > > descriptor and ops structure isn't it? Though as ever with the Qualcomm > > stuff this driver is pretty baroque which doesn't entirely help though I > > think it's just another regulator type which there's already some > > handling for. > So how do we move this forward? > To sum up his regulator needs to be able to bypass accesses to > SPMI_COMMON_REG_VOLTAGE_RANGE and provide the range in some other way > hence the change below > I can't find a simpler solution than this since the function does now > what is supposed to do for all the regulator types supported in the driver The assumption that you need to have this regulator use functions that use and provide ranges is the very thing I'm trying to get you to change. It looks like these regulators just need their own set_voltage_sel() and get_voltage_sel() then they can use the standard linear range mapping functions (and pobably the set_voltage_time_sel() needs fixing anyway for all the other regulators). There's already some conditional code in the probe function for handling different operations for the over current protection and SAW stuff, this looks like it should fit in reasonably well. Usually this would be even easier as probe functions are just data driven but for some reason more than usual of this driver's data initializaiton is done dynamically.
Attachment:
signature.asc
Description: PGP signature
