On Mon, 4 Oct 2021, Mark Brown wrote: > > > > +static const char * const micbias_voltage[] = { "off", "2V", "2.5V", > > > > "AVDD" }; > > > > This should be configured in the DT, it's going to be a property of the > > > electrical design of the system. > > > I can very well imagine that this something that should be runtime > > userspace configurable. In fact where I work we have had products where > > the bias voltage (for an externally connected microphone) could be > > configured by the end user, (although not for this specific driver quite > > honestly, we have had the need for hardware engineers to change it runtime > > during circuit verification though). > > > Would it be ok to have this configurable both in the DT as well as using a > > control? Or should it be implemented in another way, such as a number of > > pre set voltages that are selected between using a control? > > It seems like a lot less work to just not have the runtime control and > let someone who needs it figure out how to represent it to userspace. > Something that's basically a backdoor for validation doesn't seem > persuasive, validation often wants to do things we actively wish to > prevent at runtime. I'll add it to the DT configuration, but I can't really see why the having an additional runtime control would be a lot of extra work. In a completely embedded system where the microphone is part of the internal design it makes sense not to have it controllable of course, but in a system where the microphone is an external component (i.e. plugged into a microphone connector), the system design might need for it to be user configurable. /Ricard -- Ricard Wolf Wanderlof ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30