Arizona Extcon Update Device Bindings

Add additional bindings to allow configuration of the system specific microphone detection settings.

Signed-off-by Charles Keepax <[email protected]>

---
 Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
 include/dt-bindings/mfd/arizona.h                 |    5 +++++
 2 files changed, 26 insertions(+), 0 deletions(-)

Documentation/devicetree/bindings/mfd/arizona.txt +21 -0

index a8fee60..b98a11b 100644
@@ -73,6 +73,27 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,micd-software-compare : Use a software comparison to determine mic
+    presence
+  - wlf,micd-detect-debounce : Additional software microphone detection
+    debounce specified in milliseconds.
+  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
+    polarity if one exists.
+  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
+    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
+    defines.
+  - wlf,micd-rate : Delay between successive microphone detection measurements,
+    specified as per the ARIZONA_MICD_TIME_XXX defines.
+  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
+    number of measurements to take, valid values being 2 and 4.
+  - wlf,micd-timeout : Timeout for microphone detection, specified in
+    milliseconds.
+  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
+    detection.
+
+  - wlf,gpsw : Settings for the general purpose switch, set as one of the
+    ARIZONA_GPSW_XXX defines.
+
   - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
     they are being externally supplied. As covered in
     Documentation/devicetree/bindings/regulator/regulator.txt

include/dt-bindings/mfd/arizona.h +5 -0

index c40f665..dedf46f 100644
@@ -110,4 +110,9 @@
 #define ARIZONA_ACCDET_MODE_HPM 4
 #define ARIZONA_ACCDET_MODE_ADC 7
 
+#define ARIZONA_GPSW_OPEN           0
+#define ARIZONA_GPSW_CLOSED         1
+#define ARIZONA_GPSW_CLAMP_ENABLED  2
+#define ARIZONA_GPSW_CLAMP_DISABLED 3
+
 #endif

Add additional bindings to allow configuration of the system specific microphone detection settings.

Quoted 2 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 4 lines · Mark Brown

Quoted 2 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

Quoted 4 lines

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Is that an Ack?

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

Quoted 2 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

Quoted 6 lines

Quoted 4 lines

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at LinuxCon it looks like it is pretty unlikely the DT maintainers will be acking individual bindings as well, basically they are only really looking at major/framework things and leaving the rest to subsystem maintainers.

Given that these patches only touch MFD/Extcon and extcon is a subsystem designed to handle things like jack detection isn't it really sufficient that you and Chanwoo have looked this and are happy with it? Otherwise I really don't see anyway to move this forward and would appreciate any suggestions?

Hi Charles,

Quoted 23 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

Quoted 2 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

Quoted 6 lines

Quoted 4 lines

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at LinuxCon it looks like it is pretty unlikely the DT maintainers will be acking individual bindings as well, basically they are only really looking at major/framework things and leaving the rest to subsystem maintainers.

Quoted 5 lines

Given that these patches only touch MFD/Extcon and extcon is a subsystem designed to handle things like jack detection isn't it really sufficient that you and Chanwoo have looked this and are happy with it? Otherwise I really don't see anyway to move this forward and would appreciate any suggestions?

I'm positive about your patches. After receiving the ack from MFD maintainer I want to apply this patch-set on extcon git repository.

Also, I reviewed this patch on previous patch[1].
[1]https://lkml.org/lkml/2015/9/11/81

Quoted 32 lines · Chanwoo Choi

Hi Charles,

Quoted 23 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

Quoted 2 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

Quoted 6 lines

Quoted 4 lines

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at LinuxCon it looks like it is pretty unlikely the DT maintainers will be acking individual bindings as well, basically they are only really looking at major/framework things and leaving the rest to subsystem maintainers.

Quoted 5 lines

Given that these patches only touch MFD/Extcon and extcon is a subsystem designed to handle things like jack detection isn't it really sufficient that you and Chanwoo have looked this and are happy with it? Otherwise I really don't see anyway to move this forward and would appreciate any suggestions?

Quoted 5 lines

I'm positive about your patches. After receiving the ack from MFD maintainer I want to apply this patch-set on extcon git repository.

Also, I reviewed this patch on previous patch[1].
[1]https://lkml.org/lkml/2015/9/11/81

As you said, this patch touch MFD and EXTCON subsystem. If you get the Ack or agreement from MFD maintainer, I'm willing to apply it on extcon git.

