On 08/11/2022 06:33, Padmanabhan Rajanbabu wrote: >>> >>> The actual reason for having a custom sound card driver lies in the >>> fact that the Samsung i2s cpu dai requires configuration of some >>> Samsung specific properties like rfs, bfs, codec clock direction and >>> root clock source. We do not have flexibility of configuring the same >>> in simple card driver (sound/soc/generic/simple-card.c) or audio graph >>> card driver (sound/soc/generic/audio-graph-card.c). The binding has >>> been added to support the custom sound card driver. >>> >>> I understand from your query that the newly added card has device tree >>> nodes and properties which are used in simple card as well, but having >>> a different or new prefixes. I believe to address that, we can >>> restructure the string names to generic ones. >> >> You must use generic, existing properties where applicable. > > Okay > >> >>> But I would like to understand, to reuse the simple card or audio >>> graph card bindings, can we add secondary compatible strings in the >>> simple card dt-binding for the custom sound card to probe ? >> >> If you see other vendor compatibles there, then yes... But there aren't any, >> right? > > Yes you are right, we don't see other vendor compatibles. But, am I allowed > to add such secondary compatibles so that we can extend the simple card > and its utilities to a large extent? > > If no, then I believe we will need a separate binding to extend the generic > properties. If you have any custom properties, then yes. But you don't have. Best regards, Krzysztof
