Is your feature request related to a problem? Please describe.
We have a strong ABI control mechanism for the IPC ABI, but nothing equivalent exists for the underlying ABI for components byte controls such as EQ/MUX/DRC. Should an audio server such as CRAS want to start generating coefficients dynamically for a number of firmware versions it becomes quite complex to track what ABI to use where. To add to this complexity, we do not have access to logical kernel headers for core ABI version to possibly infer ABI differences in the components from.
Describe the solution you'd like
A definitive way to infer what ABI to use where and when. A possible idea is to version the components themselves and have them publish their versions through a control which can be consumed by a library to generate coefficients dynamically. Another would be version the control name.
Describe alternatives you've considered
Global versioning is not likely to work as this can be easily broken by cherry-picking to release branches, also without having some sort of ioctl or control it is much harder to access. Debugfs is discouraged.
@bzhg @johnylin76 @poloo5582 @afq984 FYI
Is your feature request related to a problem? Please describe.
We have a strong ABI control mechanism for the IPC ABI, but nothing equivalent exists for the underlying ABI for components byte controls such as EQ/MUX/DRC. Should an audio server such as CRAS want to start generating coefficients dynamically for a number of firmware versions it becomes quite complex to track what ABI to use where. To add to this complexity, we do not have access to logical kernel headers for core ABI version to possibly infer ABI differences in the components from.
Describe the solution you'd like
A definitive way to infer what ABI to use where and when. A possible idea is to version the components themselves and have them publish their versions through a control which can be consumed by a library to generate coefficients dynamically. Another would be version the control name.
Describe alternatives you've considered
Global versioning is not likely to work as this can be easily broken by cherry-picking to release branches, also without having some sort of ioctl or control it is much harder to access. Debugfs is discouraged.
@bzhg @johnylin76 @poloo5582 @afq984 FYI