On Tue, Dec 29, 2020 at 04:33:09PM +0100, Hans de Goede wrote:
On 12/29/20 4:08 PM, Mark Brown wrote:
No, that's not the case. extcon is a port of an Android custom API that looks very similar to what ended up in mainline, it was also a combination of sysfs and uevents but a bit less generic. It mainly existed to provide information to userspace about what was plugged into the various ports on devices, things like headphone jacks and the pre-USB C multifunction connectors you used to get on phones.
Interesting, I have close to 0 experience with Android userspace (something which I would like to change one of these days). But I have encountered a bunch of in-kernel use of extcon on Intel's Android X86 port for Bay and Cherry Trail devices (which I've ported to the mainline) where extcon was e.g. used with a generic extcon-gpio like driver monitoring the ID pin and then used by the USB code to detect (through monitoring the extcon) if the USB port was in host or device/gadget mode.
So it seems that extcon has many different uses by different people...
It was extended as part of getting it merged into mainline, there was some thought about what people could need to do with jacks at the time.
The whole purpose of creating sound/core/jack.c is to abstract away the userspace interfaces from the drivers, most audio devices shouldn't be working with extcon directly just as they shouldn't be creating input devices or ALSA controls directly. The missing bit there is to add extcon into jack.c.
So what you are suggesting is making sound/core/jack.c register the extcon device and then have arizona-extcon.c talk to sound/core/jack.c and no longer do any extcon stuff itself.
Yes.
So we already export 2 userspace-APIs for this IMHO adding a 3th one is not really a good idea unless it offers significant benifits which I don't really see. The input_dev API is simple enough to use that extcon does not really offer any significant benefits.
Quite apart from anything else the reason the switch API was created was AIUI that the Android people couldn't figure out how to do jack detection on Linux - the current APIs are not terribly discoverable. There's also issues with extensibility and applicability to non-audio use csaes with the existing APIs.
My current solution to have the machine-driver register a jack and then share that with the extcon-arizona.c code still seems like the best/simplest solution to me here.
Bodging it at the driver level gets in the way of improving the generic code.
Unless we go with your plan to make sound/core/jack.c export an extcon device for all sound-devs registering a jack, and then move extcon-arizona.c over to using sound/core/jack.c without it doing any extcon stuff itself. But as discussed I'm really not a fan of exporting a 3th uAPI for jack-detection for all sound-cards with jack-detect capability.
That *is* the plan, though clearly it's not exactly been backed by work. extcon already exists and supports reporting jacks.
I do think pushing things over to extcon is a useful goal, the existing interfaces have fairly clear issues that it does actually address.
I don't really see any "fairly clear issues" with the input-device uAPI, I agree that the ALSA controls can be hard to use, but that is not the case for the input-device uAPI (*). What are your objections against using the input-device uAPI ?
Like I say it's discoverabiity and extensibility in a range of axes. Other examples of thing that'd be good to have that we don't really have with the input API are things like saying things like "the red jack on the front panel".