Remove problematic and unuseful logging statement from gpio.c (IDFGH-14846)

[skibu]

Removed inappropriate and misleading logging statement. The logging statement was at INFO level, which means that it was inappropriately logging cryptic info. And the context wasn't explained, which means that it took quite a long time to find out exactly why the logging statement wrongly implied that I wasn't successfully setting up input and output bits. Best to simply remove it.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Warnings

⚠️

Some issues found for the commit messages in this PR: the commit message "Removed vars that were unused": body's lines must not be longer than 100 characters summary looks empty type/action looks empty the commit message "Update gpio.c": body's lines must not be longer than 100 characters summary looks empty type/action looks empty Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).

👋 Hello skibu, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against 6299b0b

[skibu]

I have now signed the contributor agreement.

Do the commit titles need to be changed in order for this PR to be processed? I ask because this cannot be done via GitHub website. If the titles truly need to be changed then I have to download my fork and modify the commits manually.

[wanckl]

@skibu Don't think so, the log you removed is usefull for my debug, and can be bypassed by level.

may I know how it misleads you, we can update it more understandable

[KaeLL]

No offense, but seems like you're overreacting because you don't know what you're doing.

The logging statement was at INFO level, which means that it was inappropriately logging cryptic info.

Non-sequitur

And the context wasn't explained

Care to elaborate on how that could be fixed?

it took quite a long time to find out exactly why the logging statement wrongly implied that I wasn't successfully setting up input and output bits.

How so?

[skibu]

may I know how it misleads you, we can update it more understandable

@wanckl , thank you for starting the dialog. I'm certain we can come up with a mutually satisfactory solution.

What happened:
I was using new to me software (esp-idf-cxx) to configure GPIO bits on a new ESP32 board. With informational logging enabled I noticed a peculiar log message when I was setting up IO bits to be either inputs or outputs. The log message was something like:

GPIO[17]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0

The reason this logging message was misleading is because it implied that after I setup my GPIO bit as an input or an output that InputEn:0 and OutputEn: 0. The message was implying that the bit was not actually successfully configured.

The reason for this problem is that the logging message was part of a reset that was done before the bit was actually configured as an input or an output. But the message did not indicate that it was just part of the reset.

Possible Solutions:

• Could simply delete the logging statement as I proposed, but this would limit your debugging ability. So likely not the best solution.
• Could modify the logging statement:
  1. change to debug logging. ESP_LOGI() => ESP_LOGD(). This way the message of course wouldn't show up unless debugging.
  2. add context to show that the debug logging statement is for a reset command. Could simply add to the beginning of the logging statement so that "GPIO[17]..." => "Reseting bit GPIO[17]..."

Let me know if I can further explain what happened. Also, let me know if you want to close this PR and have me submit a new one with a different solution.

[igrr]

change to debug logging. ESP_LOGI() => ESP_LOGD(). This way the message of course wouldn't show up unless debugging

+1 for this option.

I think the GPIO driver differs from other peripheral drivers in that it logs its configuration at info level. The reason why it differs is probably that GPIO driver was one of the first drivers we added in IDF, and there were no established conventions for logging from IDF components at that point.

Calling esp_log_level_set("gpio", ESP_LOG_NONE) is of course possible, but so is esp_log_level_set("gpio", ESP_LOG_DEBUG), provided that CONFIG_LOG_MAXIMUM_LEVEL_DEBUG is set. So I think the debugging use case should still be satisfied if we move this log to debug level.