Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: YGu8dfFuXkDypDAWteYxiivbyf8XDTaJITanwkLqZFfp8LfQK1gdnlpMMJL//7iktQUuFeSKbf
 rTmPaWhYO54g==
IronPort-SDR: VWi1JLsaZAVvlqpxRGMKsBvp7vRhCLW0BNV7GqwgsSiEF1Q1owbQdpqfXMGs2hcLW2cFMQOtE1
 D0ApP9YDiFnw==
Subject: Re: [PATCH] ASoC: amd: Add support for ALC1015P codec in acp3x
 machine driver
To:     "Mukunda,Vijendar" <vijendar.mukunda@amd.com>,
        Mark Brown <broonie@kernel.org>
Cc:     jack.yu@realtek.com, alsa-devel@alsa-project.org,
        Sunil-kumar.Dommati@amd.com, kent_chen@realtek.com,
        Arnd Bergmann <arnd@arndb.de>,
        Tzung-Bi Shih <tzungbi@google.com>,
        open list <linux-kernel@vger.kernel.org>,
        Basavaraj.Hiregoudar@amd.com, Takashi Iwai <tiwai@suse.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
        Alexander.Deucher@amd.com, shumingf@realtek.com,
        Ravulapati Vishnu vardhan rao 
        <Vishnuvardhanrao.Ravulapati@amd.com>, flove@realtek.com,
        Akshu Agrawal <akshu.agrawal@amd.com>
References: <1617095628-8324-1-git-send-email-Vijendar.Mukunda@amd.com>
 <82817878-a30d-2b0c-07f8-48bcca3ebc80@linux.intel.com>
 <a55c7a75-22ab-31fc-81b3-ed8fa24027f4@amd.com>
 <20210330153534.GF4976@sirena.org.uk>
 <cd0d87e0-caa5-b671-9c91-1c5f35c2f017@linux.intel.com>
 <972d38d8-39c8-66d7-292d-37c1f0e027bd@amd.com>
From:   Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Message-ID: <b330ca5e-1162-29c9-d846-fbfbd9db638f@linux.intel.com>
Date:   Mon, 5 Apr 2021 11:24:22 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <972d38d8-39c8-66d7-292d-37c1f0e027bd@amd.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


>>>>>> ?? static const struct acpi_device_id acp3x_audio_acpi_match[] = {
>>>>>> ?????? { "AMDI5682", (unsigned long)&acp3x_5682},
>>>>>> ?????? { "AMDI1015", (unsigned long)&acp3x_1015},
>>>>>> +??? { "AMDP1015", (unsigned long)&acp3x_1015p},
>>>
>>>>> This isn't a valid ACPI ID. AMDP does not exist in
>>>
>>> ...
>>>
>>>>> There was a similar issue with Intel platforms using this part, we had
>>>>> to use a different HID.
>>>
>>>> Is it okay if i use "AMDI1016" for ALC1015P?
>>>
>>> That's valid, though obviously you might regret that later on if someone
>>> releases a CODEC with a 1016 name (equally well ACPI being what it is
>>> there's no good options for naming).
>>
>> wish granted, the 1016 already exists :-)
>> you may want to align with what we did for Intel and use the same HID: 
>> RTL1015
> 
> As per RTK team inputs, "RTL1015" ACPI HID is in use for RT1015p codec 
> driver.
> RTK team suggested us to use "RTL1015A" as ACPI HID.
> Let us know, if we can use "RTL1015A" as an ACPI HID?

Not if you want to be compliant. The part ID remains pegged to 4 hex 
digits, no matter what the vendor ID representation is.

The only solution I can suggest is using the PCI ID 0x1002, ie.

AMDI1015 -> AMD platform with RT1015
10021015 -> AMD platform with RT1015p

Note that it's not only ACPI's fault, other standards also only allow 
for 16 bits for part IDs, we'd have the same issue with SoundWire.