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/komeda: Add support for Arm China Linlon-D6 Date: Thu, 12 Mar 2026 07:17:47 +1000 Message-ID: In-Reply-To: <20260311055506.12023-4-cunyuan.liu@cixtech.com> References: <20260311055506.12023-1-cunyuan.liu@cixtech.com> <20260311055506.12023-4-cunyuan.liu@cixtech.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 Three one-line additions: 1. **`malidp_product.h`** =E2=80=94 adds `LINLONDP_D6_PRODUCT_ID 0x0060`: ```c #define LINLONDP_D6_PRODUCT_ID 0x0060 ``` **Minor observation:** The naming prefix `LINLONDP_` departs from the exist= ing `MALIDP_` convention used by `MALIDP_D71_PRODUCT_ID` and `MALIDP_D32_PR= ODUCT_ID`. Since this is a different vendor's IP (Arm China vs Arm), a diff= erent prefix is reasonable, but the maintainers may have an opinion on whet= her to keep a unified prefix (e.g., `MALIDP_LINLON_D6_PRODUCT_ID`) for cons= istency, or whether the distinction is intentional and desired. 2. **`d71_dev.c`** =E2=80=94 adds the new product ID to the `d71_identify()= ` switch: ```c case LINLONDP_D6_PRODUCT_ID: funcs =3D &d71_chip_funcs; ``` This is correct =E2=80=94 it allows the D71 function table to be used when = the hardware reports product ID 0x0060. 3. **`komeda_drv.c`** =E2=80=94 adds the `of_device_id` entry: ```c { .compatible =3D "armchina,linlon-d6", .data =3D d71_identify, }, ``` Correct =E2=80=94 it maps the new compatible to the same `d71_identify` fun= ction used by the existing Mali entries. No functional issues. The patch is well-explained in its commit message, no= ting the register offset for PRODUCT_ID and the rationale for code reuse. **Overall:** Series looks good to merge. The only thing maintainers might w= ant to bikeshed is the `LINLONDP_` vs `MALIDP_` naming prefix. --- Generated by Claude Code Patch Reviewer