linux-kernel - Re: [PATCH 09/13] ASoC: amd: acp: add machine driver support for pdm use case

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:   Fri, 27 Oct 2023 17:57:25 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Mario Limonciello <mario.limonciello@....com>,
        Syed Saba Kareem <Syed.SabaKareem@....com>,
        broonie@...nel.org, alsa-devel@...a-project.org
Cc:     Vijendar.Mukunda@....com, Basavaraj.Hiregoudar@....com,
        Sunil-kumar.Dommati@....com, venkataprasad.potturu@....com,
        arungopal.kondaveeti@....com, mastan.katragadda@....com,
        juan.martinez@....com, Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Marian Postevca <posteuca@...ex.one>,
        Alper Nebi Yasak <alpernebiyasak@...il.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Gaosheng Cui <cuigaosheng1@...wei.com>,
        Jarkko Nikula <jarkko.nikula@...mer.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/13] ASoC: amd: acp: add machine driver support for pdm
 use case

On 27/10/2023 17:54, Mario Limonciello wrote:
> On 10/27/2023 10:51, Krzysztof Kozlowski wrote:
>> On 27/10/2023 17:28, Mario Limonciello wrote:
>>> On 10/27/2023 03:49, Krzysztof Kozlowski wrote:
>>>> On 21/10/2023 16:50, Syed Saba Kareem wrote:
>>>>> add pdm use case machine driver support
>>>>>
>>>>> Signed-off-by: Syed Saba Kareem <Syed.SabaKareem@....com>
>>>>> ---
>>>>
>>>>
>>>>>    	dmi_id = dmi_first_match(acp_quirk_table);
>>>>>    	if (dmi_id && dmi_id->driver_data)
>>>>> @@ -214,6 +221,10 @@ static const struct platform_device_id board_ids[] = {
>>>>>    		.name = "rmb-rt5682s-rt1019",
>>>>>    		.driver_data = (kernel_ulong_t)&rt5682s_rt1019_rmb_data,
>>>>>    	},
>>>>> +	{
>>>>> +		.name = "acp-pdm-mach",
>>>>> +		.driver_data = (kernel_ulong_t)&acp_dmic_data,
>>>>> +	},
>>>>>    	{ }
>>>>>    };
>>>>>    static struct platform_driver acp_asoc_audio = {
>>>>> @@ -235,4 +246,5 @@ MODULE_ALIAS("platform:acp3xalc5682s1019");
>>>>>    MODULE_ALIAS("platform:acp3x-es83xx");
>>>>>    MODULE_ALIAS("platform:rmb-nau8825-max");
>>>>>    MODULE_ALIAS("platform:rmb-rt5682s-rt1019");
>>>>> +MODULE_ALIAS("platform:acp-pdm-mach");
>>>>
>>>> Please stop growing the aliases. Module alias is not a substitute for
>>>> missing MODULE_DEVICE_TABLE.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> I thought the way that this works is that top level ACP driver (IE
>>> acp-pci.c) will have MODULE_DEVICE_TABLE.  This is how that module gets
>>> loaded.
>>>
>>> Then it creates platform devices based on the detected needs for the
>>> situation and the creation of those platform devices triggers a uevent
>>> which due to MODULE_ALIAS will get appropriate other platform drivers
>>> like this one loaded.
>>
>> And why you cannot use MODULE_DEVICE_TABLE here? IOW, why do you need to
>> manually duplicate entire table and re-invent MODULE_DEVICE_TABLE with
>> MODULE_ALIAS?
> 
> What would actually go into MODULE_DEVICE_TABLE?

The table you have few lines above aliases.

> 
> The platform devices created are contingent upon what was found during 
> the top level ACP driver probe.  You don't want all the "child" platform 
> drivers to load unless they're needed.

How static alias differs here from static device ID table? Both are
built into the module and always there. I don't even understand what
does it mean by "loading child platform drivers". Why would unneeded
driver be loaded?

Best regards,
Krzysztof