[PATCH] ASoC: amd: Add support for ALC1015P codec in acp3x machine driver

[Pierre-Louis Bossart]

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