Hi,
On 12/29/20 2:06 PM, Charles Keepax wrote:
On Mon, Dec 28, 2020 at 04:28:07PM +0000, Mark Brown wrote:
On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
And more in general AFAIK extcon is sort of deprecated and it is not advised to use it for new code. I would esp. not expect it to be used for new jack-detection code since we already have standard uAPI support for that through sound/core/jack.c .
Has Android been fixed to use the ALSA/input layer interfaces? That's why that code is there, long term the goal was to have ALSA generate extcon events too so userspace could fall over to using that. The basic thing at the time was that nobody liked any of the existing interfaces (the input layer thing is a total bodge stemming from it having been easy to hack in a key for GPIO detection and using ALSA controls means having to link against alsa-lib which is an awful faff for system level UI stuff) and there were three separate userspace interfaces used by different software stacks which needed to be joined together, extcon was felt to be a bit more designed and is a superset so that was the direction we were heading in.
Android has been updated to have the option to catch input events for jack detection now.
I have always been slightly confused between extcon and the ALSA jack reporting and have been unsure as to what is the longer term plan here. I vaguely thought there was a gentle plan to move to extcon, it is interesting to see Hans basically saying the opposite that extcon is intended to be paritially deprecated. I assume you just mean with respect to audio jacks, not other connector types?
No I mean that afaik extcon is being deprecated in general. Extcon is mostly meant for kernel internal use, to allow things like charger-type-detection done by e.g. a fsa micro-usb mux or a Type-C PD controller to be hooked up to the actual charger chip and set the input-current-limit based on this.
But there is no clean way to express these relation-ships in extcon terms in devicetree. At least for new device with Type-C functionality this is all being moved to OF graph bindings combined with using the power_supply class to provide info like negotiated voltage and current to the charger-IC.
Note this is mostly my 2 cents / my impression about where extcon is heading. I have actually tried to use extcon for Type-C stuff and this was frowned upon by both the devicetree bindings people and the USB Type-C code controller people.
Also despite its age, the extcon code is still not really in good shape. E.g. a driver can do extcon_get_extcon_dev, but that does not return a device-reference, that just does a lookup and returns the requested extcon-device, but there are 0 guarantees that the extcon device will not go away and dereferencing the returned pointer after doing a rmmod of the extcon-driver will result in a nasty crash.
So all this suggests to me that extcon should not be used for new code / projects.
I would agree with Mark though that if extcon exists for external connectors it seems odd that audio jacks would have their own special way rather than just using the connector stuff.
Well as I said above in me experience the extcon code is (was) mostly meant for kernel internal use. The sysfs API is more of a debugging tool then anything else (IMHO).
Also the kernel has support for a lot of sound devices, including many with jack-detection support. Yet a grep for EXTCON_JACK_HEADPHONE over the entire mainline kernel tree shows that only extcon-arizona.c is using it. So given that we have dozens of drivers providing jack functionality through the sound/core/jack.c core and only 1 driver using the extcon interface I believe that the ship on how to export this to userspace has long sailed, since most userspace code will clearly expect the sound/core/jack.c way of doing things to be used.
Arguably we should/could maybe even drop the extcon part of extcon-arizona.c but I did not do that as I did not want to regress existing userspace code which may depend on this (on specific embedded/android devices).
Regards,
Hans