From: Hans de Goede <hdegoede@redhat.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>,
Mark Brown <broonie@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Cezary Rojewski <cezary.rojewski@intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Jie Yang <yang.jie@linux.intel.com>,
patches@opensource.cirrus.com, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org
Subject: Re: [PATCH 01/14] mfd: arizona: Add jack pointer to struct arizona
Date: Tue, 29 Dec 2020 14:57:38 +0100 [thread overview]
Message-ID: <19c2d056-4f71-2c4c-c243-cdcc0115876c@redhat.com> (raw)
In-Reply-To: <20201229130657.GN9673@ediswmail.ad.cirrus.com>
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
next prev parent reply other threads:[~2020-12-29 13:59 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-27 21:12 [PATCH 00/14] MFD/extcon/ASoC: Add support for Intel Bay Trail boards with WM5102 codec Hans de Goede
2020-12-27 21:12 ` [PATCH 01/14] mfd: arizona: Add jack pointer to struct arizona Hans de Goede
2020-12-28 12:21 ` Mark Brown
2020-12-28 13:16 ` Hans de Goede
2020-12-28 16:28 ` Mark Brown
2020-12-29 13:06 ` Charles Keepax
2020-12-29 13:57 ` Hans de Goede [this message]
2020-12-29 15:06 ` Charles Keepax
2020-12-29 15:15 ` Mark Brown
2020-12-29 15:40 ` Hans de Goede
2020-12-29 16:51 ` Richard Fitzgerald
2020-12-30 11:04 ` Hans de Goede
2020-12-30 11:23 ` Richard Fitzgerald
2020-12-30 12:01 ` Hans de Goede
2020-12-30 13:16 ` Mark Brown
2020-12-29 16:43 ` Richard Fitzgerald
2020-12-29 15:08 ` Mark Brown
2020-12-29 15:33 ` Hans de Goede
2020-12-30 13:38 ` Mark Brown
2021-01-01 13:24 ` Hans de Goede
2020-12-27 21:12 ` [PATCH 02/14] mfd: arizona: Add MODULE_SOFTDEP("pre: arizona_ldo1") Hans de Goede
2020-12-29 11:40 ` Charles Keepax
2020-12-27 21:12 ` [PATCH 03/14] mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI Hans de Goede
2020-12-28 14:14 ` Andy Shevchenko
2021-01-16 14:46 ` Hans de Goede
2020-12-27 21:12 ` [PATCH 04/14] mfd: arizona: Allow building arizona MFD-core as module Hans de Goede
2020-12-29 12:00 ` Charles Keepax
2021-01-11 19:12 ` Hans de Goede
2020-12-27 21:12 ` [PATCH 05/14] extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged Hans de Goede
2020-12-27 21:12 ` [PATCH 06/14] extcon: arizona: Fix various races on driver unbind Hans de Goede
2020-12-29 12:10 ` Charles Keepax
2020-12-27 21:12 ` [PATCH 07/14] extcon: arizona: Fix modalias Hans de Goede
2020-12-29 12:10 ` Charles Keepax
2020-12-27 21:12 ` [PATCH 08/14] extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call Hans de Goede
2020-12-29 12:12 ` Charles Keepax
2020-12-27 21:12 ` [PATCH 09/14] extcon: arizona: Add arizona_set_extcon_state() helper Hans de Goede
2020-12-29 12:57 ` Charles Keepax
2020-12-27 21:12 ` [PATCH 10/14] extcon: arizona: Also report jack state through snd_soc_jack_report() Hans de Goede
2020-12-28 14:16 ` Andy Shevchenko
2020-12-27 21:12 ` [PATCH 11/14] extcon: arizona: Use ASoC jack input-device when available Hans de Goede
2020-12-27 21:12 ` [PATCH 12/14] ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() Hans de Goede
2021-01-11 17:52 ` Pierre-Louis Bossart
2020-12-27 21:12 ` [PATCH 13/14] ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102 Hans de Goede
2020-12-29 13:58 ` Charles Keepax
2021-01-11 17:54 ` Pierre-Louis Bossart
2021-01-16 16:49 ` Hans de Goede
2020-12-27 21:12 ` [PATCH 14/14] ASoC: Intel: bytcr_wm5102: Add jack detect support Hans de Goede
2020-12-28 14:19 ` [PATCH 00/14] MFD/extcon/ASoC: Add support for Intel Bay Trail boards with WM5102 codec Andy Shevchenko
2021-01-11 18:54 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19c2d056-4f71-2c4c-c243-cdcc0115876c@redhat.com \
--to=hdegoede@redhat.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=ckeepax@opensource.cirrus.com \
--cc=cw00.choi@samsung.com \
--cc=lee.jones@linaro.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=patches@opensource.cirrus.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=yang.jie@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).