linux-kernel - Re: [alsa-devel] [PATCH 1/4] ASoC: rockchip: add rockchip machine driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150519111602.GG2761@sirena.org.uk>
Date:	Tue, 19 May 2015 12:16:02 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	Dylan Reid <dgreid@...omium.org>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	Heiko Stübner <heiko@...ech.de>,
	zhengxing <zhengxing@...k-chips.com>,
	Takashi Iwai <tiwai@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Douglas Anderson <dianders@...omium.org>,
	Xing Zheng <acgzxing@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	linux-rockchip@...ts.infradead.org,
	Sonny Rao <sonnyrao@...omium.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [alsa-devel] [PATCH 1/4] ASoC: rockchip: add rockchip machine
 driver

On Fri, May 15, 2015 at 10:40:59PM +0200, Lars-Peter Clausen wrote:

> I think the proper way to support this is come up with the concept of jack
> detection providers and consumers. A component can register a jack detection
> provider just like it can register a DAI. And then in the board driver you'd
> just link the jack detection logic to the jack using the usual approach,
> which is also used for DAIs (e.g. of node or device name). The core would
> then take care of calling a enable callback or whatever is required to setup
> the jack detection logic in the driver.

Yes, nobody has really cared about it since we started pushing things
out of the card init into the device level.  We would also need to add a
way to force microphone biases on for devices where that's not a part of
the jack detection IP.

> This would also nicely solve the issue with the GPIO jack detectors, where
> we currently can't really handle -EPROBE_DEFER. The GPIO would be requested
> by a jack detection provider which can request them before the card is
> registered rather than having to do the requesting in the card's init
> callback.

Cards should be able to do their requesting in their probe function
prior to registering with the core even without anything else, though
that needs a bit or refactoring too.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)