> > > > > + if (!st->chip_info) > > > + st->chip_info = (const struct chip_info *)spi_get_device_id(spi)->driver_data; > > > + > > > + indio_dev->name = st->chip_info->name; > > > + indio_dev->modes = INDIO_DIRECT_MODE; > > > + indio_dev->channels = max11205_channels; > > > + indio_dev->num_channels = 1; > > > + indio_dev->info = &max11205_iio_info; > > > + > > > + st->vref = devm_regulator_get(&spi->dev, "vref"); > > > > devm_regulator_get_enable() ? > I found the patches which implement devm_regulator_get_enable. > However, I need to get the voltage of the regulator using > regulator_get_voltage(struct regulator *regulator) and if I use > devm_regulator_get_enable I do not have access to the regulator > pointer. What should I do in this case? Is there an API which works > like devm_regulator_get_enable but also gives access to the > regulator's pointer? Thank you for you review! Ah. You've run into a fun long running 'discussion'. There was great resistance to adding devm_regulator_get_enable() because it was felt that it was too easy to get the handling wrong and end up with underflowing reference counters etc. So the 'solution' was to make it less useful than it would otherwise have been by making sure it could not be combined with other accesses to the regulator. Upshot is you are correct that it cannot be applied in this case. Also relevant is that the patch in question is going through the regulator tree so won't be generally available to the rest of the kernel until next cycle. As such we'd have had to make such a change as a follow up patch if it were possible. Jonathan p.s. Wrap your replies at 80 chars as well as the code. Kernel developers have an annoying habit of reading their email in one small window even when they have very large monitors :) Also, where sensible crop unnecessary parts of the email to only include the bit you are responding to. Saves on lots of scrolling.. > Kind Regards, Ramona > Bolboaca
