linux-kernel - Re: [alsa-devel] [PATCH v5 7/9] ASoC: bt-sco: extend rate and add a general compatible string

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: <1467341386.21689.6.camel@mtksdaap41>
Date:	Fri, 1 Jul 2016 10:49:46 +0800
From:	Garlic Tseng <garlic.tseng@...iatek.com>
To:	Mark Brown <broonie@...nel.org>
CC:	<tiwai@...e.de>, <srv_heupstream@...iatek.com>,
	<linux-mediatek@...ts.infradead.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <alsa-devel@...a-project.org>,
	<koro.chen@...iatek.com>, <PC.Liao@...iatek.com>,
	<ir.lian@...iatek.com>
Subject: Re: [alsa-devel] [PATCH v5 7/9] ASoC: bt-sco: extend rate and add a
 general compatible string

On Thu, 2016-06-30 at 20:55 +0800, Garlic Tseng wrote:
> On Wed, 2016-06-29 at 20:15 +0100, Mark Brown wrote:
> > On Fri, Jun 17, 2016 at 03:43:58PM +0800, Garlic Tseng wrote:
> > > Add supports for 16k (wideband BT) and add a general compatible
> > > string "linux,bt-sco"
> > 
> > This will claim that we support 16k on existing systems which we clearly
> > don't.  It also seems unwise to advertise multiple rates when we've no
> > way to configure the rates...  how does the BT controller figure out
> > what the sample rate is?
> 
> The codec driver is a dummy driver for bt device and actually do
> nothing. The user-space will control both bt part and alsa part (at
> least in mt2701 platform). Yes the sound/soc/codecs/bt-sco.c was only
> support 8k and was already there before the patch, but I think it might
> be ok to extend it to 16k without any side effect.
> 
> If you worry about some potential risk (I don't see any) maybe we have
> to develop another dummy bt-sco codec driver which support both 8k and
> 16k?

Ah! If someone whose bluetooth modules only support 8k use the driver,
they might be broken, right? Maybe we can add another snd_soc_dai_driver
which can support both 8k and 16k.
(Actually I found the issue is discussed before
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-November/084687.html )