Also, If this patch dont receive the additional ack message unitl the end of this week, I'll merge patch1-3 on extcon-next branch for Linux 4.4.

Quoted 43 lines · Chanwoo Choi

Quoted 32 lines · Chanwoo Choi

Hi Charles,

Quoted 23 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

Quoted 2 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

Quoted 6 lines

Quoted 4 lines

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at LinuxCon it looks like it is pretty unlikely the DT maintainers will be acking individual bindings as well, basically they are only really looking at major/framework things and leaving the rest to subsystem maintainers.

Quoted 5 lines

Given that these patches only touch MFD/Extcon and extcon is a subsystem designed to handle things like jack detection isn't it really sufficient that you and Chanwoo have looked this and are happy with it? Otherwise I really don't see anyway to move this forward and would appreciate any suggestions?

Quoted 5 lines

I'm positive about your patches. After receiving the ack from MFD maintainer I want to apply this patch-set on extcon git repository.

Also, I reviewed this patch on previous patch[1].
[1]https://lkml.org/lkml/2015/9/11/81

As you said, this patch touch MFD and EXTCON subsystem. If you get the Ack or agreement from MFD maintainer, I'm willing to apply it on extcon git.

Quoted 3 lines

Also, If this patch dont receive the additional ack message unitl the end of this week, I'll merge patch1-3 on extcon-next branch for Linux 4.4.

Absolutely not!

I should be extremely cross if you 'go over my head' and apply MFD patches without the correct Acks.

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 1 line

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

LinuxCon it looks like it is pretty unlikely the DT maintainers will be acking individual bindings as well, basically they are only really looking at major/framework things and leaving the rest to subsystem maintainers.

Given that these patches only touch MFD/Extcon and extcon is a subsystem designed to handle things like jack detection isn't it really sufficient that you and Chanwoo have looked this and are happy with it? Otherwise I really don't see anyway to move this forward and would appreciate any suggestions?

Thanks,
Charles

Quoted 7 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 6 lines

Quoted 1 line

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

should have the confidence to review straightfoward device properties like this.

Quoted 9 lines · Mark Brown

Quoted 7 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Quoted 4 lines

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked.

Quoted 3 lines

should have the confidence to review straightfoward device properties like this.

I don't think these bindings are particularly straightforward. The contain many terms which I'm unfamiliar with, and again, to me (the uninitiated) this looks like way too many bindings just to see if an audio jack is plugged in or not.

Quoted 18 lines · Lee Jones

Quoted 9 lines · Mark Brown

Quoted 7 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Quoted 4 lines

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Its not a binding contract to continue providing them but we are making that a condition of merging any patches, which means I will need to chase Mark for Acks, as it seems the DT maintainers won't have any interest in reviewing/acking these.

Quoted 9 lines

Quoted 3 lines

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked.

It would be sensible I guess to define whether I should be including audio people on jack detection patches even if they don't touch audio subsystems. I was treating jack detection as an extcon thing and thus assuming that the extcon maintainer would be sufficient, but perhaps that is an incorrect assumption.

Quoted 7 lines

Quoted 2 lines

should have the confidence to review straightfoward device properties like this.

I don't think these bindings are particularly straightforward. The contain many terms which I'm unfamiliar with, and again, to me (the uninitiated) this looks like way too many bindings just to see if an audio jack is plugged in or not.

I also wish our designers would make less complex hardware sigh.

Apologies I didn't mean to cause any offense here, I am just getting a bit concerned about how I can get any DT support for jack detection upstreamed. I am more than happy to fix up any comments anyone has or answer any questions about what things are or why they are required.

The jack detection on these chips is fairly complex and there are going to be plenty more patches before we have full support for it in DT. So I think it would be good for everyone if we can agree some process for how to handle this type of patch.

Quoted 24 lines · Charles Keepax

Quoted 18 lines · Lee Jones

Quoted 9 lines · Mark Brown

Quoted 7 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Quoted 4 lines

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Quoted 4 lines

Its not a binding contract to continue providing them but we are making that a condition of merging any patches, which means I will need to chase Mark for Acks, as it seems the DT maintainers won't have any interest in reviewing/acking these.

I've already made it a condition, as I refuse to blindly accept unknown bindings. Taking a sea of bindings I have no knowledge of would be a bad-thing(tm). If these were GPIO bindings, I'd be asking Linus for help, likewise if they were I2C, I'd be asking Wolfram.

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked.

