linux-kernel - Re: [alsa-devel] [RFC PATCH 2/2] ASoC: samsung: Print a one-time message if the snow driver's probe defers

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, 20 Oct 2016 07:41:57 -0300
From:   Javier Martinez Canillas <javier@....samsung.com>
To:     Sylwester Nawrocki <s.nawrocki@...sung.com>
Cc:     linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
        Sangbeom Kim <sbkim73@...sung.com>,
        Takashi Iwai <tiwai@...e.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [alsa-devel] [RFC PATCH 2/2] ASoC: samsung: Print a one-time
 message if the snow driver's probe defers

Hello Sylwester,

Thanks a lot for your feedback.

On 10/20/2016 06:12 AM, Sylwester Nawrocki wrote:
> On 10/19/2016 07:21 PM, Javier Martinez Canillas wrote:
>> If the snd_soc_register_card() fails due a missing resource and the probe
>> has to be deferred, the driver prints an error message.
>>
>> But since many probe retries can happen before a resource is available,
>> the printed messages can spam the kernel log buffer and slow the boot.
> 
> Do you know why CPU DAI is not registered by the time snow machine
> driver gets probed? Did you try to debug the I2S driver? Does perhaps
> deferring happen due to some I2S clocks missing? DMA seems to be
> already initialized.
> The deferral loop looks suspicious, do you perhaps know what commits

It's suspicious indeed and I've been trying to figure out what changed
the behavior in v4.8 but I haven't found it yet.

> in v4.8 cause such changes in probing order? Did you start to use

I did a git bisect to find the first v4.8 commit that caused this but
finished in a merge commit c9b95e5961c0 ("Merge tag 'sound-4.8-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound").

That branch alone works the same than v4.7 so it seems that is not a
single commit but a combination from different branches that caused
this on integration.

> some drivers as loadable module?
>

I see no relevant changes in exynos_defconfig between v4.7..v4.8 and
also no changes in drivers/Makefile that could cause things to be
initialized on a different order.

But I thought the patches had merits on its own since probe deferral
can make a driver probe many times and the error logs were noisy. I
wasn't sure though and that's why are marked as RFC.

> As far as the error log is concerned, I would just not print anything
> in snow_probe() when register_card() returns EPROBE_DEFER.
> 

I believe it may be useful to know that a driver's probe is deferring due
a missing dependency but have no strong opinion and can remove the message.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America