On Wed, Nov 09, 2022 at 01:25:06PM +0200, Andy Shevchenko wrote: > On Tue, Nov 08, 2022 at 04:26:50PM -0800, Dmitry Torokhov wrote: > > Ensure that all paths to obtain/look up GPIOD from generic > > consumer-visible APIs go through the new gpiod_find_and_request() > > helper, so that we can easily extend it with support for new firmware > > mechanisms. > > > > The only exception is OF-specific [devm_]gpiod_get_from_of_node() API > > that is still being used by a couple of drivers and will be removed as > > soon as patches converting them to use generic fwnode/device APIs are > > accepted. > > ... > > > +static struct gpio_desc *gpiod_find_by_fwnode(struct fwnode_handle *fwnode, > > + struct device *consumer, > > + const char *con_id, > > + unsigned int idx, > > + enum gpiod_flags *flags, > > + unsigned long *lookupflags) > > { > > - unsigned long lflags = GPIO_LOOKUP_FLAGS_DEFAULT; > > > - struct gpio_desc *desc = ERR_PTR(-ENODEV); > > Not sure why this is needed. Now I see that else branch has been changed, > but looking closer to it, we can drop it completely, while leaving this > line untouched, correct? Yes. I believe removing an initializer and doing a series of if/else if/else was discussed and [soft] agreed-on in the previous review cycle, but I can change it back. I think we still need to have it return -ENOENT and not -ENODEV/-EINVAL so that we can fall back to GPIO lookup tables when dealing with an unsupported node type. > > > - int ret; > > + struct gpio_desc *desc; > > > > + dev_dbg(consumer, "GPIO lookup for consumer %s in node '%pfw'\n", > > + con_id, fwnode); > > + > > + /* Using device tree? */ > > if (is_of_node(fwnode)) { > > - desc = gpiod_get_from_of_node(to_of_node(fwnode), > > - propname, index, > > - dflags, > > - label); > > - return desc; > > + dev_dbg(consumer, "using device tree for GPIO lookup\n"); > > + desc = of_find_gpio(to_of_node(fwnode), > > + con_id, idx, lookupflags); > > At least con_id can be placed on the previous line. OK, I made it all 1 line. > > > } else if (is_acpi_node(fwnode)) { > > - desc = acpi_node_get_gpiod(fwnode, propname, index, > > - &lflags, &dflags); > > - if (IS_ERR(desc)) > > - return desc; > > + dev_dbg(consumer, "using ACPI for GPIO lookup\n"); > > + desc = acpi_find_gpio(fwnode, con_id, idx, flags, lookupflags); > > } else { > > - return ERR_PTR(-EINVAL); > > + desc = ERR_PTR(-ENOENT); > > } > > > > - /* Currently only ACPI takes this path */ > > + return desc; > > +} > > ... > > > + struct gpio_desc *desc = ERR_PTR(-ENOENT); > > + unsigned long lookupflags; > > + int ret; > > > + if (!IS_ERR_OR_NULL(fwnode)) > > I think this is superfluous check. > > Now in the form of this series, you have only a single dev_dbg() that tries to > dereference it. Do we really need to have it there, since every branch has its > own dev_dbg() anyway? As I mentioned, I like to keep this check to show the reader that we should only descend into gpiod_find_by_fwnode() if we have a valid fwnode. It is less about code generation and more about the intent. I did change the logging to remove extra dev_dbg(). We will lose message when dealing with unsupported node type, but that should not really happen in practice. > > > + desc = gpiod_find_by_fwnode(fwnode, consumer, con_id, idx, > > + &flags, &lookupflags); > > > + > > This blank line can be dropped after addressing above. > > > + if (gpiod_not_found(desc) && platform_lookup_allowed) { > > + /* > > + * Either we are not using DT or ACPI, or their lookup did not > > + * return a result. In that case, use platform lookup as a > > + * fallback. > > + */ > > + dev_dbg(consumer, "using lookup tables for GPIO lookup\n"); > > + desc = gpiod_find(consumer, con_id, idx, &lookupflags); > > + } > > + > > + if (IS_ERR(desc)) { > > + dev_dbg(consumer, "No GPIO consumer %s found\n", con_id); > > + return desc; > > + } > > ... > > > + return gpiod_find_and_request(NULL, fwnode, con_id, index, flags, label, > > + false); > > One line? OK :) > > ... > > > + return gpiod_find_and_request(dev, fwnode, con_id, idx, flags, label, > > + true); > > One line? OK. Thanks, -- Dmitry