On 12/5/2023 6:22 PM, Pierre-Louis Bossart wrote:
+static void tas2563_fixup_i2c(struct hda_codec *cdc,
+ const struct hda_fixup *fix, int action)
+{
+ tas2xxx_generic_fixup(cdc, action, "i2c", "INT8866");
Any specific reason to use an Intel ACPI identifier? Why not use
"TIAS2563" ?
Will just note that prefix should probably be TXNW (not TIAS) as
discussed recently on list.
INT8866 is in the ACPI.
I don't know why Lenovo uses this name.
I think it's more internal than intel.
Scope (_SB.I2CD)
{
Device (TAS)
{
Name (_HID, "INT8866") // _HID: Hardware ID
Ouch, I hope they checked with Intel that this isn't an HID already in
use...
It looks the INT prefix is not reserved. (yet)
https://uefi.org/ACPI_ID_List?acpi_search=INT
It's been de-facto reclaimed by Intel over the years, apparently using
INTC or INTL was too hard for some of my colleagues...
Perhaps it should be reserved then, so it is present on above list?
There are lots of INT devices in the kernel today, here's a small list
for sound/soc/codecs only
rt274.c: { "INT34C2", 0 },
rt286.c: { "INT343A", 0 },
rt298.c: { "INT343A", 0 },
ssm4567.c: { "INT343B", 0 },
Those INT values were added by Intel teams though, it's really odd to
see Lenovo use an INT-based HID. Should really use 104C2563 or something.
I will just note that those RT ones are used on quite old RVPs, and yes
I would have also preferred if they had used "real" IDs, but it is
unlikely that anyone fixes it after all this time ;).
Adding Andy to CC, as he commented recently about problematic
assignments of ACPI IDs on this list, maybe he can shed some light on
the "INT" prefix.
