On Mon, Sep 19, 2016 at 03:11:00AM +0000, Oder Chiou wrote:

...

On Tue, Aug 23, 2016 at 01:33:43PM +0800, Oder Chiou wrote:

...

...

+- realtek,use-ldo2

...

This would more normally be done by making LDO2 a regulator via the normal regulator framework - look at how the arizona drivers handle DCVDD for an example, it provides a default supply mapping which makes things really easy for users. Right now it's not clear to me looking at the code that the driver works for systems that don't use an internal LDO as there's nothing that enables MICVDD.

The LDO2 is not a regulator, and it is an internal LDO of codec that controlled by register setting. Normally, the MICVDD is connected to 3.3V

It's an internal regulator in the CODEC.

VDD directly, and it isn't controlled by regulator. The option "realtek,use-ldo2" is depend on the customer that can decide that the MICVDD is provided by external 3.3V VDD or internal LDO2 for it. If they used the internal LDO2, the pin of MICVDD can be floated.

Sure, that's exactly what it looks like so my comments above apply.

...

We do a reset when we unregister at the CODEC level - that'll overwrite these settings won't it?

We have done it in the function "rt5660_remove".

Right, and if the user removes and reloads the driver then the reset will happen.