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]

Message-id: <7a730a84-ce97-2148-87d9-64211a1aaa6b@samsung.com>
Date:   Thu, 20 Oct 2016 13:27:09 +0200
From:   Sylwester Nawrocki <s.nawrocki@...sung.com>
To:     Javier Martinez Canillas <javier@....samsung.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

On 10/20/2016 12:41 PM, Javier Martinez Canillas wrote:
> 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.

I remember this

commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
clk: probe common clock drivers earlier

going in recently, but it's rather dubious it could cause such trouble.

Anyway, I'd try to add some debug prints to samsung_i2s_probe() to see
what's the issue with the CPU DAI registration.

> 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.

In general I wouldn't be disabling those err logs unless proper
EPROBE_DEFER handling is added on related error paths and we can
differentiate between probe deferral and real unrecoverable errors
and can disable logging only for EPROBE_DEFER cases.

>> 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.

I'd rather rely on core code to inform about missing resources when
registering components.  Otherwise booting unnecessarily takes more
time when there is more probe deferring logs printed on the console.

--
Thanks,
Sylwester