FelipeMdeO opened a new pull request, #20242:
URL: https://github.com/apache/nuttx/pull/20242
## Summary
Follow-up to #20231 ("sensors/lsm6ds3trc_uorb.c: three robustness fixes"),
addressing review feedback from @raiden00pl left after merge
(https://github.com/apache/nuttx/pull/20231#discussion_r4070387230 —
"you should not put board or arch specific things in common code").
The reset comment in `lsm6ds3trc_register()` — generic, board/arch
independent driver code — named ESP32S3-specific things that have
nothing to do with this driver's actual logic:
* `esptool`/RTS-pin reset vocabulary (Espressif tooling, not a generic
MCU-reset concept);
* a literal path to
`boards/xtensa/esp32s3/common/src/esp32s3_board_lsm6ds3trc.c`;
* the espressif-arch function `esp_gpioirqenable()`.
None of that is reachable from this file — the driver only ever calls
the board-supplied `config->attach()` callback, which is exactly the
abstraction meant to keep this code arch/board-agnostic. Reworded the
comment to describe the same reset/level-trigger requirement in those
generic terms, and dropped an ESP32S3-collar bring-up anecdote
("observed as a boot that stops right after Wi-Fi init...") that
documents one board's validation, not the driver.
Comment-only change; no functional/behavioral difference.
## Impact
* Is new feature added? No.
* Is existing feature changed? No — comment-only change, no code path
affected.
* Impact on hardware? None.
## Testing
Comment-only change. Confirmed no other board/arch-specific reference
remains anywhere in `drivers/sensors/lsm6ds3trc_uorb.c` (searched for
`esp_`, `esptool`, `xtensa`, `esp32`, and the specific board file name).
`nxstyle` passes on the file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
