linux-kernel - Re: [PATCH v3 2/2] ASoC: codecs: add support for TAS5720 digital amplifier

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] [day] [month] [year] [list]

Message-ID: <20160513140420.GH9174@borg.dal.design.ti.com>
Date:	Fri, 13 May 2016 09:04:20 -0500
From:	Andreas Dannenberg <dannenberg@...com>
To:	Mark Brown <broonie@...nel.org>
CC:	<alsa-devel@...a-project.org>, <devicetree@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] ASoC: codecs: add support for TAS5720 digital
 amplifier

Mark, please see below...

On Fri, May 13, 2016 at 12:55:40PM +0100, Mark Brown wrote:
> On Tue, Apr 26, 2016 at 01:01:05PM -0500, Andreas Dannenberg wrote:
> > On Tue, Apr 26, 2016 at 06:29:36PM +0100, Mark Brown wrote:
> 
> > > Is the device actually going to mess up if someone sends it something
> > > else or is it just going to ignore the extra bits (given that it's doing
> > > autodetection anyway).
> 
> > well in any of the left-justified modes (which are the only ones the
> > driver supports) the device takes and processes as many bits as it can
> > given the clock and divider settings. Any extra bits provided will get
> > ignored, and the next sync happens on the frame sync signal and not by
> > counting bits so there is no downside also as confirmed by some bench
> > testing I did feeding in 32-bit long frames for one channel. This seems
> > like a case of preferring tolerance over strictly enforcing
> > datasheet-advertised bit-widths. Will take out the check code.
> 
> OK, accepting extra bits is fine.  You should set sig_bits in the DAI so
> userspace can see what's going on if it cares.

I just had a quick look to see what sig_bits does, yes this is a good
addition. Will post a follow-up patch based on the driver that you
already accepted into your tree.

(Btw I'm working on another codec driver and I don't stop getting
positively surprised how flexible and powerful the overall ASoC
framework is).

Regards,
Andreas

> > Along these lines, earlier as I was rummaging through the existing
> > drivers looking for a solution I could model after I noticed that
> > most(?) ASoC codec drivers don't have any type of HW fault checking, at
> > at least whatever drivers I looked at. Not sure why this is but given
> > this discussion this seems like a general opportunity to make
> > improvements.
> 
> There are some with over temperature handling (eg, wm8962) but it's
> relatively uncommon for observable protection features to be implemented
> in silicon and even rarer for the interrupts to be hooked up (and hence
> useful to support in software) unless there is also accessory detection
> in the device.  On older devices the required digital logic was often
> excessively expensive and realistically only relatively high power
> speaker drivers have much risk of something going wrong - things like
> headphone outputs or smaller speaker drivers end up with protection from
> their supplies collapsing well before the device is in physical danger.