Login attempt failed and Banning IP address <IP_ADDRESS>

Home Assistant release with the issue:

0.77.2
Last working Home Assistant release (if known):
0.74.2
Operating environment (Hass.io/Docker/Windows/etc.):

HassOS on RPI 3
Component/platform:

Description of problem:
After upgrading to 0.77 I now see a login attempt/ban issue for <IP_ADDRESS>, which seems to be the hassos_supervisor IP in docker. I see a similar issue at #15595, but that was marked as resolved.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
http:
  api_password: !secret myapi_password
  base_url: hassio.example.com:8123
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem
  ip_ban_enabled: true
  login_attempts_threshold: 3

Traceback (if applicable):
18-09-04 03:09:50 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/install access from a0d7b954_ssh
18-09-04 03:09:50 INFO (MainThread) [hassio.addons.addon] Create Home-Assistant addon data folder /data/addons/data/a0d7b954_docker-enabler
18-09-04 03:09:50 INFO (SyncWorker_16) [hassio.docker.interface] Pull image hassioaddons/docker-enabler tag 0.1.1.
18-09-04 03:09:54 INFO (SyncWorker_16) [hassio.docker.interface] Tag image hassioaddons/docker-enabler with version 0.1.1 as latest
18-09-04 03:09:55 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/options access from a0d7b954_ssh
18-09-04 03:09:55 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/start access from a0d7b954_ssh
18-09-04 03:09:58 INFO (SyncWorker_14) [hassio.docker.addon] Start docker addon hassioaddons/docker-enabler with version v0.1.1
18-09-04 03:10:00 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/info access from a0d7b954_docker-enabler
18-09-04 03:10:01 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:03 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/info access from a0d7b954_docker-enabler
18-09-04 03:10:05 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:06 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/info access from a0d7b954_docker-enabler
18-09-04 03:10:09 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/info access from a0d7b954_docker-enabler
18-09-04 03:10:09 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:12 INFO (MainThread) [hassio.api.security] /addons access from a0d7b954_docker-enabler
18-09-04 03:10:13 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:17 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/info access from a0d7b954_docker-enabler
18-09-04 03:10:18 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:20 INFO (MainThread) [hassio.api.security] /addons access from a0d7b954_docker-enabler
18-09-04 03:10:22 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:25 INFO (MainThread) [hassio.api.security] /supervisor/info access from a0d7b954_docker-enabler
18-09-04 03:10:26 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:28 INFO (MainThread) [hassio.api.security] /host/info access from a0d7b954_docker-enabler
18-09-04 03:10:30 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:31 INFO (MainThread) [hassio.api.security] /homeassistant/info access from a0d7b954_docker-enabler
18-09-04 03:10:34 INFO (MainThread) [hassio.api.security] /supervisor/info access from a0d7b954_docker-enabler
18-09-04 03:10:34 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:37 INFO (MainThread) [hassio.api.security] /supervisor/info access from a0d7b954_docker-enabler
18-09-04 03:10:39 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:43 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:44 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/info access from a0d7b954_docker-enabler
18-09-04 03:10:46 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/info access from a0d7b954_docker-enabler
18-09-04 03:10:47 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:51 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:55 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:10:58 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/options access from a0d7b954_docker-enabler
18-09-04 03:10:58 WARNING (MainThread) [hassio.api.addons] Protected flag changing for a0d7b954_ssh!
18-09-04 03:11:00 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:11:02 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_docker-enabler/uninstall access from a0d7b954_ssh
18-09-04 03:11:02 INFO (SyncWorker_2) [hassio.docker.interface] Clean hassioaddons/docker-enabler docker application
18-09-04 03:11:02 INFO (SyncWorker_2) [hassio.docker.interface] Remove docker hassioaddons/docker-enabler with latest and v0.1.1
18-09-04 03:11:03 INFO (MainThread) [hassio.addons.addon] Remove Home-Assistant addon data folder /data/addons/data/a0d7b954_docker-enabler
18-09-04 03:11:04 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/restart access from a0d7b954_ssh
18-09-04 03:11:04 INFO (SyncWorker_7) [hassio.docker.interface] Stop hassioaddons/ssh-aarch64 docker application
18-09-04 03:11:05 INFO (SyncWorker_7) [hassio.docker.interface] Clean hassioaddons/ssh-aarch64 docker application
18-09-04 03:11:06 WARNING (SyncWorker_19) [hassio.docker.addon] SSH & Web Terminal run with disabled proteced mode!
18-09-04 03:11:07 INFO (SyncWorker_19) [hassio.docker.addon] Start docker addon hassioaddons/ssh-aarch64 with version v3.4.1
18-09-04 03:11:10 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:11:13 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:11:15 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:11:18 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:11:20 INFO (MainThread) [hassio.api.security] /addons access from a0d7b954_ssh
18-09-04 03:11:24 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:11:27 INFO (MainThread) [hassio.api.security] /addons access from a0d7b954_ssh
18-09-04 03:11:31 INFO (MainThread) [hassio.api.security] /supervisor/info access from a0d7b954_ssh
18-09-04 03:11:33 INFO (MainThread) [hassio.api.security] /host/info access from a0d7b954_ssh
18-09-04 03:11:35 INFO (MainThread) [hassio.api.security] /homeassistant/info access from a0d7b954_ssh
18-09-04 03:11:38 INFO (MainThread) [hassio.api.security] /supervisor/info access from a0d7b954_ssh
18-09-04 03:11:40 INFO (MainThread) [hassio.api.security] /supervisor/info access from a0d7b954_ssh
18-09-04 03:11:53 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:11:55 INFO (MainThread) [hassio.api.security] /addons/a0d7b954_ssh/info access from a0d7b954_ssh
18-09-04 03:13:22 ERROR (MainThread) [hassio.homeassistant] Can't update HomeAssistant access token!
18-09-04 03:13:22 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished coro=<Tasks._watchdog_homeassistant_api() done, defined at /usr/local/lib/python3.7/site-packages/hassio/tasks.py:109> exception=UnboundLocalError("local variable 'err' referenced before assignment")>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/hassio/tasks.py", line 126, in _watchdog_homeassistant_api
    await self.sys_homeassistant.check_api_state():
  File "/usr/local/lib/python3.7/site-packages/hassio/homeassistant.py", line 426, in check_api_state
    _LOGGER.warning("Home-Assistant API config missmatch: %d", err)
UnboundLocalError: local variable 'err' referenced before assignment
18-09-04 03:18:22 ERROR (MainThread) [hassio.homeassistant] Can't update HomeAssistant access token!
18-09-04 03:18:22 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished coro=<Tasks._watchdog_homeassistant_api() done, defined at /usr/local/lib/python3.7/site-packages/hassio/tasks.py:109> exception=UnboundLocalError("local variable 'err' referenced before assignment")>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/hassio/tasks.py", line 126, in _watchdog_homeassistant_api
    await self.sys_homeassistant.check_api_state():
  File "/usr/local/lib/python3.7/site-packages/hassio/homeassistant.py", line 426, in check_api_state
    _LOGGER.warning("Home-Assistant API config missmatch: %d", err)
UnboundLocalError: local variable 'err' referenced before assignment
18-09-04 03:23:22 ERROR (MainThread) [hassio.homeassistant] Can't update HomeAssistant access token!
18-09-04 03:23:22 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished coro=<Tasks._watchdog_homeassistant_api() done, defined at /usr/local/lib/python3.7/site-packages/hassio/tasks.py:109> exception=UnboundLocalError("local variable 'err' referenced before assignment")>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/hassio/tasks.py", line 126, in _watchdog_homeassistant_api
    await self.sys_homeassistant.check_api_state():
  File "/usr/local/lib/python3.7/site-packages/hassio/homeassistant.py", line 426, in check_api_state
    _LOGGER.warning("Home-Assistant API config missmatch: %d", err)
UnboundLocalError: local variable 'err' referenced before assignment
18-09-04 03:28:22 ERROR (MainThread) [hassio.homeassistant] Can't update HomeAssistant access token!
18-09-04 03:28:22 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished coro=<Tasks._watchdog_homeassistant_api() done, defined at /usr/local/lib/python3.7/site-packages/hassio/tasks.py:109> exception=UnboundLocalError("local variable 'err' referenced before assignment")>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/hassio/tasks.py", line 126, in _watchdog_homeassistant_api
    await self.sys_homeassistant.check_api_state():
  File "/usr/local/lib/python3.7/site-packages/hassio/homeassistant.py", line 426, in check_api_state
    _LOGGER.warning("Home-Assistant API config missmatch: %d", err)
UnboundLocalError: local variable 'err' referenced before assignment
18-09-04 03:28:35 INFO (MainThread) [hassio.api.proxy] /homeassistant/api/services access from core_configurator
18-09-04 03:28:35 ERROR (MainThread) [hassio.homeassistant] Can't update HomeAssistant access token!
18-09-04 03:28:35 ERROR (MainThread) [hassio.api.proxy] Authenticate error on API for request services

Additional information:

Only two users (Me and my wife). There were two other "System generated: true" accounts that I didn't recognize and removed thinking they were from sessions prior to creating the named accounts. If removing those caused an issue is there a way to recreate them?

The reason I suspect that is the supervisor is 1) that is a private IP range and 2) I see the IP match the docker container when using the SSH & Web Terminal addon:

At least it is hassio bug:
  File "/usr/local/lib/python3.7/site-packages/hassio/homeassistant.py", line 426, in check_api_state
    _LOGGER.warning("Home-Assistant API config missmatch: %d", err)
UnboundLocalError: local variable 'err' referenced before assignment

/move to home-assistant/hassio


Recommendation: The predicted rating is garbled on the Evaluate page when using metric "RMSE" or "MSE".

System Information (please complete the following information):
Windows OS: Windows-11-Enterprise-21H2
ML.Net Model Builder 2022: <IP_ADDRESS>1401 (Main Build)
Microsoft Visual Studio Enterprise: 2022(17.3.6)
.Net: 6.0
Describe the bug

On which step of the process did you run into an issue:
The predicted rating is garbled on the Evaluate page for Recommendation scenario.

TestMatrix
https://testpass.blob.core.windows.net/test-pass-data/recommendation-ratings.csv
https://testpass.blob.core.windows.net/test-pass-data/iris.mdf
To Reproduce
Steps to reproduce the behavior:

Select Create a new project from the Visual Studio start window.
Choose the C# Console App (.NET Core6.0) project template.
Add model builder by right click on the project.
Select Recommendation scenario.
On Data page, select the data source
On the Train page, choose metric "RMSE" or "MSE", then completed the training.
On the Evaluate page, click "Predict" button and check the evaluate results.

Expected behavior
There is no garbled on the Evaluate page.
Screenshot

Additional context:
The bug is not repro when using metric "RSquared".

