Dne 24. 04. 20 v 18:49 Mark Brown napsal(a):
On Fri, Apr 24, 2020 at 10:52:38AM +0200, Jaroslav Kysela wrote:
Dne 23. 04. 20 v 20:40 Mark Brown napsal(a):
My instinct is that the machine driver name is being used as a proxy for something else here and that if we need to change the ABI perhaps we need to extend it rather than trying to shoehorn things into what's there.
My point is that this information is duplicated in the sense, that we have three fields with the similar contents passed from the audio driver by the ASoC drivers whose set only snd_soc_card->name from the device tree.
For generic drivers: They can pass a generic driver name (like 'ASoC Simple') for the simple card driver (soc/generic/simple-card.c).
So my proposal is to change the driver_name to the right contents (it was the initial intention for this field - changed somehow for ASoC). An information about the used driver which is independent on the real configuration (device tree, ACPI, component enumeration etc.). In other words, the name should be more close to the source (top-level driver) code name than the hardware configuration.
So if it's not really going to be used for anything particularly concrete then I'm having a hard time summoning the enthusiasm for a change.
The driver name is used as the directory name in UCM / UCM2. For DT, it means thousands possible directories (one per board / board + codec variant and so on..). The generic simple asoc card is a good example.
It feels more like a neatness thing than anything else and the postitive case just isn't jumping out at me, certainly not as a thing to force for everything. New stuff, sure. I guess I'm not bothered enough to block any platform that has a burning desire to convert either though if users start coming and complaining about kernel upgrades breaking things we'd have to revert.
:-( I don't propose to force one way. We can conditionally change the driver names using a well documented CONFIG_ option to keep compatibility with the older user space code. The new driver names may be selected manually in the kernel config.
I would prefer to have the sound hardware description in the long name field than the whole hardware platform info here, too.
Does it also cope with the DT equivalents (and I guess there's nothing we can do for board file based systems)? This stuff does get used for embedded systems where the plastics are often important for the configuration.
The author of DT config knows what hardware is described, thus this person should be resposible for the nice GUI sound part name.
Jaroslav