From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm: bridge: anx7625: don't crash if Type-C port is not used Date: Sun, 15 Feb 2026 19:02:41 +1000 Message-ID: In-Reply-To: <20260215-anx-fix-no-typec-v1-1-75172a5ca88b@oss.qualcomm.com> References: <20260215-anx-fix-no-typec-v1-1-75172a5ca88b@oss.qualcomm.com> <20260215-anx-fix-no-typec-v1-1-75172a5ca88b@oss.qualcomm.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review > + if (!ctx->typec_port) > + return; > + > if (intr_vector & CC_STATUS) > anx7625_typec_set_orientation(ctx); > if (intr_vector & DATA_ROLE_STATUS) { The fix is correct and well-placed. `anx7625_typec_set_status()` is the funct= ion that dispatches to `anx7625_typec_set_orientation()` and the data/power r= ole status paths, all of which ultimately call `typec_set_*()` functions that= will dereference the port pointer. Guarding at this single entry point cover= s all downstream call sites. One question: the changelog notes that a chunk fixing `anx7625_typec_unregist= er()` was dropped. Does `anx7625_typec_unregister()` also need a NULL guard o= n `ctx->typec_port` before calling `typec_unregister_port()`? If the driver's= remove/unbind path can be reached without the typec port having been success= fully registered (e.g., probe succeeded but typec registration was skipped be= cause the connector fwnode was absent), then the same NULL dereference would = occur on driver removal. It would be worth confirming that the unregister pat= h is already safe. Otherwise, no issues found. The fix is minimal, targeted, has the correct Fix= es: tag, and the commit message clearly explains the problem with an actual c= rash trace. --- Generated by Claude Code Patch Reviewer