On 12/16/21 8:37 AM, Cezary Rojewski wrote: > On 2021-12-16 3:11 PM, Pierre-Louis Bossart wrote: >> The intent of soc-acpi files is to establish a match between ACPI _HID >> and machine driver, this is now duplicated, and it makes limited sense >> to add machine driver dependencies in a platform driver. >> >> Nothing was broken with the existing code. > > Hello, > > Yes, nothing is broken in the existing code. The intention is different > - be cohesive about what is actually used by the driver. > > PCI-ids table is duplicated already for the Intel audio drivers. And > it's OK to do so - one knows which ids are covered by given driver and > how. Here, it's clear that haswell_machines are only used by > catpt-driver and so are some fields for broadwell_machines. In time I > believe that we will be able to reduce the number of fields for struct > snd_soc_acpi_mach i.e. have a single fw_filename and single > tplg_filename field without some driver-specific duplicates. I don't really see the point about the number of fields, this is a generic descriptor used for I2S/SoundWire devices so mechanically there are things are are not used in all platforms. Another example is the quirks field, it's only meant to be used when there's actually a quirk. Note that I am planning to remove the sof_fw_filename field since it's redundant with what is part of the PCI descriptor, but the topology will remain there: it has to match with the machine driver. > About the last, there could be a case where no topology file is > available for certain configuration and given entry should not be taken > into account. While catpt-driver does not make use of soc-topology > feature, that isn't true for other drivers. Again if a feature is not needed/not supported, the field can remain empty.
