linux-kernel - RE: [PATCH] ASoC: da7219: remove SRM lock check retry

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: <AM5PR1001MB09946850D64829B34BDA89EB80420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
Date:   Tue, 3 Dec 2019 17:15:25 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     "Lu, Brent" <brent.lu@...el.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
CC:     Support Opensource <Support.Opensource@...semi.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ASoC: da7219: remove SRM lock check retry

On 03 December 2019 15:23, Brent Lu wrote:

> > Yes, that's right. I have put in a request with our HW team to again clarify
> > timings, but still awaiting feedback.
> >
> > The driver already warns via the kernel logs when SRM lock fails as follows:
> >
> > 	dev_warn(component->dev, "SRM failed to lock\n");
> >
> > What else do you think is needed?
> >
> 
> Hi Adam,
> 
> Let's say that the SRM locks in the second loop. The 50ms delay was applied
> but there is no kernel log message about it because the value of srm_lock is
> already true when exiting the loop. If we can print every SRM lock fail before
> msleep() call, it would be a helpful for people resolving timing issues like Cold
> latency.
> 
> do {
> 	pll_status = snd_soc_component_read32(component,
> DA7219_PLL_SRM_STS);
> 	if (pll_status & DA7219_PLL_SRM_STS_SRM_LOCK) {
> 		break;
> 	} else {
> 		++i;
> 		dev_warn(component->dev, "SRM failed to lock, retry in
> 50ms\n");
> 		msleep(50);
> 	}
> } while (i < DA7219_SRM_CHECK_RETRIES);

I have no real problem in providing debug like this, although this is probably
dev_info() rather than dev_warn(). Also I'd suggest the debug message should be
something like the following if we were to add anything here:

	dev_info(component->dev, "Waiting for SRM lock\n");

Timings can be ascertained from the kernel log (assuming timestamping is on) so
I don't think we need to explicitly state the delay information.

> 
> 
> Regards,
> Brent