Quoted 5 lines

It would be sensible I guess to define whether I should be including audio people on jack detection patches even if they don't touch audio subsystems. I was treating jack detection as an extcon thing and thus assuming that the extcon maintainer would be sufficient, but perhaps that is an incorrect assumption.

Now I know that jack detection is an Extcon thing and Extcon Ack will do just nicely. However, that begs the question; if they are an Extcon thing, why aren't they in the Extcon binding document?

Quoted 9 lines

Quoted 8 lines

Quoted 3 lines

should have the confidence to review straightfoward device properties like this.

I don't think these bindings are particularly straightforward. The contain many terms which I'm unfamiliar with, and again, to me (the uninitiated) this looks like way too many bindings just to see if an audio jack is plugged in or not.

Quoted 7 lines

I also wish our designers would make less complex hardware sigh.

Apologies I didn't mean to cause any offense here, I am just getting a bit concerned about how I can get any DT support for jack detection upstreamed. I am more than happy to fix up any comments anyone has or answer any questions about what things are or why they are required.

Hopefully there won't be too many more bindings to come?

My issue is that as they are not MFD related, I need some advice from my colleagues to whom they are related to.

Quoted 4 lines

The jack detection on these chips is fairly complex and there are going to be plenty more patches before we have full support for it in DT. So I think it would be good for everyone if we can agree some process for how to handle this type of patch.

Put them in the subsystem where they pertain to -- job done.

Hi Lee,

Quoted 52 lines · Lee Jones

Quoted 24 lines · Charles Keepax

Quoted 18 lines · Lee Jones

Quoted 9 lines · Mark Brown

Quoted 7 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Quoted 4 lines

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Quoted 4 lines

Its not a binding contract to continue providing them but we are making that a condition of merging any patches, which means I will need to chase Mark for Acks, as it seems the DT maintainers won't have any interest in reviewing/acking these.

I've already made it a condition, as I refuse to blindly accept unknown bindings. Taking a sea of bindings I have no knowledge of would be a bad-thing(tm). If these were GPIO bindings, I'd be asking Linus for help, likewise if they were I2C, I'd be asking Wolfram.

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked.

Quoted 5 lines

It would be sensible I guess to define whether I should be including audio people on jack detection patches even if they don't touch audio subsystems. I was treating jack detection as an extcon thing and thus assuming that the extcon maintainer would be sufficient, but perhaps that is an incorrect assumption.

Quoted 3 lines

Now I know that jack detection is an Extcon thing and Extcon Ack will do just nicely. However, that begs the question; if they are an Extcon thing, why aren't they in the Extcon binding document?

As I knew, the arizona-extcon is one device of the MFD devices for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon driver needs the some property for dt support, some property should be included in MFD device tree node. There is no separate device tree node for arizona-extcon driver.

Quoted 57 lines · Chanwoo Choi

Quoted 52 lines · Lee Jones

Quoted 24 lines · Charles Keepax

Quoted 18 lines · Lee Jones

Quoted 9 lines · Mark Brown

Quoted 7 lines · Charles Keepax

Quoted 6 lines · Lee Jones

Quoted 4 lines · Mark Brown

This all seems pretty much fine to me - the things it is controlling are fairly specific to the way the former Wolfson devices do, they only really make sense with a fairly particular algorithm which isn't widely implemented.

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Quoted 4 lines

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Quoted 4 lines

Its not a binding contract to continue providing them but we are making that a condition of merging any patches, which means I will need to chase Mark for Acks, as it seems the DT maintainers won't have any interest in reviewing/acking these.

I've already made it a condition, as I refuse to blindly accept unknown bindings. Taking a sea of bindings I have no knowledge of would be a bad-thing(tm). If these were GPIO bindings, I'd be asking Linus for help, likewise if they were I2C, I'd be asking Wolfram.

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked.

Quoted 5 lines

It would be sensible I guess to define whether I should be including audio people on jack detection patches even if they don't touch audio subsystems. I was treating jack detection as an extcon thing and thus assuming that the extcon maintainer would be sufficient, but perhaps that is an incorrect assumption.

Quoted 3 lines

Now I know that jack detection is an Extcon thing and Extcon Ack will do just nicely. However, that begs the question; if they are an Extcon thing, why aren't they in the Extcon binding document?

Quoted 5 lines

