We know that there are issues when TRRS usage is combined with n!n and some similar boards. There is also a lack of documentation on the issue.
I propose the addition of a new flag under the definition of a board, EXT_POWER_DEFAULT_ON, which is only relevant if the board is able to regulate EXT_POWER. The flag defaults to y when not present, and is used to define the initial EXT_POWER value (currently it defaults to on).
We then adjust the definition of n!n, nrfmicro (and any other boards which I am not thinking of that have the same issue) to have the flag set to n, aka default off.
The documentation should be adjusted accordingly, but then should also warn users about enabling EXT_POWER for wired use.
I believe that with EXT_POWER off the wired power issues are not present, and then users will be informed about the issue as they go to enable it/try to find out why it is no longer working. A potential increase in the number of user questions is a fair price for increasing safety in my opinion.
We know that there are issues when TRRS usage is combined with n!n and some similar boards. There is also a lack of documentation on the issue.
I propose the addition of a new flag under the definition of a board,
EXT_POWER_DEFAULT_ON, which is only relevant if the board is able to regulateEXT_POWER. The flag defaults toywhen not present, and is used to define the initialEXT_POWERvalue (currently it defaults toon).We then adjust the definition of n!n, nrfmicro (and any other boards which I am not thinking of that have the same issue) to have the flag set to
n, aka defaultoff.The documentation should be adjusted accordingly, but then should also warn users about enabling
EXT_POWERfor wired use.I believe that with
EXT_POWERoff the wired power issues are not present, and then users will be informed about the issue as they go to enable it/try to find out why it is no longer working. A potential increase in the number of user questions is a fair price for increasing safety in my opinion.