nuttxpr commented on PR #14895: URL: https://github.com/apache/nuttx/pull/14895#issuecomment-2491691177
[**\[Experimental Bot, please feedback here\]**](https://github.com/search?q=repo%3Aapache%2Fnuttx+13552&type=issues) No, this PR does not fully meet the NuttX requirements. While it provides a summary and testing information, it lacks crucial details. Here's a breakdown of what's missing: * **Summary:** Needs to be more detailed. * **Why is this change necessary?** Just saying "Create an ioctl driver..." isn't enough. Explain the problem the driver solves. Why is the current method (PDO2/POO2/reset) insufficient? What benefits does the ioctl driver provide? * **What functional part of the code is being changed?** Be specific. Which subsystem is affected? Are new files being added? Are existing files being modified? Where is this ioctl driver located in the codebase? * **How does the change exactly work?** Explain the mechanism of the ioctl driver. What ioctl commands are being introduced? How does it interact with the hardware? How does it differ from the existing power negotiation method? * **Related Issues:** Are there any related issues in the NuttX or NuttX Apps repositories? If not, consider creating one to track the feature request/bug this PR addresses. * **Impact:** "None expected" is almost never true. Think carefully about potential impacts. * **New feature?** Yes, explicitly state this. * **Impact on the user:** Will the user need to change their application code to use the new ioctl driver? If so, how? Provide examples. * **Impact on build:** Does the build system need to be modified to include the new driver? Are any new Kconfig options added? * **Impact on hardware:** Which architectures and boards are supported? Are any hardware-specific modifications required? * **Impact on documentation:** At a minimum, the new driver needs to be documented. State this explicitly. Where will the documentation be added? * **Impact on security:** Consider potential security implications. Could the ioctl driver be misused? * **Impact on compatibility:** Does this change break any existing functionality? * **Testing:** Insufficient detail. * **Build Host(s):** Provide specific information: OS version, compiler version (e.g., "Linux Ubuntu 20.04, GCC 9.4.0"). * **Target(s):** Be specific: Architecture, board, configuration (e.g., "sim:qemu-arm", "stm32f4discovery:default"). * **Testing logs:** "Tested on custom board" is meaningless without actual logs. Show *relevant* logs demonstrating the functionality before and after the change. Include commands used, output, and evidence that the power delivery negotiation is working as expected. Demonstrate the benefits over the previous method. By addressing these points, the PR will be much more likely to be accepted. Remember to be clear, concise, and provide as much detail as possible. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