Looks like this is related to #2293. The recommendation scenario with these metrics seems to be the issue.

I think the value we got for  RMSE and MSE  is 0.0000, I think that might create undefined prediction.
@v-Hailishi  are you able to try for non-zero values
@LittleLittleCloud  any thought on this ?

@LittleLittleCloud  does this caused by this ml.net issue https://github.com/dotnet/machinelearning/issues/6361

This seems triggered by this Ml.Net issue https://github.com/dotnet/machinelearning/issues/6361


ZEPPELIN-5397 : Modified the interpreter.sh script to be able to parse SPARK_SUBMIT_OPTIONS

What is this PR for?
To be able to parse SPARK_SUBMIT_OPTIONS which has whitespace in between like
export SPARK_SUBMIT_OPTIONS="$SPARK_SUBMIT_OPTIONS --conf 'spark.driver.extraJavaOptions=-Dcom.example.env=production -Dcom.example.role=zeppelin'"

What type of PR is it?
Bug Fix
Todos

[ ] - Task

What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-5397

How should this be tested?
Its mentioned in the jira issue
Screenshots (if appropriate)
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? Not sure
Does this needs documentation? No

I think an empty delimiter is wrong, possibly something like "--conf" would be better.

@Reamer I tried with setting IFS as "--conf". But it making things more worse. Bash is interpreting every character in "--conf" as a separator and breaking more things.

@nilroy I tried around a bit and found this great explanation on Stackoverflow
I think the following solution can be used in our case. Tested at https://www.tutorialspoint.com/execute_bash_online.php
export SPARK_SUBMIT_OPTIONS="$SPARK_SUBMIT_OPTIONS --conf 'spark.driver.extraJavaOptions=-Dcom.example.env=production -Dcom.example.role=zeppelin' --conf mytest=myvalue"

readarray -td ''  SPARK_SUBMIT_OPTIONS_ARRAY < <(awk '{ gsub(/--conf/,"\0--conf"); print; }' <<<"${SPARK_SUBMIT_OPTIONS}--conf"); unset 'SPARK_SUBMIT_OPTIONS_ARRAY[-1]'
declare -p SPARK_SUBMIT_OPTIONS_ARRAY;

What do you think?

export SPARK_SUBMIT_OPTIONS="$SPARK_SUBMIT_OPTIONS --conf 'spark.driver.extraJavaOptions=-Dcom.example.env=production -Dcom.example.role=zeppelin' --conf mytest=myvalue"
readarray -td ''  SPARK_SUBMIT_OPTIONS_ARRAY < <(awk '{ gsub(/--conf/,"\0--conf"); print; }' <<<"${SPARK_SUBMIT_OPTIONS}--conf"); unset 'SPARK_SUBMIT_OPTIONS_ARRAY[-1]'
declare -p SPARK_SUBMIT_OPTIONS_ARRAY;

@Reamer This approach LGTM, we need to do the same thing on ZEPPELIN_SPARK_CONF

@Reamer @zjffdu
I did update as you suggested. However there are 3 other places where same IFS problem might show up:

ZEPPELIN_FLINK_YARN_APPLICATION
JAVA_INTP_OPTS
ZEPPELIN_INTP_MEM

@nilroy CI is failed, https://github.com/apache/zeppelin/pull/4127/checks?check_run_id=3053525638

@zjffdu I am having hard time understanding the failures. They all seem to be Java stack traces. Can you help me debug?

@nilroy Have you tried this PR to run spark yarn-cluster ? I suspect this PR cause the spark-submit fail to launch spark app.

I see the following error quite often.
2021-07-13T05:53:46.8447034Z SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
2021-07-13T05:53:46.8448574Z ##[error]Exception in thread "main" java.lang.NumberFormatException: For input string: "--conf spark.cores.max=2 "
2021-07-13T05:53:46.8450991Z 	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
2021-07-13T05:53:46.8452128Z 	at java.lang.Integer.parseInt(Integer.java:580)
2021-07-13T05:53:46.8452816Z 	at java.lang.Integer.parseInt(Integer.java:615)

We missed the trim.

@nilroy Any update ?

@zjffdu I did not tested running a spark-yarn cluster. I am quite tied up with my work and getting it hard to invest time. If anyone of you can take this thing from here I shall be more than happy.  You can close this PR and create a new one for the same Jira issue. Or don't change anything at all. We already found the way around this problem which I described earlier in a comment.

Hi @nilroy
I hope to have time to fix this. For the next two weeks I am on vacation.

@Reamer Thank you.  I shall leave it to you.

@Reamer CI is failed

@nilroy @Reamer  I created another PR to fix the CI https://github.com/apache/zeppelin/pull/4187, it would be nice to have this merged in the next release.

@nilroy @Reamer The major problem of this PR is that readarray is not supported in mac, this would cause user unable to use zeppelin directly on mac. IIUC, this PR just use | as separator which is this PR does in java side. https://github.com/apache/zeppelin/pull/4173 This PR would work both in mac and linux.
Regarding SPARK_SUBMIT_OPTIONS, personally I think we should deprecate this option, we should ask user always set spark interpreter in interpreter setting which seems more consistent.

@nilroy @Reamer If you don't mind, I will use https://github.com/apache/zeppelin/pull/4173 as short term solution for the coming release, and we can think about the long term solution in the next release, what do you think ?

@zjffdu @Reamer Personally I am not going to use the SPARK_SUBMIT_OPTIONS in my project after we hit this issue in the first place. We are already setting all spark configurations in spark-defaults.conf. So I am ok with removing that option completely. Regarding the interim solution #4173 I am perfectly ok with it.

Thanks for your feedback @nilroy  Besides setting it in spark-defaults.conf,  you can also set it in zeppelin's spark interpreter setting. Because setting it in spark-defaults.conf would affect all the spark application, while setting it in zeppelin's spark interpreter setting would only affect the spark application launched in zeppelin.

@zjffdu Could you please tell me the config file where I can set zeppelin spark interpreter setting? Is it the interpreter.default.json? I am a bit lost with the documentation.

@nilroy I mean the spark interpreter setting page, you can set all the spark configuration here.

@zjffdu Got it. Thank you. Shall I close this PR?

Closed in favor of #4173


Form explainers: color updates

The default design system link color had accessibility issues when displayed on the existing form explainer expandable background colors. This PR updates the explainer colors to improve accessibility, adds two additional colorways so the Wagtail explainer module can support up to 4 categories of annotations, and fixes the way the explainer Javascript is generated and added to the explainer template to resolve missing file errors on Content.
The form explainer colors are based on the CFPB design system palette but for the most part don't overlap with values in brand-colors.less (overlapping values are noted in comments in form-explainer.less).

Additions

New colors for the explainers
index.js file to init the explainer js in browser
Full width text option in explainer content streamfield

Changes

Adds the explainer js to the page via the explainer template rather than the explainer block

How to test this PR

Check out branch and run migrations and yarn
Create a FormExplainer page in Wagtail admin and verify that it is possible to add a Full Width Text block to the page
Add an explainer block to the page with 4 categories of annotations and verify that

the annotations have the expected background colors
the explainer js is loaded / interactions work as expected
WAVE tool does not report accessibility errors for links in the explainer expandables

Screenshots
Explainer colors

Explainer admin

Checklist

[x] PR has an informative and human-readable title

PR titles are used to generate the change log in releases; good ones make that easier to scan.
Consider prefixing, e.g., "Mega Menu: fix layout bug", or "Docs: Update Docker installation instructions".

[ ] Changes are limited to a single goal (no scope creep)
[x] Code follows the standards laid out in the CFPB development guidelines
[ ] Project documentation has been updated, potentially one or more of:

This repo’s docs (edit the files in the /docs folder) – for basic, close-to-the-code docs on working with this repo
CFGOV/platform wiki on GHE – for internal CFPB developer guidance
CFPB/hubcap wiki on GHE – for internal CFPB design and content guidance

I could see naming them something like gold-dk-fe if this isn't quite specific/different enough, but I think it'll be fine. 😄

Good point! I'll keep that in mind if we make more changes or need to alias the colors if they're moved to the DS...


north korea?

At the bottom of document,  it says "Contoso has blocked north korea" in so many words,  but the example screenshot does not directly show results showing blocked nor how that IP address equals a certain geographic area.
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5b96bf8a-e95d-292c-366d-c5d2a0f887b1
Version Independent ID: f640200f-9a70-0109-e2b3-2187f0dfad02
Content: Troubleshoot Conditional Access using the What If tool - Azure Active Directory
Content Source: articles/active-directory/conditional-access/troubleshoot-conditional-access-what-if.md
Service: active-directory
Sub-service: conditional-access
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@ruderod Thank you for your feedback . We have engaged the content team to look into this and provide more information on the screenshot .

@MicrosoftGuyJFlo Could you please look into this one ?
Thank you.

IP locations are defined in the back end code. Its hard to fake out a country from another. Ill see how I can update this doc when we make updates next. #please-close


Move @yamada-ui/charts to Data Display

Closes #2212
Description
Move @yamada-ui/charts to Data Display.
Is this a breaking change (Yes/No):
No.

@kurakke Sorry, Which should I check  the file under .github/workflows/  or my local source code? Or the other?
I run "pnpm format:check" command in my local, but no error detected...


Not Able to include in android studio Mac

Hello I am trying to use MoviperTemplateGenerator in android studio with mac osx but i am not able to make this heppen as in mac i don't find any plugin folder with android studio again i tried with android studio preferences but nothing works got error on http clone so if you can help me with the instructions for mac .

finally worked but you must add installation for mac systems -> path for templates is
/Applications/Android Studio.app/Contents/plugins/android/lib/templates/other/ ---->Mac Only
Thanks

That's correct. I've already added it. Thanks a lot. I sincerely apologize for replying late to your issue.


