linux-kernel - Re: [PATCH v2 2/2] ASoC: tlv320adcx140: Add the tlv320adcx140 codec driver family

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 for Android: free password hash cracker in your pocket

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

Message-ID: <0faf0bfe-6186-59d0-e800-8523a33044dc@ti.com>
Date:   Tue, 18 Feb 2020 13:32:05 -0600
From:   Dan Murphy <dmurphy@...com>
To:     Mark Brown <broonie@...nel.org>
CC:     <lgirdwood@...il.com>, <perex@...ex.cz>, <tiwai@...e.com>,
        <alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] ASoC: tlv320adcx140: Add the tlv320adcx140 codec
 driver family

Mark

On 2/18/20 1:23 PM, Mark Brown wrote:
> On Tue, Feb 18, 2020 at 11:21:40AM -0600, Dan Murphy wrote:
>
> A couple of very small things, otherwise this looks good:
>
>> +	if (unlikely(!tx_mask)) {
>> +		dev_err(component->dev, "tx and rx masks need to be non 0\n");
>> +		return -EINVAL;
>> +	}
> Do you really need the unlikely() annotation here?  This is *hopefully*
> not a hot path.

I was copying the code from tlv320aic3x.c as suggested by one our audio 
guys here in TI.

I can remove it if you desire

>
>> +static int adcx140_codec_probe(struct snd_soc_component *component)
>> +{
>> +	struct adcx140_priv *adcx140 = snd_soc_component_get_drvdata(component);
>> +	int sleep_cfg_val = ADCX140_WAKE_DEV;
>> +	u8 bias_source;
>> +	u8 vref_source;
>> +	int ret;
>> +
>> +	adcx140->supply_areg = devm_regulator_get_optional(adcx140->dev,
>> +							   "areg");
>> +	if (IS_ERR(adcx140->supply_areg)) {
> You should really do the request and defer at the I2C level, that avoids
> running through the whole card initialization repeatedly when the device
> isn't ready.  Basically try to do all resource aquisition at the device
> level and then use it at the card level.

Ack.  Makes more sense to do it in the I2C probe.

Dan