linux-kernel - Re: [PATCH] ASoC: rt5682: Prefer async probe

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:   Sun, 30 Aug 2020 09:22:02 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Cheng-yi Chiang <cychiang@...omium.org>
Cc:     Mark Brown <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>,
        Liam Girdwood <lgirdwood@...il.com>,
        Oder Chiou <oder_chiou@...ltek.com>,
        Takashi Iwai <tiwai@...e.com>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@...a-project.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: rt5682: Prefer async probe

Hi,

On Sun, Aug 30, 2020 at 4:05 AM Cheng-yi Chiang <cychiang@...omium.org> wrote:
>
> > @@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
> >                 .name = "rt5682",
> >                 .of_match_table = rt5682_of_match,
> >                 .acpi_match_table = rt5682_acpi_match,
> > +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>
>
> One thing I am wondering is that there has not been any usage in codec
> driver for this.
> I think every codec driver can use this, and take the benefit of a
> possible faster boot time ?

One possibility is that they are all enabled as modules instead of
builtin to the kernel so nobody ever thought to do it.  Modules are
always probed asynchronously, so this flag is basically a no-op there
(and, in fact, for anything that can be built as a module we have even
more certainty that async probe is safe).

In the case of the Chrome OS 5.4 tree it's possible this driver should
be moved to a module.  However, even if we do that my patch is still
fine and would be helpful if anyone has a reason to build this driver
in.  Similar patches could likely be made to other codecs and would
similarly speed up boots in cases where codecs were builtin.

-Doug