On Fri, Mar 30, 2012 at 10:29 AM, Erik Gilling [off-list ref] wrote:

On Fri, Mar 30, 2012 at 3:07 AM, Mark Brown
[off-list ref] wrote:

quoted

On Thu, Mar 29, 2012 at 03:27:01PM -0700, Erik Gilling wrote:

quoted

On Fri, Mar 9, 2012 at 4:41 AM, Mark Brown

quoted

quoted

This seems somewhat sad - if ANDROID is turned on the standard ABI
vanishes. ?It'd be much nicer to do this with a symlink (or with
symlinks within the android directory if the driver core doesn't support
that). ?That way userspace code can be written to the new ABI and will
work on Android systems without ifdefery.

quoted

This won't work if userspace code is receiving uevents through netlink
and comparing based on the device name which it does in android. ?Why

That's not really the point here - the point is that the new ABI
vanishes as soon as you turn on the legacy Android ABI. ?You're right
that the particular fix I suggested has issues but the overall problem
exists and should be dealt with more sensibly.

I'm also not in favor of having functionality conditionally compiled
based on CONFIG_ANDROID. ?If fact, going through the patch stack
there's much more that changes the ABI from the switch driver than
just the name. ?Android asumes that there is a single "switch" for
each logical entity (called cable types in extcon) each with a binary
state (0,1). ?Here things have changed to have a single extcon
instance that can have a bitmask of states which are sent as strings
in the uevent.

In addition to all this added complexity, the fact that you now have
to white-list the possible "cable types" is also undesirable. If I
wanted to expose a new cable type, I now have to modify the extcon.h
file and the extcon.c file and I don't see what that white-list buys
me. The class device itself should not care for which cable types can
be registered, nor how they relate to each other. Let the client
drivers decide, just enforce uniqueness.

--Dima

As it stands, this patch does not solve the cases where we use switch
today and we'll probably continue to carry the switch driver in the
common android tree. ?If, instead, we got rid of the idea of multiple
states and mutual exclusivity and relied on the driver that uses
extcon to have multiple instances for each logical entity and deal
with mutual exclusion itself, we'd have a driver that would be pretty
easy to support in android.

-Erik