The removal of /usr/src/* breaks docker-php-ext-install on alpine build

Our pipelines fail because the sockets module can no longer be installed with docker-php-ext-install.
The error is tar (child): /usr/src/php.tar.xz: Cannot open: No such file or directory
This is because /usr/src/* is removed at cleanup for the alpine images.
https://github.com/edbizarro/gitlab-ci-pipeline-php/blob/1a456604e37c41cc2c07730f67b3c0cebf6bb630/php/scripts/alpine/cleanup.sh#L10
Is this intentional?
If so, is there a proper workaround?
Thanks

hi @StanvanHoorn
Actually that's not intentional, i believe i can safe remove this dir from removal

fixed in https://github.com/edbizarro/gitlab-ci-pipeline-php/commit/2e59517d704a3f7b6bfad0447b8c3a5b9907f2f5

Nice! Thanks for the quick fix.


AbstractOptionalAssert::contains() fails on substring.

Summary
using contains on Optional fails with substring.
Example
// fails
 assertThat(Optional.of("abc")).contains("a");

// passes
assertThat("abc").contains("a");

This works as expected as per http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractOptionalAssert.html#contains-VALUE- contains for Optional checks the content, it's not a String assertion.
We will update the code examples, to make it clear that  assertThat("abc").contains("a");


Update the general UI images

Closes #75.
Simple changes to the UI diagram in the project site's homepage and for the help section in UG.

Codecov Report

Merging #80 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #80   +/-   ##
=========================================
  Coverage     69.85%   69.85%
  Complexity      441      441
=========================================
  Files            79       79
  Lines          1463     1463
  Branches        151      151
=========================================
  Hits           1022     1022
  Misses          397      397
  Partials         44       44

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 381b00c...85f7993. Read the comment docs.


safe open: permissive on windows with auto GC

I think that rather than define safe_open, how about we (1) always issue GC.gc() right before opening (a GC doesn't take long compared to the time needed to read a file), and (2) catch the error, if it's a SystemError print your informative message, and rethrow().


Which parameter can be used to filter the scallop result?

hi ,there
The scallop is a good software to assembly the illumina data and I got lots of transcripts that other softwares can not. When I use the ORFfinder to predict the ORF with the scallop results. I got lots of transcripts without the classical splice site, such as the GT-AG,GC-AG or AT-AC. As shown in the picture1, the scallop results were not the same as the other data. Lots of scallop transcripts were not the classical splice site. Is there some parameters can be used to filter it ? As also the picture 2, the transcript looks so strange!
Thanks so much!
Sincerely
Yizhong Huang

Hi Yizhong,
Re question 1: Scallop fully uses the splice sites predicted by the aligner. So far it does not contain any model or parameter to detect / filter out poorly supported non-canonical splice sites. We will probably add such feature in future releases. But for now, you may try: 1, check if certain aligner such as STAR or HISAT2 provide such parameters to control splice sites, and/or 2, write a script of your own to filter the assembled transcripts (by Scallop).
Re question 2: the assembled transcripts seem strange to me too. Is this sample strand-specific? If so did you specify library-type when running Scallop?
Best,
Mingfu

@shaomingfu Thanks so much for your quick reply! It is a pity that the scallop has no the parameter to filter the splice sites. I have checked the annotation file of the human using the gffread  software, and almost all the transcripts are the canonical splice sites. May be I can use the gffread to filter these directly.  How can I get the proper thread of the  reads number to filter the undesired transcripts? As shown in the picture1, the scallop transcript has two more bases (CT) than other data. The strange transcript I have attached is not the strand-specific, how to deal with it ? I just run the scallop as follows: ${scallop} -i ${bam[$PBS_ARRAYID]}  -o ${output}/${NAME}_scallop.gtf.
Thanks again for your kind help
Sincerely
Yizhong Huang


Test geomap visualization with Grafana

Grafana Geomap panel visualization allows us to view and customize the world map using geospatial data. To test the capability and explore the possibility of leveraging Grafana as a customizible geographic visualization front-end for tools and applications.
https://grafana.com/docs/grafana/latest/panels-visualizations/visualizations/geomap/


gtk-update-icon-cache: The generated cache was invalid

getting this message while update icon cache gtk-update-icon-cache: The generated cache was invalid

what needs to be done is delete all or rename any files that have a space in them

ls -R | grep ' '

thanks for the answer, i'm not sure how i manage to make it disappear but now the manage never appear since after a few days i posted here.


gpio/pinctrl: GPIO and introduce PINCTRL API to support gpio, pinctrl DTS nodes

Introduction
As a general requirement we want Zephyr DTS to adhere to the specification as well as to use bindings compatible with those of the Linux kernel. To support gpio, pinctrl DTS node bindings the current GPIO driver needs to be reworked. We also need to introduce PINCTRL driver.
A GPIO driver is used to configure and control the pins directly by the application. A PINCTRL driver is used to configure the pins and route the signals to the internal hardware modules on the SoC.
Requirement to support gpio, pinctrl DTS node bindings used by the Linux kernel doesn't imply that we have to provide the same GPIO, PINCTRL API like Linux does. In fact, the APIs can be quite different. We only need to process configuration data provided by the gpio, pinctrl DTS nodes in an easy and convenient manner.
Problem description
Unlike virtually any other driver e.g. I2C, RTC, CAN, UART which functionality is confined to a single hardware module the pin configuration and control functions can be spread among multiple SoC components. The implementation can vary significantly between vendors or even SoC families.
As an example both Intel Quark and NXP/Freescale K64 have separate GPIO and pinctrl modules however functionality assigned to each module by the respective SoC family is quite different. I.e. in one case debouncing is controlled by GPIO in the other by pinctrl module.
Pin functions controlled by
Intel Quark GPIO module: value, direction, interrupts, debouncing, source (pio/ext)
Intel Quark pinctrl module: muxing, pullup, slew rate
K64 GPIO module: value, direction
K64 pinctrl module: muxing, pullup/pulldown, slew rate, open drain, drive strength, interrupts, debouncing, source (pio/ext)
Proposed change
The driver API should hide implementation details and make it possible to write portable code. I.e. it would be impractical to expect user writing application code to know if they need to use PINCTRL or GPIO driver to configure an output as an open drain. As such both GPIO and PINCTRL API should provide means to fully configure pin properties such as open drain, drive strength, input debounce, pull up or schmitt-trigger mode.
Update GPIO and introduce PINCTRL API to let Zephyr drivers and application code configure pins using data provided by gpio, pinctrl DTS nodes. The API should use naming convention / configuration options which directly relate to the gpio, (gpio.h) and pinctrl bindings defined by Linux DTS. Zephyr implementation should preserve the meaning of Linux defined configuration options. E.g. relation between DTS pinctrl node property drive-open-drain and corresponding feature of the Zephyr API should be straightforward to identify and have the same effect.
Detailed RFC
GPIO/PINCTRL driver should use the following flags as a parameter to *_configure function:

GPIO_ACTIVE_LOW, GPIO_ACTIVE_HIGH: indicate pin active state (logical value '1' in low state or logical value '1' in high state). gpio_pin_write/gpio_pin_read functions should write/read the logical pin value.
GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE: configure single ended pin driving mode
GPIO_PULL_UP, GPIO_PULL_DOWN: enable pin pull-up, pull-down
GPIO_INPUT: configure pin as input
GPIO_OUTPUT: configure pin as output. By default output is configured in push/pull mode. This behavior can be modified via GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE flags.
GPIO_OUTPUT_INIT_LOW/GPIO_OUTPUT_INIT_HIGH: initialize the output in a low/high state
GPIO_INPUT_DEBOUNCE: enable pin debounce circuitry

Linux DTS does not specify interrupt configuration within GPIO/PINCTRL node but rather a dedicated IRQ chip node. Zephyr GPIO API shall provide means to directly configure interrupts. Following base flags are proposed:

GPIO_INT_ENABLE
GPIO_INT_LEVEL
GPIO_INT_EDGE
GPIO_INT_LOW
GPIO_INT_HIGH

To make interrupt configuration easier for the end user the following convenience flags are proposed:

GPIO_INT_EDGE_RISING
GPIO_INT_EDGE_FALLING
GPIO_INT_EDGE_BOTH
GPIO_INT_LEVEL_LOW
GPIO_INT_LEVEL_HIGH

Where each of the convenience flags is defined as a combination of a base flag. E.g.
/** Trigger GPIO pin interrupt on level high. */
#define GPIO_INT_LEVEL_HIGH     (GPIO_INT_ENABLE  \
				 | GPIO_INT_LEVEL \
				 | GPIO_INT_HIGH)

New API functions
Following two functions are added to let the user directly control the pin level ignoring GPIO_ACTIVE_LOW flag. Writing value 1 to a pin will always set it to high output state, writing value 0 will always set it to low output state.
int gpio_pin_write_raw(struct device *port, u32_t pin, u32_t value);
int gpio_pin_read_raw(struct device *port, u32_t pin, u32_t *value);

Pin Controller API: TBD
Dependencies
When a new PINCTRL API is introduced the current PINMUX API can be deprecated.
Concerns and Unresolved Questions
The GPIO and PINCTRL drivers will significantly overlap their functionality since many driver features (e.g. pin drive strength, pull-up, pull-down, ability to configure output as on open source) need to be provided by both drivers. A better choice may be merging the two APIs into one.

Pull-up and pull-down input configuration flags appear to be missing.
GPIO_DIR_OUT_LOW/HIGH and GPIO_OUTPUT_INIT_LOW/HIGH appear to be redundant.
Some devices (Nordic GPIO, Semtex SX1509B) support drive strength configuration with very different capabilities and defaults.  Slew rate was also mentioned.  Unless every potential hardware capability can be anticipated with a generic API, there should be some mechanism to pass driver-implementation-specific flags along with the standard ones so vendor extensions can be controlled by applications that are aware of the underlying hardware.
It's unclear whether the flags used in the device-tree gpios composite's flags field are to be the same as the corresponding argument to a GPIO driver configuration function, or if some of the flags may only relevant for either device-tree or dynamic configuration.
The rework should clearly define at what point the flags specified in the device tree will be applied: when the GPIO driver is initialized (e.g. to come up in a low-power mode) or when whatever uses the corresponding GPIO is initialized (which would likely be a very different configuration).  It may be useful to provide multiple sets of configuration flags for a specific GPIO, perhaps by leveraging the PINMUX concept.
Functions in the new GPIO and PINCTRL driver API should clearly document exactly what is meant by each flag, and exactly what behavior is expected from drivers that are given flags that represent a configuration that is not supported by the hardware (ignore, error, make up something, ...).  The existing solution failed to do this, and the results have been unsatisfactory.

GPIO_ACTIVE_LOW, GPIO_ACTIVE_HIGH: indicate pin active state (logical value '1' in low state or logical value '1' in high state)

If this is the output configuration it should be renamed to GPIO_OUTPUT_ACTIVE_LOW/HIGH to avoid any misinterpretation.

GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE: configure single ended pin driving mode

How is push/pull operation configured?

GPIO_INPUT_DEBOUNCE: enable pin debounce circuitry (the debounce parameters, if any, should be set by a SoC specific DTS)

Why not have a set of generic debounce times that may fit a lot of SoCs (e.g. DEBOUNCE_NONE, DEBOUNCE_SHORT, DEBOUNCE_MEDIUM, DEBOUNCE_LONG). What short/ medium/ long means is dependent on the SoC and may even be specified in the DTS.

Linux DTS does not specify interrupt configuration within GPIO/PINCTRL node but rather a dedicated IRQ chip node. Zephyr GPIO API shall provide means to directly configure interrupts. Following flags are proposed:

GPIO_INT_EDGE_RISING
GPIO_INT_EDGE_FALLING
GPIO_INT_EDGE_BOTH
GPIO_INT_LEVEL_LOW
GPIO_INT_LEVEL_HIGH

