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]

Date:	Thu, 09 Aug 2012 13:18:50 +0300
From:	Peter Ujfalusi <peter.ujfalusi@...com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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 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.

Yes, the idea in it's core is generic, but right now I can not think of a
generic implementation which would work.
In case of twl4030 this is how it looks like:

1. if extmute is requested
 1.1. if GPIO number is not valid
   Use the internal MUTE functionality (HS_POPN_SET register, EXTMUTE bit)
 1.2. if GPIO number is valid
   set the GPIO to 1
2. Execute the sequence for the power up/down
3. if extmute is requested
 3.1. if GPIO number is not valid
   Use the internal MUTE functionality (HS_POPN_SET register, EXTMUTE bit)
 3.2. if GPIO number is valid
   set the GPIO to 0

For other devices it could be simpler:
1. Set GPIO for mute
2. Toggle a bit in the codec
3. Clear the GPIO to unmute

another device would need a sequence in step 2 instead of a single bit change.

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

> Still, the main thing here was the fact that we should be able to drop
> the flag for the feature in the first place.

Which flag you are referring?
I can (and have dropped) the hs_extmute_disable_level flag, but separate
hs_extmute, hs_extmute_gpio is needed for this device.

hs_extmute tells that the board implemented some sort of HS extmute functionality.
hs_extmute_gpio tells if the board is _not_ using the built in functionality,
but it is using external GPIO line to enable/disable the mute.

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.

-- 
Péter
--
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/