As I knew, the arizona-extcon is one device of the MFD devices for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon driver needs the some property for dt support, some property should be included in MFD device tree node. There is no separate device tree node for arizona-extcon driver.

If creating the separate extcon doc for extcon-arizona.c driver, it is possible to make the child device tree node which is located at the below of arizona MFD device tree node.

I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.

Quoted 20 lines · Chanwoo Choi

Quoted 13 lines · Chanwoo Choi

Quoted 11 lines · Lee Jones

Quoted 6 lines · Charles Keepax

Quoted 5 lines · Lee Jones

Quoted 3 lines · Mark Brown

Quoted 2 lines · Charles Keepax

Quoted 1 line · Lee Jones

On Wed, 07 Oct 2015, Mark Brown wrote:

Now I know that jack detection is an Extcon thing and Extcon Ack will do just nicely. However, that begs the question; if they are an Extcon thing, why aren't they in the Extcon binding document?

Quoted 5 lines

As I knew, the arizona-extcon is one device of the MFD devices for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon driver needs the some property for dt support, some property should be included in MFD device tree node. There is no separate device tree node for arizona-extcon driver.

Quoted 5 lines

If creating the separate extcon doc for extcon-arizona.c driver, it is possible to make the child device tree node which is located at the below of arizona MFD device tree node.

I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.

This is how we normally document MFDs. Extcon doesn't even need to have it's own child-node (it can if you want though -- it's however you want to represent it), you can just put something like this in the MFD binding doc:

Optional properties
this : Does this
that : Does that

Also any child device specific property:
GPIO See: ../extcon/arizona.txt
Extcon See: ../gpio/arizona.txt

Etc. Or words to that effect. See some other MFDs for examples.

Quoted 6 lines · Mark Brown

Quoted 4 lines · Charles Keepax

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Quoted 3 lines

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked.

Quoted 2 lines

should have the confidence to review straightfoward device properties like this.

I don't think these bindings are particularly straightforward. The contain many terms which I'm unfamiliar with, and again, to me (the uninitiated) this looks like way too many bindings just to see if an audio jack is plugged in or not.

Quoted 7 lines · Lee Jones

Quoted 6 lines · Mark Brown

Quoted 4 lines · Charles Keepax

I am guessing Mark is slightly hesitant to ack as he probably doesn't want to add reviewing all our jack detection bindings to his already fairly sizable work load and doing so here likely means it will be expected in the future. From talking to people at

Quoted 4 lines

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

It's a bit concerning when it seems like my review is becoming a blocker for something and I don't understand why.

Quoted 3 lines

Quoted 3 lines

Pretty much (plus generally being busy at ELC-E last week) - if there's specific questions that's one thing but if it's just general requests to look at bindings then it seems like the relevant subsystem maintainers

Quoted 5 lines

This is exactly my point. I am not the 'relevant subsystem maintainer' for these properties and subsequently know nothing of microphone detection, headsets, bias', etc. These look like Audio related properties to me (the uninitiated), which is why you were asked.

They're extcon things (and there are accompanying driver changes to the extcon driver parsing them).

Quoted 7 lines

Quoted 2 lines

should have the confidence to review straightfoward device properties like this.

I don't think these bindings are particularly straightforward. The contain many terms which I'm unfamiliar with, and again, to me (the uninitiated) this looks like way too many bindings just to see if an audio jack is plugged in or not.

When your power budget is in the low double digit microamps and you're trying to respond promptly and reliably to rapidly changing and variable physical inputs it gets complicated.

Quoted 6 lines · Mark Brown

Quoted 4 lines · Lee Jones

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Quoted 2 lines

It's a bit concerning when it seems like my review is becoming a blocker for something and I don't understand why.

Not necessarily _your_ review. Just someone, other than the submitter, who I trust and knows about this stuff. You just happen to tick those boxes this time. Cross pollination and knowledge sharing is one of the characteristics of MLs which I'm particularly proud of.

Quoted 3 lines

When your power budget is in the low double digit microamps and you're trying to respond promptly and reliably to rapidly changing and variable physical inputs it gets complicated.

This is exactly why I asked you.

Thanks for adding structure to my PoV. ;)

Quoted 8 lines · Lee Jones

Quoted 6 lines · Mark Brown

Quoted 4 lines · Lee Jones