GPIO_INT_EDGE_BOTH is just a waste of configuration space, it should be the combination of the GPIO_INT_EDGE_RISING and GPIO_INT_EDGE_FALLING flags.

Pull-up and pull-down input configuration flags appear to be missing.

Added to the issue description.

GPIO_DIR_OUT_LOW/HIGH and GPIO_OUTPUT_INIT_LOW/HIGH appear to be redundant.

I'm not sure how they made it there. Removed.

Some devices (Nordic GPIO, Semtex SX1509B) support drive strength configuration with very different capabilities and defaults. Slew rate was also mentioned. Unless every potential hardware capability can be anticipated with a generic API, there should be some mechanism to pass driver-implementation-specific flags along with the standard ones so vendor extensions can be controlled by applications that are aware of the underlying hardware.

I think we need to discuss drive strength, slew rate and debouncing configuration a bit more. In Linux DTS these are configured with a parameter.

drive-strength takes as argument the target strength in mA.
input-debounce takes the debounce time in usec as argument or 0 to disable debouncing
slew-rate takes as argument an integer value (unit seems to be unspecified)

If we want to stay true to the promise that Zephyr DTS description is compatible with Linux DTS then we would need to configure these parameters via a dedicated functions taking respected parameter as an argument. The GPIO_INPUT_DEBOUNCE flag would need to be removed. Setting drive strength in mA doesn't seem to be very practical, on the other hand that's probably the only way to do it in a generic way. We could provide some SoC specific convenience macros that would encode available drive strengths in mA as an easy to understand name.

It's unclear whether the flags used in the device-tree gpios composite's flags field are to be the same as the corresponding argument to a GPIO driver configuration function, or if some of the flags may only relevant for either device-tree or dynamic configuration.

The DTS configuration has to follow the rules specified in GPIO bindings. These are documented in Linux DTS GPIO bindings.

The rework should clearly define at what point the flags specified in the device tree will be applied: when the GPIO driver is initialized (e.g. to come up in a low-power mode) or when whatever uses the corresponding GPIO is initialized (which would likely be a very different configuration). It may be useful to provide multiple sets of configuration flags for a specific GPIO, perhaps by leveraging the PINMUX concept.

According to the Linux DTS automatic configuration of GPIO pins is achieved by means of gpio-hog property.
The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
providing automatic GPIO request and configuration as part of the
gpio-controller's driver probe function.

That's independent from GPIO API but surly needs to be clarified.

Functions in the new GPIO and PINCTRL driver API should clearly document exactly what is meant by each flag, and exactly what behavior is expected from drivers that are given flags that represent a configuration that is not supported by the hardware (ignore, error, make up something, ...). The existing solution failed to do this, and the results have been unsatisfactory.

Yes, fully agree. This should be taken care of in the PR.

GPIO_ACTIVE_LOW, GPIO_ACTIVE_HIGH: indicate pin active state (logical value '1' in low state or logical value '1' in high state)

If this is the output configuration it should be renamed to GPIO_OUTPUT_ACTIVE_LOW/HIGH to avoid any misinterpretation.

The flag is honored by gpio_pin_write and gpio_pin_read functions. I've clarified the description.

GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE: configure single ended pin driving mode

How is push/pull operation configured?

By default (no flags) output is configured in push/pull mode. I've updated the description.

Why not have a set of generic debounce times that may fit a lot of SoCs (e.g. DEBOUNCE_NONE, DEBOUNCE_SHORT, DEBOUNCE_MEDIUM, DEBOUNCE_LONG). What short/ medium/ long means is dependent on the SoC and may even be specified in the DTS.

I discuss the configuration of debounce time in the previous comment.

Linux DTS does not specify interrupt configuration within GPIO/PINCTRL node but rather a dedicated IRQ chip node. Zephyr GPIO API shall provide means to directly configure interrupts. Following flags are proposed:

GPIO_INT_EDGE_RISING
GPIO_INT_EDGE_FALLING
GPIO_INT_EDGE_BOTH
GPIO_INT_LEVEL_LOW
GPIO_INT_LEVEL_HIGH

GPIO_INT_EDGE_BOTH is just a waste of configuration space, it should be the combination of the GPIO_INT_EDGE_RISING and GPIO_INT_EDGE_FALLING flags.

Indeed, that was not well explained. I propose to have to have two sets of flags. The base set used by the drivers, fully sufficient to configure an interrupt. Since their usage may not be intuitive to the end user / may involve too much typing the second set are convenience flags. This is a single identifier with a straightforward name which combines and may be used in place of a set of base flags. I've updated the description.

@mnkp
I am still concerned about the flags GPIO_ACTIVE_* and their influence on gpio_pin_write and gpio_pin_read functions. As I already mentioned in https://github.com/zephyrproject-rtos/zephyr/pull/12651#discussion_r254328542, I think it would be better to keep the current behavior of gpio_pin_write and gpio_pin_read, and to handle these flags outside of GPIO drivers. My main concern is the inconsistency between reading/writing the state of pins and configuring interrupts for them (I assume from your previous comment in this topic that interrupt triggers should still operate only on physical input levels). I think this will be just confusing for people - one will configure an interrupt to be generated on the raising edge on a pin, and the state reported for this pin in the interrupt handler will be either 1 or 0, depending on the GPIO_ACTIVE_* flag used in this pin configuration. And to properly configure the interrupt to occur when the input changes its state to active, one would still need to use the same GPIO_ACTIVE_* flag that was used when the pin was configured (and a piece of code that will handle it, so probably it would be convenient to provide a wrapper for this in GPIO API).
You replied to my comment:

I provided a bit more elaborate answer in my comment in #11880. In short GPIO_ACTIVE_LOW is just a different name for GPIO_POL_INV flag which controls the value returned by gpio_pin_write and gpio_pin_read functions.

I am not convinced that GPIO_ACTIVE_LOW in its current form is just a replacement for GPIO_POL_INV. As I understand it, the inversion of polarity should affect a given pin in all aspects, including the configuration of interrupts, just as if there was a hardware inverter connected to the pin. I tried to look at how the polarity inversion is handled in hardware currently supported by Zephyr's GPIO drivers:

for Semtech SX1509B, polarity affects the relation between IO[x] and RegData[x], and the interrupt configuration is based on RegData[x], so it is influenced by the used polarity
for TI CC13x0 and CC26x0, the documentation says only that the input/output can be configured as inverted, and interrupts can be generated for positive and/or negative edges on the IO, so I cannot tell what will be the actual behavior, and I don't have a piece of such hardware to check it (later on, for PWMs it is mentioned that output inversion affects the edge detection interrupts, but I'm not sure if any assumptions regarding GPIOs can be based on this)
for ESP32 again, I cannot tell from the documentation whether GPIO interrupts are generated for pin levels before or after the inversion is applied
for PCAL9535A, only the input pins can be inverted and the simplified schematic of the I/Os shows that the polarity inversion only affects the input port register data, it is not taken into account in the interrupt generation path
other drivers either do not support the flag or support it in software

And now I'm really puzzled regarding what would be the best way to handle GPIOs polarity inversion. 🙂
Could anyone provide other examples of hardware supporting this feature, or provide any other hints?
Anyway, I still think that the influence of the GPIO_ACTIVE_LOW flag on the behavior of gpio_pin_write and gpio_pin_read functions should be reconsidered.

Hi @mnkp, I wanted to clarify my remarks about fast access functions during today's meeting.
I think that the _raw variants are good and should be included. The issue I am considering is a separate one that would be an enhancement to your existing work.
My main point is that it would also be useful for other device drivers that need fast access to GPIOs built into the SoC to have a generic API for accessing the output registers for these devices.
In other words, something like this:
struct device *gpio_port = device_get_binding(...);
u32_t *output_register;
u32_t my_bit = 3U;

gpio_get_output_register(gpio_port, &output_register);
*output_register |= (1U << my_bit);

To be equivalent to:
struct device *gpio_port = device_get_binding(...);
gpio_pin_write_raw(gpio_port, 3U, 1U);

except without the overhead, so that the bit manipulation on output_register could be done in a tight loop.
The inspiration is from the FastLED library's pin abstraction (https://github.com/FastLED/FastLED/blob/master/fastpin.h; also see PORTING.md in the same repository), which works on a variety of Arm SoCs and AVRs at the very least.
Of course, there are problems to consider:

not all GPIO devices support this: SoCs may not have a GPIO port with this type of register, I2C-based GPIO expanders don't have this type of access, etc. But it is a common enough pattern that I think it would be useful to allow GPIO drivers to implement it, and gpio_get_output_register() can always return an error when it's not available. This would make it easier to write efficient drivers for timing sensitive bit-banging protocols when possible, without re-writing SoC-specific versions that duplicate GPIO driver code as we do today in e.g. https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/led_strip/ws2812b_sw.c.
concurrent access to output_register and the GPIO APIs may be an issue as well. I think this is the responsibility of the driver author or application to avoid. And anyway, in designs where only a single core is accessing the GPIO port (the common case), accesses to output_register are likely to be done with interrupts disabled to ensure timing determinism.

Your thoughts are welcome. Thanks.

@mbolivar thanks for the proposal.
I was hoping that removing the access_op from GPIO API would improve things significantly. It does improve things but there is still a fair share of pointer dereferencing going on. To test it I've implemented gpio_pin_write_raw on SAM E70 (ARM Cortex-M7) SoC which is a very friendly chip to work with.
static int gpio_sam_pin_write_raw(struct device *dev, u32_t pin, u32_t value)
{
	const struct gpio_sam_config * const cfg = DEV_CFG(dev);
	Pio *const pio = cfg->regs;

	if (value) {
		/* Set the pin. */
		pio->PIO_SODR = 1 << pin;
	} else {
		/* Clear the pin. */
		pio->PIO_CODR = 1 << pin;
	}
	return 0;
}

