On Wed, Jul 30, 2014 at 6:12 PM, Rojhalat Ibrahim <[email protected]> wrote: > On Wednesday 09 July 2014 12:17:13 Linus Walleij wrote: >> On Mon, Jul 7, 2014 at 6:12 PM, Rojhalat Ibrahim <[email protected]> wrote: >> > On Monday 07 July 2014 17:23:34 Linus Walleij wrote: >> >> On Mon, Jun 16, 2014 at 3:51 PM, Rojhalat Ibrahim <[email protected]> >> >> wrote: >> >> >> >> > Introduce new functions gpiod_set_array & gpiod_set_raw_array to the >> >> > consumer >> >> > interface which allow setting multiple outputs with just one function >> >> > call. >> >> > Also add an optional set_multiple function to the driver interface. >> >> > Without an >> >> > implementation of that function in the chip driver outputs are set >> >> > sequentially. >> >> >> >> Yes this looks good. >> >> >> >> Except for one thing I mentioned quite early I think: >> >> >> >> no users! >> > >> > I'm pretty sure you did _not_ mention this before. >> >> I'm not referring to your patch set specifically. The idea of array handling >> has been proposed something like three times, I cannot tell these discussion >> threads apart in my head. >> >> But it's a reasonable request don't you think? >> > > The request might be reasonable. > > But after taking a look at the i2c-gpio and spi-gpio drivers, I do not think > they > would benefit from the new feature. In both cases there are only two GPIO > lines. > And they have to be set separately at least half of the time. > > I could not find any other in-kernel driver that might benefit from the new > feature, either. > > So I guess you are right: There are no users for this. > > For my use-case the feature is very beneficial, but of course only in > combination > with an out-of-kernel driver module for configuring the FPGA on my custom > board. > I posted the patch because I expected similar use-cases to exist for other > people > out there. If you think that's not the case, there is nothing I can do about > it.
Personally I would be sad if this series is not merged. It is a well-written solution to a problem that comes regularly. It is understandable that the upstream kernel API serves, well, upstream users - but we also need to recognize that most of the drivers using lots of GPIOs do not get merged upstream because using GPIOs that way is often considered a hack. I'd be surprised if at least *one* such driver was not in mainline though. Had a quick look but could not find anything that would be an obvious candidate to use these new functions. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