Providing Acks should not (and has not to my knowledge) be a binding contract to continue providing Acks. However, should more bindings be submitted which appear as though they are related to a particular maintainer, then sure, you'll be asked for your expert eye again.

Quoted 7 lines

Quoted 2 lines

It's a bit concerning when it seems like my review is becoming a blocker for something and I don't understand why.

Not necessarily _your_ review. Just someone, other than the submitter, who I trust and knows about this stuff. You just happen to tick those boxes this time. Cross pollination and knowledge sharing is one of the characteristics of MLs which I'm particularly proud of.

That was what it read like.

Quoted 3 lines

Quoted 3 lines

When your power budget is in the low double digit microamps and you're trying to respond promptly and reliably to rapidly changing and variable physical inputs it gets complicated.

Quoted 3 lines

This is exactly why I asked you.

Thanks for adding structure to my PoV. ;)

So, a more specific question would have helped - just a general "any thoughts" type question isn't very clear.

Quoted 6 lines · Mark Brown

Quoted 4 lines

Not necessarily _your_ review. Just someone, other than the submitter, who I trust and knows about this stuff. You just happen to tick those boxes this time. Cross pollination and knowledge sharing is one of the characteristics of MLs which I'm particularly proud of.

That was what it read like.

Quoted 2 lines

So, a more specific question would have helped - just a general "any thoughts" type question isn't very clear.

To both comments -- this is how I phrased it:

"I either need an Ack from the DT folks, or at least someone who knows about this stuff. Mark perhaps."

Quoted 8 lines · Lee Jones

Quoted 6 lines · Mark Brown

Quoted 4 lines

Not necessarily _your_ review. Just someone, other than the submitter, who I trust and knows about this stuff. You just happen to tick those boxes this time. Cross pollination and knowledge sharing is one of the characteristics of MLs which I'm particularly proud of.

That was what it read like.

...

Quoted 7 lines

Quoted 2 lines

So, a more specific question would have helped - just a general "any thoughts" type question isn't very clear.

To both comments -- this is how I phrased it:

"I either need an Ack from the DT folks, or at least someone who knows about this stuff. Mark perhaps."

I'd have expected something that says why you're looking for this - something saying what you were unclear on, something more like "It seems like there's an awful lot of properties for something that just checks if a jack". From the above (especially with the request for the DT people to review) it seems like more just a review because there's DT properties.

Add additional bindings to allow configuration of the system specific microphone detection settings.

Signed-off-by Charles Keepax <[email protected]>

---
 Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
 include/dt-bindings/mfd/arizona.h                 |    5 +++++
 2 files changed, 26 insertions(+), 0 deletions(-)

Documentation/devicetree/bindings/mfd/arizona.txt +10 -0

index a8fee60..b98a11b 100644
@@ -73,6 +73,27 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,micd-software-compare : Use a software comparison to determine mic
+    presence
+  - wlf,micd-detect-debounce : Additional software microphone detection
+    debounce specified in milliseconds.
+  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
+    polarity if one exists.
+  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
+    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
+    defines.
+  - wlf,micd-rate : Delay between successive microphone detection measurements,

Documentation/devicetree/bindings/mfd/arizona.txt +0 -0

   - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
     they are being externally supplied. As covered in
     Documentation/devicetree/bindings/regulator/regulator.txt

include/dt-bindings/mfd/arizona.h +5 -0

index c40f665..dedf46f 100644
@@ -110,4 +110,9 @@
 #define ARIZONA_ACCDET_MODE_HPM 4
 #define ARIZONA_ACCDET_MODE_ADC 7
 
+#define ARIZONA_GPSW_OPEN           0
+#define ARIZONA_GPSW_CLOSED         1
+#define ARIZONA_GPSW_CLAMP_ENABLED  2
+#define ARIZONA_GPSW_CLAMP_DISABLED 3
+
 #endif

Quoted 31 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

Signed-off-by Charles Keepax <ckeepax-yzvPICuk2AATkU/[email protected]>

---
 Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
 include/dt-bindings/mfd/arizona.h                 |    5 +++++
 2 files changed, 26 insertions(+), 0 deletions(-)

Documentation/devicetree/bindings/mfd/arizona.txt +14 -0

