linux-kernel - Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of

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: <87k1je38w7.wl-kuninori.morimoto.gx@renesas.com>
Date:   09 Jan 2019 10:51:48 +0900
From:   Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        <linux-tegra@...r.kernel.org>, Matthias Reichl <hias@...us.com>,
        <alsa-devel@...a-project.org>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Takashi Iwai <tiwai@...e.com>, <linux-kernel@...r.kernel.org>,
        Marcel Ziswiler <marcel@...wiler.com>
Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement

Hi Jon

Thank you for your help

> > Yes so this does workaround the problem. However, per my previous
> > comments, I would like to explore whether it is necessary to allocate
> > the platform link component or if it can be static.

OK, thanks.
It *will* be static, but not yet.
Thank you for your patch.
I guess you worry about allocated memory leak when failed case ?
It is using devm_kzalloc(), so all allocated memory will be automatically
freed when card was detached.
But indeed if driver gots -EPROBE_DEFER many times,
it will allocate many unused platform.

Here is the background of snd_soc_init_platform.

Legacy dai_link was xxx_name/xxx_of_node style,
but multi codec support starts to use snd_soc_dai_link_component style.
OTOH Lars-Petter is thinking that current ALSA SoC is not good match
for modern sound device.
I guess, we need "multi xxx" support as 1st step for modern sound device.
"multi codec" is already supported,
"multi cpu"   patch was posted, but not yet accepted (or rejected ??).
"multi platform" is no plan (?).
These want to use snd_soc_dai_link_component style,
because it is nice for multi xxx support style, I think.
I think no one is planing for "multi platform" so far, thus,
I posted snd_soc_dai_link_component style for it.
# Maybe it should have num_platform, too.
# all driver will have .num_platform = 1, thus I didn't added.
# maybe it was my fault...

The reason why platform/codec is allocating/copying by snd_soc_init_xxx
so far is that it is glue for
xxx_name/xxx_of_node (legacy style) <-> snd_soc_init_platform (modern style).

I want to which to modern style immediately and remove legacy style.
But as you know, we have too many ALSA SoC drivers now.
So, if I posted "switch legacy style to modern style" patch
for each (= for codec, for platform, for cpu), it will be patch-bomb,
and Lars-Petter/Mark don't like it.
Thus, I'm waiting "multi CPU" support patch.

If CPU/Codec/Platform can be snd_soc_init_platform style,
then, we can switch to modern style for all drivers.
Then, all driver will have *static* platform.

# So, I guess if your driver can switch to use
# snd_soc_init_platform style directly, your problem can gone ?

> Mark

If there is no plan for "multi CPU" so far,
I can post snd_soc_dai_link_component style for CPU.
and post switch modern style for all drivers.
Then, this issue can be solved ?

Best regards
---
Kuninori Morimoto