On 3/4/24 14:34, Cezary Rojewski wrote: > On 2024-03-04 9:22 PM, Pierre-Louis Bossart wrote: >> On 3/4/24 13:49, Andy Shevchenko wrote: >>> On Mon, Mar 04, 2024 at 10:57:39AM -0600, Pierre-Louis Bossart wrote: >>>>> +/* Values for link_type field above */ >>>>> + >>>>> +#define ACPI_NHLT_LINKTYPE_HDA 0 >>>>> +#define ACPI_NHLT_LINKTYPE_DSP 1 >>>>> +#define ACPI_NHLT_LINKTYPE_PDM 2 >>>>> +#define ACPI_NHLT_LINKTYPE_SSP 3 >>>>> +#define ACPI_NHLT_LINKTYPE_SLIMBUS 4 >>>>> +#define ACPI_NHLT_LINKTYPE_SDW 5 >>>>> +#define ACPI_NHLT_LINKTYPE_UAOL 6 >>>> >>>> More than half of those values are not used. Is there really any >>>> benefit >>>> in exposing them? >>> >>> Sometimes a code is the (only) documentation. Since it's a global >>> header and >>> part of ACPICA we probably better to expose all bits that are defined. >> >> NHLT is an Intel-only solution - no other company uses it. >> Intel does not have any designs where SlimBus is productized. >> >> I fail to see the wisdom of exposing a non-existent option with >> LINKTYPE_SLIMBUS. It's not because this case was listed in a document >> that we have to add the information verbatim in a open-source header. >> >> Likewise for SoundWire we do NOT use NHLT at all... >> >> Options 4 and 5 are completely irrelevant. 0 and 1 most likely as well. > > Hello, > > How relevant or not given field is in LINKTYPE enumeration is.. > irrelevant. Those values are reserved since the dawn of the table. > Renaming those with range of RESERVED_X(s) is hardly an alternative. On > top of that, specs which have been publicly shared since 2016 _do_ list > the non-I2S/PDW constants when describing LINKTYPE. I maintain that all those values, while spec-defined, should be treated as not supported. It's not unusual in engineering to change directions and back-annotate, demote or cleanup initial designs. Change is the only constant.
