From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: bus: mhi: Expose DDR training data via controller sysfs Date: Sun, 22 Mar 2026 04:44:35 +1000 Message-ID: In-Reply-To: <20260319-sahara_protocol_new_v2-v4-8-47ad79308762@oss.qualcomm.com> References: <20260319-sahara_protocol_new_v2-v4-0-47ad79308762@oss.qualcomm.com> <20260319-sahara_protocol_new_v2-v4-8-47ad79308762@oss.qualcomm.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Adds a read-only binary sysfs attribute for DDR training data. **Issues:** - **`sahara_ctrl_trng_get()` from sysfs read creates empty devres entries**. If no training data exists, the sysfs read handler (`ddr_training_data_read` at `sahara.c:418`) allocates a new empty `sahara_ctrl_trng_data` via `sahara_ctrl_trng_get()`. Should use `devres_find()` only and return 0 if not found. - **Partial reads during active receive**: No check for `ct->receiving == true`. A userspace reader could get inconsistent partial data. - **`devres_alloc(..., 1, GFP_KERNEL)` for cookie** at `sahara.c:476`: Allocating 1 byte as a sentinel is unusual; the allocation overhead is wasted. - **Race in `sahara_sysfs_create`**: The check-then-create pattern for the sysfs file is not atomic. Concurrent probes for two channels on the same controller could both pass the `devres_find` check and create duplicate sysfs files. --- Generated by Claude Code Patch Reviewer