2015-07-27 17:51 GMT+08:00 Linus Walleij <linus.walleij@xxxxxxxxxx>: > On Thu, Jul 16, 2015 at 3:08 PM, Jun Nie <jun.nie@xxxxxxxxxx> wrote: >> 2015-07-16 16:17 GMT+08:00 Linus Walleij <linus.walleij@xxxxxxxxxx>: > >>>> + if (of_property_read_bool(dev->of_node, "gpio-ranges")) >>>> + chip->uses_pinctrl = true; >>> >>> I see this follows the PL061 pattern, maybe we should start doing this >>> in the gpiolib core. >> >> A structure with all functions and flags can be feed to a new function >> that calls gpiochip_add(). We can abstract logic of struct gpio_chip >> members value assignment. For example, a struct gpio_chip with these >> members assigned at compiling stage can be copied directly to >> instantiation memory space and call gpiochip_add(). We can do this in >> driver too. > > Hm anything that will result in a lot of code lines saved in drivers > is by definition good. This could be a good start. Above solution only save runtime CPU cycle with a memory copy because structure with member assigned in compile time also takes code lines. We can wrap gpiochip_add into new function gpiochip_add_arg() and feed below info to it and assign the value in the common code. It is make the function argument list too long. Any better idea? Or you think it is OK, then I can draft a patch for review. gpio_chip members: direction_input, direction_output, get, set, request, free, ngpio, label, dev. Jun > >> For interrupt stuff, it is hard to abstract because argument vary much >> from driver to driver and different functions are called in different >> drivers. A structure can also serve more or less to abstract function >> calls, but not much. > > Yeah I really tried my best with gpiolib_irqchip_add() and managed > to cut down on all the simple IRQ drivers. Don't think we get > any further with these. > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html