with default Zephyr compiler optimization options the implementation takes 11 assembly instructions (for comparison the gpio_sam_pin_write function takes 32 assembly instructions. Since there is also some overhead for calling the function to have truly fast GPIO access we definitely need to considered the type of API you mentioned.
I believe though that letting an application directly access the output_register will not be possible. There are SoCs that provide only output_set, output_clear registers. There are SoCs that provide only output_write register. There are SoCs that provide both. The internal layout of the registers is also not always consistent. We would probably need a set of inline functions which would present a consistent API but be implemented individually by the SoC. Similar to your proposal but writing to the register would happen via an inline function. We would need to rely on CMake to include the right header (and in this case also implementation) file.

I believe though that letting an application directly access the output_register will not be possible. There are SoCs that provide only output_set, output_clear registers. There are SoCs that provide only output_write register. There are SoCs that provide both. The internal layout of the registers is also not always consistent.

Yes, I understand this is not a universally supported register type. However, I believe that the existence of the fastled library shows that there is a small set of "types" of GPIO output registers, which we can support through a common API. E.g. if gpio_get_output_register errors out, the driver could fall back on gpio_get_output_set_register(), gpio_get_output_clear() register, etc., with coverage level depending on the driver. We could consider a query routine where the GPIO driver returns a bitmask of supported types.

We would probably need a set of inline functions which would present a consistent API but be implemented individually by the SoC. Similar to your proposal but writing to the register would happen via an inline function. We would need to rely on CMake to include the right header (and in this case also implementation) file

I'm not sure I can see clearly how some of these details would work in practice, but I look forward to seeing more details if you have them.
Thanks for your response!

@mnkp Regarding the question I was trying to signal yesterday on slack. It's about configuring interrupts for handling a button, for instance. An application will get the flags defined for the button in DTS through a a generated macro, like SW0_GPIO_FLAGS. Ideally, it would just pass the value to the gpio_pin_configure function to get the pin properly configured, just like in the case of the LED that you presented in your PR. But the flags controlling the interrupts generation are application specific - some applications will need to react on the input becoming active (button pressed), others on the input becoming inactive (button released), and in some cases, perhaps not buttons, there may be a need to react on the signal level, not an edge. Thus, I think that the flags related to interrupts should not be specified in DTS (like in your PR), but instead the GPIO API should provide some means to get the proper interrupt configuration based on the GPIO_ACTIVE_* flag used in DTS. Hence, I thought that we would need to add some macros or inline functions that would handle the translation. Or do you have some other vision of achieving this?

After taking another look, I've got one more doubt. Why do we change the required behavior of gpio_pin_{read|write} functions so that they now are to operate on the logic level and then we introduce gpio_pin_{read|write}_raw functions that are to behave just like gpio_pin_{read|write} were supposed to so far?
Wouldn't it be clearer/safer to only introduce new functions that take into account the GPIO_ACTIVE_LOW flag? Possibly with names clearly indicating this, for instance gpio_pin_{activate|deactivate|is_active} or gpio_pin_{assert|deassert|is_asserted} as @pabigot proposed earlier in his PR.

I think that the flags related to interrupts should not be specified in DTS (like in your PR), but instead the GPIO API should provide some means to get the proper interrupt configuration based on the GPIO_ACTIVE_* flag used in DTS.

The current interrupt configuration done in the Zephyr version of the DTS is not standard and indeed it may be best to remove it. We can always add it back in the future, possibly in a standard form, if the need arises. The easiest way to have the application configure interrupts in a portable way is to define them in terms of pin active, inactive state as in: LEVEL_INACTIVE, LEVEL_ACTIVE, EDGE_TO_ACTIVE, EDGE_TO_INACTIVE.
A general remark regarding DTS:
According to the documentation DTS is meant to provide information about hardware the OS runs on as well as its initial configuration for the boot process. Thus uart DTS node contains register addresses of the UART module as well as the initial baud rate. The application is free to change the configuration later. It's actually OK to add application specific bits to the DTS.

After taking another look, I've got one more doubt. Why do we change the required behavior of gpio_pin_{read|write} functions so that they now are to operate on the logic level and then we introduce gpio_pin_{read|write}_raw functions that are to behave just like gpio_pin_{read|write} were supposed to so far?

I'll copy paste my answer from #12651.

I provided a bit more elaborate answer in my comment in #11880. In short GPIO_ACTIVE_LOW is just a different name for GPIO_POL_INV flag which controls the value returned by gpio_pin_write and gpio_pin_read functions. Unfortunately, the documentation of these functions did not state it explicitly. The only reason we rename the GPIO_POL_INV flag to GPIO_ACTIVE_LOW is to be compatible with the definition of DTS gpio node in Linux.

In short we don't change the behavior of gpio_pin_{read|write} functions. We rename the GPIO_POL_INV flag to match Linux DTS and clarify its usage.

In short we don't change the behavior of gpio_pin_{read|write} functions. We rename the GPIO_POL_INV flag to match Linux DTS and clarify its usage.

I cannot entirely agree with that. As I recall, one of the reasons for making this GPIO flags cleanup was the need to replace GPIO_INT_ACTIVE_{HIGH|LOW} flags used in DTS files to define the active state of buttons and LEDs with something more appropriate (see #10339 and its predecessor #10300). In this context, when we replace GPIO_INT_ACTIVE_LOW with GPIO_ACTIVE_LOW we change the behavior of gpio_pin_{read|write} functions.
See for instance the basic button sample. It takes the flags defined in DTS for the button with sw0 alias and passes them directly to gpio_pin_configure. After GPIO_INT_ACTIVE_LOW is replaced with GPIO_ACTIVE_LOW, this call to gpio_pin_read will give the opposite result than it does currently. The read value is only printed here, so it is not a big deal, but I'm afraid that we may encounter cases with more serious consequences of such change (related to incorrect driving of CS pins, for example). Do you think it is possible to catch them all while applying the proposed changes in GPIO flags?

@mnkp @anangl
My suggestion here would be to:

Deprecate GPIO_POL_INV so that we get rid of the pseud-logical behavior of the read/write functions
Leave gpio_pin_read/write as they are, physical and using the *value
Add 4 new functions, all using __ASSERT():

bool gpio_pin_get(*port, pin) which returns the logical value as a return param
void gpio_pin_set(*port, pin, value)
u32_t gpio_port_get(*port)
void gpio_port_set(*port, mask)

@carlescufi
I was thinking about similar names for these new functions, but I wasn't sure if _get and _set would not be too general, so I thought that maybe _state_{get|set} could work, but actually these didn't convince me fully either. And so far I couldn't come up with anything better.
Anyway, your proposal looks good to me. With one correction, gpio_port_set should take 3 parameters: (*port, pin_mask, value), so that one could set states of pins from the group specified by pin_mask to desired states (active or inactive) as defined by the bits in value.

@anangl @carlescufi gpio_pin_{assert,deassert} as with https://github.com/zephyrproject-rtos/zephyr/pull/11880#issuecomment-459641859?  I believe it's understood that "assert" means logic true and "deassert" logic false.
In any case, I think you're running into the same problems that killed #11880: we can be backward compatible, or we can match Linux/DTS API.  Because GPIO_POL_INV wasn't clearly defined and implemented consistently across implementations we can't do both.
Or so I believe.  I'm not sure everybody believes they're incompatible, and if they are I don't know that there's agreement on which requirement should take priority.  If not, that should be clearly settled first.

@pabigot @anangl @mnkp
Now we're getting into personal preference territory, but I honestly think that assert,deassert is less clear than get,set. Looking at other APIs I can also propose:

bool gpio_pin_get_level(*port, pin) which returns the logical value as a return param
void gpio_pin_set_level(*port, pin, value)
u32_t gpio_port_get_levels(*port)
void gpio_port_set_levels(*port, mask)

that way we match the classical "active level low/high` way of describing the logical levels

Thanks @carlescufi for the proposal. Nice selection!
Since we are getting into personal preference territory regarding naming I'll make my statement. I like very much the first proposal: gpio_pin_get, gpio_pin_set, gpio_port_get, gpio_port_set. The function names are short and to the point. They should become the most used GPIO API functions so it's better to keep them short. IMHO the level variants all read well but there is no added value, we only make the name longer.

While I agree with @pabigot that gpio_pin_{assert,deassert} would indicate the purpose of these functions in perhaps the clearest way, I see a disadvantage of such approach. We'd have separate functions for setting active and inactive pin levels, while set handles both cases. I think it matters especially for ports, where it will be convenient to have the possibility of setting a selected group of pins to different levels in one call.
And I agree with @mnkp that the get,set proposal seems to be the best one. But still, shouldn't the gpio_port_set function take the third parameter with values to set for the pins specified by the mask (as I already tried to signal above)? Or do I misunderstand something?

shouldn't the gpio_port_set function take the third parameter with values to set for the pins specified by the mask (as I already tried to signal above)? Or do I misunderstand something?

Yes, the port functions should include an extra parameter

u32_t gpio_port_get(*port, mask)
void gpio_port_set(*port, mask, value)

Yes, the port functions should include an extra parameter

I'm not sure about gpio_port_get. Callers of the function can mask the obtained value on their own, if needed. Do you see some additional benefit of masking the value inside the driver?

Yes, the port functions should include an extra parameter

I'm not sure about gpio_port_get. Callers of the function can mask the obtained value on their own, if needed. Do you see some additional benefit of masking the value inside the driver?

I believe it will make the API more consistent and easier to use.

Yes, the port functions should include an extra parameter

I'm not sure about gpio_port_get. Callers of the function can mask the obtained value on their own, if needed. Do you see some additional benefit of masking the value inside the driver?

I believe it will make the API more consistent and easier to use.

I've updated port_set() to take a value.
I have no preference regarding port_get().

I believe it will make the API more consistent and easier to use.

I just thought it might be considered an unnecessary overhead when there would be no need of any masking at this point (for example, when there are more groups of pins in this port which need to be later on masked separately). But that's fine for me. Consistency is important, too.

If you do:

u32_t gpio_port_get(*port)
void gpio_port_set(*port, set_bits, clear_bits)

you don't need need the mask on the read, and you get a slightly more powerful operation that I personally think is more clear than "set to this value, oh, but ignore everything but these bits".  (I use this in my APIs, with the semantics that a bit set in both set_bits and clear_bits is inverted from whatever its previous value was.  Very useful for flashing LEDs.)
Just another opinion.

u32_t gpio_port_get(*port)
void gpio_port_set(*port, set_bits, clear_bits)

I like this proposal for the port, thoughts @mnkp and @anangl ?

u32_t gpio_port_get(*port)
void gpio_port_set(*port, set_bits, clear_bits)

I like this proposal for the port, thoughts @mnkp and @anangl ?

Looks reasonable. These parameters will actually directly provide values that will be written to hardware registers in many drivers. And we still can provide the functionality of setting (*port, mask, value) with some wrapper if it turns out to be useful for cases that utilized gpio_port_write previously, like this one.
I like it, too.

u32_t gpio_port_get(*port)
void gpio_port_set(*port, set_bits, clear_bits)

I like this proposal for the port, thoughts @mnkp and @anangl ?

Interesting. I'll need to have a look at how such an API plays with bit-banging implementations on the application level. There should be a few in Zephyr codebase. For now in the PR I'm preparing I'll implement pin versions only. It's going to be a lot of work anyway. Now that we've chosen the names we can add port versions later.

My main point is that it would also be useful for other device drivers that need fast access to GPIOs built into the SoC to have a generic API for accessing the output registers for these devices.

@mnkp @pabigot to follow up on our brief discussion today, I thought I would look at all the existing GPIO drivers and see what types of registers they use. From there, I think we can see more clearly what this would look like in practice.
Here are my results (plain text formatted). Comments/corrections welcome; I did this by inspection:
Register type glossary
======================

bit set/clr
    distinct set and clear registers.

    set register: write 1 to a bit to set pin to active, writes of 0
    are ignored.

    clear register: write 1 to a bit to set pin to inactive, writes of 0
    are ignored.

input
    one-pin-per-bit readable data register; this may be the same as
    the output register

other
    pin access register is not any of the other types in this section

output
    one-pin-per-bit writeable data register; this may be the same as
    the input register

pin
    write some value to the register to set pin to active, another to
    inactive; i.e. writes to a register affect one pin only, and are
    not one-pin-per-bit

N/A
    reads or writes are not supported or not done with MMIO registers

Zephyr GPIO driver register types
=================================

Columns:

- No.: number
- Driver: driver name in zephyr/drivers/gpio
- "BSC": has bit set/clr register ("X" = yes, " " = no)
- O: has output register
- I: has input register
- Other: other register types and footnotes

No. Driver		  BSC O I    Other
--- --------------------  --- - -    -----
 0. gpio_altera_nios2.c   X   X X    [1]
 1. gpio_atmel_sam3.c     X     X
 2. gpio_cc13xx_cc26xx.c  X     X    pin [2]
 3. gpio_cc2650.c         X     X
 4. gpio_cc32xx.c             X X
 5. gpio_cmsdk_ahb.c          X X
 6. gpio_dw.c             X     X
 7. gpio_esp32.c          X     X
 8. gpio_gecko.c          X   X X    [4]
 9. gpio_ht16k33.c                   special-purpose I2C led driver
10. gpio_imx.c                X X
11. gpio_intel_apl.c                 pin input and output
12. gpio_mchp_xec.c           X X
13. gpio_mcux.c           X   X X    [5]
14. gpio_mcux_igpio.c         X X
15. gpio_mcux_lpc.c             X    pin/other output [6]
16. gpio_mmio32.c             X X
17. gpio_nrfx.c           X   X      [7], for input see [8]
18. gpio_pcal9535a.c                 N/A [9]
19. gpio_qmsi.c           X     X
20. gpio_qmsi_ss.c		     other? [10]
21. gpio_rv32m1.c         X   X X    [11]
22. gpio_sam0.c           X   X X    [12]
23. gpio_sam.c            X     X
24. gpio_sch.c            X     X    in some configurations only [13]
25. gpio_sifive.c             X      other input [8]
26. gpio_stellaris.c          X X
27. gpio_stm32.c          X   X X    [14]
28. gpio_sx1509b.c                   N/A [9]

[1] driver uses bit set/clr; but output register exists per Intel UG 01085
    <IP_ADDRESS>. ("data Register")

[2] driver uses bit set/clr; in
    zephyr/ext/hal/ti/simplelink/source/ti/devices/cc13x2_cc26x2/driverlib/gpio.h,
    GPIO_WriteDio() shows pin control register exists

[3] this is at least an input register; unclear to me if it's a data
    register

[4] driver uses bit set/clr, but output exists per 32.5.4 in
    https://www.silabs.com/documents/public/reference-manuals/EFM32WG-RM.pdf

[5] driver uses bit set/clr, but PDOR also referenced and seems to be an
    output register for compatible devices, see e.g. K64P144M120SF5RM
    55.2.1 Port Data Output Register (GPIOx_PDOR)

[6] "other": driver uses contiguous byte-sized per-pin registers.
    However, UM10914 11.5.2 GPIO port word pin registers describes
    individual pin control registers

[7] driver uses bit set/clr, nrf_gpio.h shows nrf_gpio_port_out_write()

[8] values from multiple registers are combined depending on pin's
    directionality; could be simplified if we assume input mode

[9] I2C GPIO expander

[10] from ARC-related comments and
     modules/hal/qmsi/drivers/gpio/qm_ss_gpio.c, it looks like this
     may be non-MMIO registers

[11] driver uses bit set/clr, but PDOR exists as in gpio_mcux.c
     (looks like same/similar IP)

[12] driver uses bit set/clr, but
     zephyr/ext/hal/atmel/asf/sam0/include/samd20/component/port.h
     declares PORT_OUTSET_Type as R/W

[13] there's a "legacy" I/O port access type in some configurations

[14] driver uses bit set/clr, but every ST part I've ever seen has an
     ODR (output data register) per-port which can also be used

From this, I think it's clear that if we provide "write register" accessors for both bit set/clr registers and output registers, as well as one "read register" accessor, we can cover almost every interesting case.
The write register APIs could look something like this:
/**
 * @brief Get a GPIO port's output register.
 *
 * Bits in the output register correspond to individual pins. Setting
 * a bit makes the pin active, and clearing it makes it inactive.
 *
 * @param dev GPIO device to get a reference to the output register for
 * @param output_reg on success, *output_reg contains the output register's address
 *
 * @return 0 on success, -ENOTSUP if not supported by this device.
 */
int gpio_get_output_register(struct device *dev, uintptr_t *output_reg);

/**
 * @brief Get a GPIO port's bit set register address.
 *
 * Bits in the bit clear register correspond to individual
 * pins. Writing 1 to a bit a bit makes the pin active; writes of zero
 * are ignored.
 *
 * @param dev GPIO device to get a reference to the bit set register for
 * @param bit_set_reg on success, *bit_set_reg contains the bit set register's address
 *
 * @return 0 on success, -ENOTSUP if not supported by this device / pin.
 */
int gpio_get_bit_set_register(struct device *dev, uintptr_t *bit_set_reg);

/**
 * @brief Get a GPIO port's bit clear register address.
 *
 * Bits in the bit clear register correspond to individual
 * pins. Writing 1 to a bit a bit makes the pin active; writes of zero
 * are ignored.
 *
 * @param dev GPIO device to get a reference to the bit clear register for
 * @param bit_clr_reg on success, *bit_clr_reg contains the bit clear register's address
 *
 * @return 0 on success, -ENOTSUP if not supported by this device / pin.
 */
int gpio_get_bit_clear_register(struct device *dev, uintptr_t *bit_clr_reg);

On the output side, driver authors would need to try both gpio_get_output_register() and gpio_get_bit_set_register() / gpio_get_bit_clear_register() as appropriate for the use case. For quick hacks or applications that know which one their SoC supports, you could just call the right one.
On the input side, a single gpio_get_input_register() seems to cover all the drivers where something like this is possible.

I would like to shortly revisit our decision on naming functions that read/write pin logical level. Currently we have gpio_pin_get, gpio_pin_set and I argued to keep it this way. However, to implement fast access GPIO functions as proposed by @mbolivar we will likely need to add a new function to the API, something like gpio_pin_get_register or gpio_pin_get_descriptor. And in this case maybe it will be better to use the _level variants of pin_get, pin_set functions (to easier distinguish the two) as proposed by @carlescufi i.e. use gpio_pin_get_level, gpio_pin_set_level functions. Linux API is using gpiod_get_value, gpiod_set_value names.

And in this case maybe it will be better to use the _level variants of pin_get, pin_set functions (to easier distinguish the two) as proposed by @carlescufi i.e. use gpio_pin_get_level, gpio_pin_set_level functions.

I would prefer to avoid using the term "level" in the API identifiers.  AFAICT the API in #16648 has the traditional gpio_pin_read which operates on the line (electrical/physical) level and new gpio_pin_get which operates on the logical level.  Both of them are levels, so adding _level does not help the user to understand what the function does.
If this is for the "fast" version of the API I'd rather see that as a separate, parallel API with a different prefix, e.g. gpiof_pin_read(), just as Linux gpiod_get_value(&gpio_desc) is for a descriptor based API that replaces the legacy gpio_get_value(unsigned).

If you do:

u32_t gpio_port_get(*port)
void gpio_port_set(*port, set_bits, clear_bits)

you don't need need the mask on the read, and you get a slightly more powerful operation that I personally think is more clear than "set to this value, oh, but ignore everything but these bits". (I use this in my APIs, with the semantics that a bit set in both set_bits and clear_bits is inverted from whatever its previous value was. Very useful for flashing LEDs.)

How is the masked write not clear? It corresponds directly to hardware implementations with explicit set and clear port registers.
I don't see how a bit set in both set_bits and clear_bits should mean to invert it.
I think I'd rather see something like:
void gpio_port_set(*port, set_bits)
void gpio_port_clear(*port, clear_bits)

And if you really want an invert, you can add:
void gpio_port_invert(*port, invert_bits)

So that'd be:
u32_t gpio_port_read(port); // line level
u32_t gpio_port_get(port);  // logic level
void gpio_port_write(port, value); // line level, all bits
void gpio_port_set1(port, value);  // logic level, all bits
void gpio_port_set(port, set_bits); // logic level, only specified bits
void gpio_port_clear(port, clear_bits); // logic level, only specified bits
void gpio_port_invert(port, invert_bits); // logic level, only specified bits

Other than the naming conflict when both line and logic level operations are supported I don't have a big problem with this.   The original motivation for the API I proposed was to resolve the conflict when having a mask parameter to the set operation suggested there should be a corresponding mask in the get operation.

Here is my proposal based on everything that has been said so far, and taking into account the following:

Simplicity and consistency

Anything returning an int can return:

A negative value (error)
0 (logical false, physical low)
A positive value (logical true, physical high)

There is no easy solution for returning errors on port reads, so revert to using __ASSERT() there

Note that due to
Standard APIs:
/** Pin access **/
/* Logical */
int gpio_pin_get(*port, pin);
int gpio_pin_set(*port, pin);
/* Physical */
int gpio_pin_get_raw(*port, pin);
int gpio_pin_set_raw(*port, pin);

/** Port access **/
/* Logical */
u32_t gpio_port_get(*port); // assert on error
u32_t gpio_port_get_masked(*port, mask); // assert on error
int gpio_port_set(*port, value); // writes the value to the port
int gpio_port_set_masked(*port, value, mask); // writes the value to the port, only non-masked bits
int gpio_port_set_bits(*port, set_bits);
int gpio_port_clear_bits(*port, clear_bits);
int gpio_port_invert_bits(*port, invert_bits);

/* Physical */
u32_t gpio_port_get_raw(port); // assert on error
u32_t gpio_port_get_masked_raw(*port, mask); // assert on error
int gpio_port_set_raw(*port, value); // writes the value to the port
int gpio_port_set_masked_raw(*port, value, mask); // writes the value to the port, only non-masked bits
int gpio_port_set_bits_raw(*port, set_bits);
int gpio_port_clear_bits_raw(*port, clear_bits);
int gpio_port_invert_bits_raw(*port, invert_bits);

Fast/descriptor-based APIs:
/* Get a descriptor */
struct gpiod_t* gpiod_get(*port);

The rest of APIs should be exactly the same as the standard APIs but:
- Replacing gpio_ with gpiod_ as a prefix
- Replacing the first port parameter with struct gpiod_t*

I don't believe we have consensus on the port set API.  There have been three proposals:
// API 1
int gpio_port_set_masked(*port, value, mask); // writes the value to the port, only non-masked bits
// API 2
int gpio_port_set_sct(*port, set_bits, clear_bits); // sets some bits, clears some bits, toggles if both requested
// API 3
int gpio_port_set_bits(*port, set_bits); // sets specified bits
int gpio_port_clear_bits(*port, clear_bits); // clears specified bits
int gpio_port_invert_bits(*port, toggle_bits); // TBD: changes level of specified bits

(1) is existing practice, so should be the fallback if we can't agree on a change.  (2) seemed to get some approval and interest, but one rejection.  (3) hasn't really been discussed.
I prefer (2), because the set-clear-toggle bit mutation operation has general applicability for flags and register values outside of GPIO, and I am going to use it in other situations where it's more clear. I could live with the others.
So how about we vote?  I'm going to post separate comments for each choice; sorry for the blitz.  Click thumbs-up to prefer this API.  Click thumbs-down if you think it's an absolutely horrible idea and would want to block a PR that includes it.  Vote up on one choice, and down on any of them you want.  We'll figure out how to tally the votes when we have some.

Click thumbs-up to prefer this API.  Click thumbs-down if you think it's an absolutely horrible idea.
// Multi-pin mutate operation API 1
int gpio_port_set_masked(*port, value, mask); // writes the value to the port, only non-masked bits

Click thumbs-up to prefer this API.  Click thumbs-down if you think it's an absolutely horrible idea.
// Multi-pin mutate operation API 2
int gpio_port_set_sct(*port, set_bits, clear_bits); // sets some bits, clears some bits, toggles if both requested

Click thumbs-up to prefer this API.  Click thumbs-down if you think it's an absolutely horrible idea.
// Multi-pin mutate operation API 3
int gpio_port_set_bits(*port, set_bits); // sets specified bits
int gpio_port_clear_bits(*port, clear_bits); // clears specified bits
int gpio_port_invert_bits(*port, toggle_bits); // TBD: changes level of specified bits

Previously we agreed that the pin set / get functions should be defined as
bool gpio_pin_get(*port, pin);
void gpio_pin_set(*port, pin, value);

i.e. they were not returning error codes. That's fine for the SoC GPIOs but as @pabigot mentioned during API meeting we need to support also external GPIOs, e.g. connected via I2C bus. So it looks like we do need to add error codes to set/get functions. That's easy for the pin version of the functions, as proposed by @carlescufi.
int gpio_pin_get(*port, pin);
int gpio_pin_set(*port, pin, value);

However, we can't rely on the assert for the port version of the functions as we're talking here about allowed runtime errors. E.g. an error on the I2C bus that prevents the gpio_port_get_masked from being correctly executed. I'm afraid in this case we will need to return the port value by a parameter, as in
int gpio_port_get_masked(*port, mask, *value);

Click thumbs-up to prefer an API that combines AP1 and API3.  Click thumbs-down if you think it's an absolutely horrible idea.
// Multi-pin mutate operation API 1
int gpio_port_set_masked(*port, value, mask); // writes the value to the port, only non-masked bits
// Multi-pin mutate operation API 3
int gpio_port_set_bits(*port, set_bits); // sets specified bits
int gpio_port_clear_bits(*port, clear_bits); // clears specified bits
int gpio_port_invert_bits(*port, toggle_bits); // TBD: changes level of specified bits

Reviewing some of the material above there's another consensus decision that needs to be summarized: handling of line vs logic level taking into account GPIO and interrupt configuration and the impact of adding line/level API on the use of existing GPIO_POL_* flags.  Every bulleted item below is intended to be either a definition or a requirement that together determine whether an implementation of the API is conforming.
A clarified terminology summary from the pin/port access API summary above:

Line levels are defined in a peripheral-specific way by comparing voltages against thresholds, and are provided by the peripheral as a binary value.
Valid line levels are high (positive) and low (zero).
Valid logic levels are true/1/asserted (positive) and false/0/deasserted (zero).
Unknown/error state for both levels are represented by negative integers.

Logic level derives from line level based on a configured active level:

A pin is configured ACTIVE_HIGH if and only if it is not configured ACTIVE_LOW.

I.e. active level is a binary state.   Informally, if a pin is configured active high the value representations of  logic level and line level are equivalent; otherwise the logic level is the inverse of the line level.  In support of formalizing this, define these two functions for any pin p within the device:

Let ACTLOW(p) return:

true when p is pin configured ACTIVE_LOW;
false when p is pin configured ACTIVE_HIGH;

Let LEVCONV(p, lev) return:

(lev == 0) XOR ACTLOW(p) if lev is a valid level (i.e. non-negative);
lev if lev is an unknown/error state (negative)

where standard C conversion between integer and boolean value spaces is assumed and XOR is boolean exclusive or.
We have also introduced a distinction between GPIO mode and interrupt mode for a pin.  Using the proposed API of #16648:

A pin that was last configured by gpio_pin_configure() is a GPIO-controlled pin.
A pin that was last configured by gpio_pin_interrupt_configure() is an interrupt-controlled pin.
GPIO API functions other than gpio_pin_configure() are disallowed and shall return -ENOTSUP if invoked on interrupt-controlled pins.
Interrupt API functions other than gpio_pin_interrupt_configure() are disallowed and shall return -ENOTSUP  if invoked on GPIO-controlled pins.
On driver startup every pin must be configured as either GPIO-controlled or interrupt-controlled.

This summarizes my understanding of what we've decided; again, this needs to be validated.
The effect of active level on pin mode is specified by this rule:

The active level configuration of a pin affects API behavior for both GPIO-controlled and interrupt-controlled pins.

My recollection is that in early discussions this was not true (possibly because it was mixed with GPIO_POL_INV), so we need to confirm or reject this interpretation.
Abstracting away from public API names we have an inspect operation get and a mutate operation set, where the unadorned name operations on logic levels and a suffix _raw operates on line levels.  The fundamental get_raw function defines the behavior of an internal inspection of pin state within the target, regardless of whether the pin is GPIO or interrupt controlled.  For GPIO-controlled it is equivalent to the exposed GPIO function; for interrupt-controlled its defined behavior is used to configure the interrupt conditions.
Proposed detailed semantics for get_raw(p) for any pin p are:

If a pin is configured to enable input, get_raw(p) returns the line input level for p sampled/provided by the GPIO peripheral; otherwise
If a pin is configured to enable output, get_raw(p) returns the line output level configured for p in the GPIO peripheral; otherwise
get_raw returns (TBD) -EINVAL

NOTE: The requirements above are carefully worded to specify the behavior when a pin is configured for both input and output.  There are devices (e.g. SX1509B) where bidirectional configuration is supported and the input signal may be different from the configured output signal.  This proposed behavior must be validated, because it fails to provide a way to read the configured output of a signal that is bidirectional.  Also note that this requires that a driver be able to provide the last configured output value; it's possible some peripherals don't provide a way to read that back.
With the above, we then have:

get(p) is LEVCONV(p, get_raw(p)) in all situations.

Where "all situations" covers GPIO and interrupt configuration, direction, and active level.
For mutation operations:

set_raw(p, v) shall:

set the output signal to high and return TBD if v is line level high;
set the output signal to low and return TBD if v is line level low;
return -EINVAL if v is an unknown/error level

set(p, v) shall be equivalent to set_raw(p, LEVCONV(p, v)) in all situations.

Finally we need the following to deal with the legacy parts of the API:

GPIO_POL_NORMAL shall have the same effect as GPIO_ACTIVE_HIGH
GPIO_POL_INV shall have the same effect as GPIO_ACTIVE_LOW
These flags shall not be used independently to control an underlying hardware peripheral pin inversion capability.  A hardware capability may be used to implement ACTIVE_LOW as long as the API requirements are satisfied.

Without this people may continue to use these flags to enable peripheral-specific inversion capabilities, resulting in cross-platform inconsistencies.  (I would rather retain these flags and specify that their use has a target-specific impact on the behavior of getraw() and setraw(), but I don't think that's the consensus position.)

@pabigot
Two doubts from my side.

Regarding get_raw(p). Is this bullet:

If a pin is configured to enable output, get_raw(p) returns the line output level configured for p in the GPIO peripheral; otherwise

really necessary, will such functionality be useful? Maybe we could remove it and hence simplify the API by allowing using get_raw(p) only for pins with enabled input?

Regarding GPIO- vs interrupt-controlled pins.

A pin that was last configured by gpio_pin_configure() is a GPIO-controlled pin.
A pin that was last configured by gpio_pin_interrupt_configure() is an interrupt-controlled pin.

I am not convinced that we should distinct such two modes for pins, and basing on them disallow parts of API. I'd rather instead set a requirement for set_raw(p) to return an error code (-EINVAL perhaps) if it is called for a pin that was not configured to enable output, and a similar one for get_raw(p).
I understand the introduced gpio_pin_interrupt_configure as an additional to gpio_pin_configure way of configuring GPIO interrupts, to be used in cases when a pin is not to be controlled via GPIO driver (like the one signaled by @b0661). And I thought this function could be used also for changing only the interrupt configuration for a pin configured previously by gpio_pin_configure.

@anangl Thanks for the careful reading.
For the semantics of interrupt versus GPIO configuration I represented my understanding based on the goal of moving towards PINMUX functionality where interrupt functions are separated (to some degree) from GPIO functions.  From earlier discussions I understood that on some hardware a pin configured to be an interrupt mode may not support GPIO operations.  I haven't encountered that myself, but I defer to @mnkp to precisely define the two roles and the functions used to control them.
For reading the configured output state of a pin: if it is to be possible to toggle a pin state, as with flashing an LED, you need to be able to read the current setting so you know what value to write to change that state.  That could be done by:

(A) providing a facility to read the configured output state in the GPIO API;
(B) providing a facility to toggle the configured output state in the GPIO API; or
(C) requiring anything that wants to toggle maintain the last configured state itself.

In my APIs I usually go with (B), but (C) is OK too and simplifies GPIO.
Thumbs up here to go with (C), removing explicit toggle support from the GPIO API.

@pabigot Both (B) and (C) are OK to me, my point was just to not go with (A). (B) seems to be a bit better option, since there are pieces of hardware providing dedicated registers for toggling (no need to read the output state then). It shouldn't be that hard to agree on how to support toggling in the GPIO API.

It shouldn't be that hard to agree on how to support toggling in the GPIO API.

A minimal impact way to do it is to define toggle as the behavior specified when a bit is set in both the set_bits and clear_bits parameters to the fundamental set-clear operation.  As there were reasonable objections to that based on it being obscure, and I think adding an explicit toggle operation is over-engineering, I still prefer (C).

A minimal impact way to do it is to define toggle as the behavior specified when a bit is set in both the set_bits and clear_bits parameters to the fundamental set-clear operation.

I agree and I think this is a good way to go. Such semantic may seem a bit "exotic" at first glance, but after you think of it a bit, you realize that it is a good way of utilizing a configuration possibility that has to be checked anyway, but instead of returning an error, providing a nice feature for it. To me this is mainly a question of describing it properly in the documentation, so that it is clear to users. What you propose in your first edit seems reasonable.

Edit2: In fact this specification also defines the behavior when the driver knows the operation will not change the current configuration (viz., it must not appear to occur). This is relevant to drivers like SX1509B where an I2C transaction can be eliminated. That tips my vote to (B) provided though this mechanism.

Yes. That convinces me even more that this option is a better choice.

API meeting:
/** Pin access **/
/* Logical level */
int gpio_pin_get(*port, pin);
int gpio_pin_set(*port, pin);
/* Line level */
int gpio_pin_get_raw(*port, pin);
int gpio_pin_set_raw(*port, pin);

int gpio_port_sc_bits(*port, u32_t set_bits, u32_t clear_bits);

I'd suggest:
int gpio_port_set_clr_bits(*port, u32_t set_bits, u32_t clear_bits);

All of the APIs above have a baseline assumption that you are working on a 32-bit machine, and can only set or clear up to 32 bits at a time. what happens when you move to a 64-bit machine? What happens if you are working on a 16-bit native machine, and it has to extend all of the parameters up to 32-bits?  You are passing in 32-bit ints, but getting back native machine ints (which may or may not be 32-bits).

The baseline assumption is that no GPIO device has more than 32 pins.  There's one existing device that has more, and it has to be split into separate devices.
Yes, if there's a 16-bit target this would cause overhead, but Zephyr pretty strongly expects a minimum 32-bit system.  I generally prefer native int types but for a cross-platform system they introduce complexity.
Plain int returns are (or should be) always zero, a boolean, or a negative error code.  Pin sets should always be returned via out parameters.  If that isn't happening, it needs to be fixed.

The int that the gpio_port_* functions return contains an error status, as defined by errno.h. If there is a functional value that we want to return, as it is in case of gpio_port_get function, we do it via a function parameter.
That said, I agree that we should discuss / reconsider the need to enforce a fixed 32-bit types in Zephyr's API. This issue has been neglected for a while.

In the API meeting last week I explicitly asked whether anybody had an issue with requiring a 32-bit value to represent the set of pins supported by a single driver and people were OK with it.
For future-proofing and clarity of argument purpose I'd be happy to see typedef u32_t gpio_value_t and use gpio_value_t in the API.  It could be typedef'd on a per-platform basis, but that might cause problems with external GPIO devices that are not platform-specific and might be larger/smaller than the platform default.

tl;dr: The facts have been collected; I've changed my mind; and I now propose revising the specification so set_clr does not support toggle and instead clears pins that are present in both sets.
So I've been spending some time with #16648 and based on experience would like to propose a change.
I originally promoted the set_clr interface because it's a basis operation: set, clear, and set_masked can all be implemented in terms of it, and toggle can too with careful definition of the operation.  I've used this technique in several APIs and found it to reduce complexity (one function instead of four).
I've now implemented that on top of #16648.  The effect is that it reduces code size slightly (102 b on nRF52) and slightly reduces the size of the driver structure.
It also incurs a noticeable overhead.  Below are times, in microseconds, for each step of a series of operations.  16648 is the original implementation using four basis functions, Basis is one that replaces them with one core implementation, NoTgl is Basis with the branch test that supports toggling in set_clr removed, and New is explained later:

Operation
16648
Basis
NoTgl
New

gpio_port_clear_bits
0.56
1.1
1.0
0.57

gpio_port_set_bits
0.70
1.0
0.92
0.70

gpio_port_set_bits
0.68
1.1
1.0
0.68

gpio_port_set_clr_bits
1.12
1.15
0.95
0.49

gpio_pin_set
0.56
0.92
0.84
0.58

gpio_port_clear_bits_raw
0.59
0.94
0.87
0.55

Per Iteration
7.02
9.6
8.9
6.34

When measured at this level the time for each operation in Basis ranges from 43% to 96% more than for 16648, ignoring the toggle operation which is slightly faster in Basis.  When measured at a higher level the average time for the entire sequence (including a containing function call) repeated several thousand times the Basis approach takes 36% longer.
If the original set_clr_bits call is replaced with toggle_bits the corresponding call reduces from 1.12 us to 0.49 us.
Analysis suggests that most of the increased cost in the basis function approach is due to branch conditions that deal with toggle support.  The implementation also handled inversion in the basis function, which slightly confounds the results: the 16648 approach of doing it inline allows optimization using the integer constant parameters that aren't visible in the driver.  Nonetheless, the need to check for toggle in each basis function invocation adds enough cost that reconsideration is appropriate.
Given this evidence I withdraw the proposal that driver implementations should use the basis function for simplicity: it is, indeed, too expensive.  As a result there is no motivation for defining set_clr(bits, bits) to be a toggle operation as the primitive toggle can be used.  The only cost of this is an increased delay between pin state changes in the presumably rare situation where "simultaneously" some bits are set or cleared and others are toggled.
Instead the semantics of set_clr(bits, bits) is defined to cause the bits to be cleared.
The New column above is the result of this change, replacing the set_clr_bits operator with toggle_bits.  The effect of this is that the duration of the iteration reduces from 7.02 us to 6.34 us.
My branch #18689 has been updated to make this change.
BTW: I will be adding the function that does performance testing to the GPIO test in #18689, but right now it depends on devicetree capability not yet merged to master.

@mnkp can we close this one ?

Now that new GPIO API has been implemented and merged, I think we can open the floor to pinctrl API.
Since this issue has been exploited in length for GPIO, I suggest to close this one a open a new one dedicated to pinctrl
@mnkp are you fine with this?


Fixes timezone misinformation

Timezone is already enabled by default in 4.2

Thanks for this patch, however the docs are correct for Django 4.2:
https://github.com/django/django/blob/791407fef16faa4da6fe2247c24a9055037dd5dd/django/conf/global_settings.py#L43-L44

True, but the docs for that version would still be misleading as they haven't been updated.
https://docs.djangoproject.com/en/4.2/topics/i18n/timezones/

USE_TZ = False for 4.2: https://github.com/django/django/blob/4.2/django/conf/global_settings.py#L44
? 🤔

@shangxiao the patch updates the docs


Enable Az ML teams to easily launch GH Actions.

Launch a getting started with GH Actions for ML repo so that they can easily contribute actions.
This should cover things such documentation, best practices patterns, unit test coverage requirements, supportability, powerBI dashboard integration to understand the uptake of any new action.

@aronchick Can you maybe add what you would like to be included in the template?
Why do the teams not take over responsibility over the Actions that we have developed?

@aronchick Any updates?

The things that I would expect to appear in this would be a template repo structure, sample documentation and sample usage guidelines, unit test harnesses, and other things necessary for each team to pick it up and run.
Our goal is for this team only to own this repo structure and not the actions themselves.

@pulkitaggarwl @aronchick

Let's discuss this in detail. What is required?
How do the individual teams work together?
What should be included in the templates?

Documentation is required. Iterative process.


Pock Ribbon won't close while browsing finder

While browsing finder in Pock, I am presented with 2 close x buttons. One of the inner close buttons works like closing the finder browser. But the main close button is working as back button in finder, instead of closing the Pock Ribbon. While performing this task,  Esc button is also not visible.

As a temporary fix, one can double press Ctrl and close the pock strip and double press again to resume browsing from same place.

This is the expected behavior if the option "Hide Control Strip" is disabled.

This is the expected behavior if the option "Hide Control Strip" is disabled.


Add version tag

It is better to add version tag for development, bug fix and consensus between server and client.

Fine by me. Altough it seems procrastination until a server is not run, so I won't figure out this change it.

Yes, but there is still no version alpha though. IMO the TOR patch is needed before making any release.

will do, soon v1. I am trying to tumble 100 testnet client simultaneously, then will release v1


Ensure every puppet run does not unzip the odl

Every time puppet runs, the odl zip was getting downloaded unzipping and restarting services. To ensure this doesnt happen, we need to add a root_dir in the archive provider .
This will ensure that multiple puppet runs will not cause any service restarts

@vpramo thanks for the PR! Sorry for the delay, I'm still trying to understand exactly what this does. Restating what I'm understanding from the commit message, this is meant to make the tarball extraction process idempotent? If you could give an example that would help me quickly understand/merge. Else I'll take another dive early next week (when I get home, traveling at the moment). Thanks again!

@dfarrell07 hey sorry for the bad commit message,  well basically during each and every puppet run, the tarball was getting unzipped and extracting all the files  and since its dependent on the service, it basically will restart the ODL service.
You can refer to this Issue raised in puppet-archive
https://github.com/camptocamp/puppet-archive/issues/55

@vpramo Okay, cool, that makes sense. Thanks!


defer notifying observers with reactor.batch

There are cases when you want to preform multiple synchronous actions without notifying observers.
For 1.1 lets implement
reactor.batch(function() {
   Query.Actions.setStartDate(picker.startDate);
   Query.Actions.setEndDate(picker.endDate);
})

Which will execute all of the actions and then notify observers after the function has been run.
Underneath the hood it will most likely use functions like reactor.__batchStart() and reactor.__batchEnd()

Closed in #113


Need detailed information.

It doesn't tell you where you need to be in order to "type the path and file name for the CSR in the file name text box."

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ad3ee770-a0fc-1c19-85df-2348948bcf75
Version Independent ID: e18038bb-00f6-7488-f8ba-4ef3183ccd83
Content: Certificate Request (Certificate Signing Request)
Content Source: Skype/SfbServer/help-topics/help-depwiz/certificate-request-certificate-signing-request.md
Product: skype-for-business-itpro
GitHub Login: @jambirk
Microsoft Alias: jambirk

Thank you for this feedback and for contributing to the wellness of the content! This is a good idea and we have added it into our backlog for triage and prioritization

@tseward Is investigating this.

Hi @nsshommo thanks for your feedback.
This document is part of a group of documents that you must follow in order and when you get into this one you already are in the Deployment Wizard, Certificate Request Page, so it's not neccesary to specify.
Thank you.


GraalVM

I would personally need a GraalVM image (arm64) for one of my custom plugins running other languages.
https://github.com/graalvm/container/pkgs/container/graalvm-ce

I've created 8 CE and 11/17 JDK versions for my own use. They can be found in my repo here and could be PR'ed over.

Just use Software-Noob. IF you want to pr them over that is fine.