On Tue, Jun 02, 2020 at 05:40:45PM +0530, Sumit Semwal wrote: > On Tue, 2 Jun 2020 at 17:02, Mark Brown wrote: > > On Tue, Jun 02, 2020 at 03:39:23PM +0530, Sumit Semwal wrote: > > This should be a get_status() callback... > From my (limited) understanding of downstream code, it seemed like for > this set of regulators, the 'enabled' check is done via the > 'REG_LABIBB_STATUS1 reg; for some reason, not via the same enable_reg > / enable_mask ones. That's why I used it as is_enabled() callback. > I will try and check with the QC folks to clarify this point about > their hardware. The way this is functioning at the minute the downstream code is just buggy. > > ...is_enabled() should just be regulator_is_enabled_regmap() and these > > functions should just be removed entirely, you can use the regmap > > operations directly as the ops without the wrapper. > The 2 wrappers are a precursor to the next patch, where we keep track > of regulator's enable status to check during SC handling. Add the functions when they're useful, not before. TBH if the register is write only you're probably better off adding a register cache. > > > + match = of_match_device(qcom_labibb_match, &pdev->dev); > > > + if (!match) > > > + return -ENODEV; > > > + > > > + for (reg_data = match->data; reg_data->name; reg_data++) { > > > + child = of_get_child_by_name(pdev->dev.of_node, reg_data->name); > > > + > > > + if (WARN_ON(child == NULL)) > > > + return -EINVAL; > > > > This feels like the DT bindings are confused - why do we need to search > > like this? > The WARN_ON? This was suggested by Bjorn to catch the case where the > DT binding for a PMIC instantiates only one of the regulators. No, this whole loop - why this whole match and get child stuff?