index a8fee60..b98a11b 100644
@@ -73,6 +73,27 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,micd-software-compare : Use a software comparison to determine mic
+    presence
+  - wlf,micd-detect-debounce : Additional software microphone detection
+    debounce specified in milliseconds.
+  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
+    polarity if one exists.
+  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
+    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
+    defines.
+  - wlf,micd-rate : Delay between successive microphone detection measurements,
+    specified as per the ARIZONA_MICD_TIME_XXX defines.
+  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
+    number of measurements to take, valid values being 2 and 4.
+  - wlf,micd-timeout : Timeout for microphone detection, specified in

Documentation/devicetree/bindings/mfd/arizona.txt Optional properties: · line 95

Quoted 6 lines

Documentation/devicetree/bindings/mfd/arizona.txt +6 -0

+    milliseconds.
+  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
+    detection.
+
+  - wlf,gpsw : Settings for the general purpose switch, set as one of the
+    ARIZONA_GPSW_XXX defines.

Where are all of these bindings to be consumed?

Quoted 33 lines · Lee Jones

Quoted 31 lines · Charles Keepax

Add additional bindings to allow configuration of the system specific microphone detection settings.

Signed-off-by Charles Keepax <ckeepax-yzvPICuk2AATkU/[email protected]>

---
 Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
 include/dt-bindings/mfd/arizona.h                 |    5 +++++
 2 files changed, 26 insertions(+), 0 deletions(-)

Documentation/devicetree/bindings/mfd/arizona.txt +14 -0

index a8fee60..b98a11b 100644
@@ -73,6 +73,27 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,micd-software-compare : Use a software comparison to determine mic
+    presence
+  - wlf,micd-detect-debounce : Additional software microphone detection
+    debounce specified in milliseconds.
+  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
+    polarity if one exists.
+  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
+    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
+    defines.
+  - wlf,micd-rate : Delay between successive microphone detection measurements,
+    specified as per the ARIZONA_MICD_TIME_XXX defines.
+  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
+    number of measurements to take, valid values being 2 and 4.
+  - wlf,micd-timeout : Timeout for microphone detection, specified in

Quoted 8 lines

Documentation/devicetree/bindings/mfd/arizona.txt Optional properties: · line 95

Quoted 6 lines

Documentation/devicetree/bindings/mfd/arizona.txt +6 -0

+    milliseconds.
+  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
+    detection.
+
+  - wlf,gpsw : Settings for the general purpose switch, set as one of the
+    ARIZONA_GPSW_XXX defines.

Where are all of these bindings to be consumed?

In the extcon driver it handles all jack detection in the Arizona devices.

Add additional binding for inverting the polarity of the detection on the jack detection pins.

Signed-off-by Charles Keepax <[email protected]>

---
 Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Documentation/devicetree/bindings/mfd/arizona.txt +0 -0

index b98a11b..ef59696 100644

Documentation/devicetree/bindings/mfd/arizona.txt +0 -0

   - wlf,micd-software-compare : Use a software comparison to determine mic
     presence
   - wlf,micd-detect-debounce : Additional software microphone detection

Quoted 16 lines · Charles Keepax

Add additional binding for inverting the polarity of the detection on the jack detection pins.

Signed-off-by Charles Keepax <ckeepax-yzvPICuk2AATkU/[email protected]>

---
 Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Documentation/devicetree/bindings/mfd/arizona.txt +0 -0

index b98a11b..ef59696 100644
@@ -73,6 +73,8 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 

Documentation/devicetree/bindings/mfd/arizona.txt Optional properties: · line 77

Quoted 2 lines

Documentation/devicetree/bindings/mfd/arizona.txt +2 -0

+  - wlf,jd-invert : Invert the polarity of the jack detection switch
+

There are other jack detection properties in the bindings docs.

Please generify.

Quoted 23 lines · Lee Jones

Quoted 13 lines · Charles Keepax

Add additional binding for inverting the polarity of the detection on the jack detection pins.

Signed-off-by Charles Keepax <[email protected]>

---
 Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Documentation/devicetree/bindings/mfd/arizona.txt +0 -0

index b98a11b..ef59696 100644

Documentation/devicetree/bindings/mfd/arizona.txt Optional properties: · line 77

Quoted 5 lines

Documentation/devicetree/bindings/mfd/arizona.txt +2 -0

@@ -73,6 +73,8 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,jd-invert : Invert the polarity of the jack detection switch
+

There are other jack detection properties in the bindings docs.

Quoted 1 line

Please generify.

Apologies but not sure I follow what you want me to do here? Do you just want me to drop the wlf, prefix on this one?