On 2024-03-04 9:46 PM, Pierre-Louis Bossart wrote:
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.
What's the proposal here? Would comment suffice or there is something
else you have in mind?
