On Mon, Oct 10, 2011 at 09:49:38PM +0530, Rajendra Nayak wrote: > Device nodes in DT can associate themselves with one or more > regulators/supply by providing a list of phandles (to regulator nodes) > and corresponding supply names. Mostly looks good. > +/** > + * of_get_regulator - get a regulator device node based on supply name > + * @dev: Device pointer for the consumer (of regulator) device > + * @supply: regulator supply name > + * > + * Extract the regulator device node corresponding to the supply name. > + * retruns the device node corresponding to the regulator if found, else > + * returns NULL. > + */ > +struct device_node *of_get_regulator(struct device *dev, const char *supply) > +{ Should be static. > @@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device *dev, const char *id, > goto found; > } > } > + if (!dev) > + list_for_each_entry(rdev, ®ulator_list, list) > + if (strcmp(rdev_get_name(rdev), id)) > + goto found; > This looks really strange, we didn't remove any old lookup code and the DT lookup jumps to found by iself so why are we adding code here? > + if (supply) { > + struct regulator_dev *r; > + struct device_node *node; > + > + /* first do a dt based lookup */ > + if (dev) { > + node = of_get_regulator(dev, supply); > + if (node) > + list_for_each_entry(r, ®ulator_list, list) > + if (node == r->dev.parent->of_node) > + goto found; > } > > - if (!found) { > - dev_err(dev, "Failed to find supply %s\n", > - init_data->supply_regulator); > - ret = -ENODEV; > - goto scrub; > - } > + /* next try doing it non-dt way */ > + list_for_each_entry(r, ®ulator_list, list) > + if (strcmp(rdev_get_name(r), supply) == 0) > + goto found; > > + dev_err(dev, "Failed to find supply %s\n", supply); > + ret = -ENODEV; > + goto scrub; > + > +found: This is all getting *really* complicated and illegible. I'm not sure what the best way to structure is but erroring out early looks useful. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html