linux-kernel - Re: [PATCH 04/11] MFD: twl4030-audio: Add DT support

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: <20120809103600.GI24328@opensource.wolfsonmicro.com>
Date:	Thu, 9 Aug 2012 11:36:00 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>, Liam Girdwood <lrg@...com>,
	Tony Lindgren <tony@...mide.com>,
	Dmitry Torokhov <dtor@...l.ru>, alsa-devel@...a-project.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	Benoit Cousson <b-cousson@...com>
Subject: Re: [PATCH 04/11] MFD: twl4030-audio: Add DT support

On Thu, Aug 09, 2012 at 01:18:50PM +0300, Peter Ujfalusi wrote:
> On 08/08/2012 05:49 PM, Mark Brown wrote:

> > That makes sense if the GPIO is actively driven, open drain should be
> > better here, but it's still a generic thing which it'd be nice to
> > extract.

> To cover all of this in a generic way is not that straight forward IMHO.

The sequence is just:

  1. Enable mutes (at _PRE time)
  2. Do whatever the device needs
  3. Disable the mutes (at _POST time)

I'm not sure there's any reason for you not to use the internal mute
even if the external mute is present but if there is that's the only
thing that's weird here.  If there's no reason not to do it it just goes
into step 2 and then it's fine, even if there is you can make it
conditional in step 2.

> Sure I could do this:
> hs_extmute: if only this is set we shall use the chip built in functionality
> hs_extmute_gpio: if this is set we use the extmute feature but with external
>                  GPIO.

> But both need to be documented and supported.

Is there any actual case where an external mute is supplied via a
mechanism other than a GPIO, and if there is would it not either need
its own DT property or already need to interact with the driver from
code, making the DT property redundant?  My thinking here is that the
flag should be redundant because we already need to specify how we do
the mute, what I'd expect is that we activate the external mute
functionality as a result of being given another way of doing it so we
don't need to provide a flag.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/