Re: [RFC 0/5] Add a gpio jack device

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1911 bytes --]

On Tue, May 26, 2015 at 08:43:34PM +0200, Lars-Peter Clausen wrote:
> On 05/25/2015 07:15 PM, Mark Brown wrote:

> >I think it solves the 90% case well enough for simple-card (which is to
> >the main target user here) and the situation with jack detection is
> >already fragmented enough that we're not likely to make things
> >that much worse.  Though now I think about it just taking the gpio out
> >of the device name would help with binding reuse for other users.

> Yea, but 90% of those 90% are already covered by the existing bindings. The

I'm not sure what this thing with "yea" is (I've seen some other people
use it too) but the normal word is "yes"...

> existing simple-card bindings and driver support GPIO based jack detection,
> albeit not as flexible as this. But we don't actually gain that much with

Huh, so they do.  Ugh.

> >Yes, this is the complete solution - and it's not an audio specific
> >thing either, there's a reasonable case to be made for saying that that
> >this should be resolved in extcon rather than in any one consumer
> >subsystem.

> If the bindings are good it doesn't really matter which framework eventually
> picks them up, but in this case the bindings are awfully ASoC specific and
> leak a lot of the shortcomings of the current implementation.

Could you expand on the abstraction problems you see please?  It looks
like a fairly direct mapping of GPIOs to a jack to me (like I say I
don't see having GPIOs directly on the jack object as a problem - having
to create a separate node to put the GPIOs in doesn't seem to solve
anything) and we're not likely to have enough GPIOs to make the usual
problems with lists of values too severe.

The only things that concerned me particularly were the name (which I
did agree on once you mentioned it) and the use of a bitmask to describe
what's being reported but it's hard to think of anything much better
than that.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]