[alsa-devel] [PATCH 2/4] ASoC: s3c64xx/smartq: use dynamic registration
broonie at kernel.org
Mon Jul 21 03:04:12 PDT 2014
On Mon, Jul 21, 2014 at 12:36:43PM +0900, Alexandre Courbot wrote:
> On Thu, Jul 17, 2014 at 8:05 PM, Mark Brown <broonie at kernel.org> wrote:
> > For set and get, sure - but it's still useful to be able to do bulk
> > requests for GPIOs especially since that's the only bit of the interface
> > that requires error handling.
> I foresee many problems if people start using gpiod_array_get() as a
> way to spare a few lines of error-checking code. First all the GPIOs
> would end into an array instead of members with meaningful names -
> unless they are moved later on, but doing so would add extra code and
> somewhat kill the purpose. It also becomes more difficult to maintain
> as you are dealing with array indexes to update all over the code.
You just need a few defines for the names, it's not a big deal.
> Finally, it will make it more difficult to use gpiod_array_*() the way
> it is intended to be used, as you would have to discriminate between
> GPIOs of the same function and the rest by yourself.
Yes, you probably shouldn't mix and match here but that's fine.
> Also, if such a convenience function is legitimate for GPIO, shouldn't
> it also apply to other sub-systems? E.g. regulator_array_get()?
It's certainly a totally reasonable and expected way of using
> Maybe I am missing your point, but I still think some error-handling
> code really doesn't hurt here, and the few drivers that would actually
> benefit from a more automated GPIO request error handling can easily
> implement it themselves. Let's keep gpiod_array_*() single-purposed
> and to the point.
I'm not sure I see the massive complication TBH - it's not so much about
complexity as it is about reducing the amount of boilerplate that people
need to get right.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the linux-arm-kernel