今日重点：🔍 标题解析——前面几期拆过动词、限定语、方括号元信息；今天只盯冒号前那一截：前缀。 它像地址：最左一栏是树，往右每加一级，范围缩一圈。 今天四组真实补丁指向同一件事：前缀写到哪一级，取决于你动了谁的地—— 同一条系列里，改 1 个文件的补丁写到驱动名，改 25 个文件的补丁停在类别层； 一个 SoC 支持系列，前缀散落在九个 binding 子系统里。
📖 今日标题（真实清单，逐字引用）
/ section[PATCH 0/5] media: use designated initializers for acpi_device_id [PATCH 3/5] media: i2c: cvs: Use named initializers for acpi_device_id [PATCH 4/5] media: i2c: Use named initializers for acpi_device_id [PATCH 5/5] media: pci: intel: Use named initializers for acpi_device_id
[PATCH v3 00/16] drm/msm/a8xx: GPU state capture support [PATCH v3 01/16] drm/msm: Import adreno_snapshot.h [PATCH v3 02/16] drm/msm/a8xx: Export aperture helpers [PATCH v3 08/16] drm/msm/adreno: Fix PROTECT span length
[PATCH v6 1/2] media: dt-bindings: imx908: Add Sony IMX908 sensor [PATCH v7 02/11] dt-bindings: iommu: qcom,iommu: Add MSM8952 IOMMU to SMMUv2 compatibles [PATCH v7 07/11] dt-bindings: display: msm: dsi-controller-main: Add MSM8952 compatible [PATCH v7 09/11] arm64: dts: qcom: Add initial support for MSM8952
出处：均取自 2026-10-29 投递到 linux-media / dri-devel 的真实邮件（本地雷达 2026-10-30 抓取）。 每条引用都给了该邮件本身的链接，点开就是标题和正文所在的那一封。
🔍 前缀的三种深度
/ column ① 相邻两条差一级：动一个驱动 vs 动二十五个 先看 acpi_device_id 这条 5 补丁的清理系列。封面列出的五条标题，前缀一眼能看出分工：
3/5 只改
4/5 改 25 个文件，从
5/5 只改
读法：前缀到哪一级，等于你要求哪一级的人来看。写到驱动名，是告诉那位驱动维护者「这是你的私事」； 停在
media: cec: seco:、media: i2c: ccs:、media: i2c: cvs:、 media: i2c:、media: pci: intel:。 封面原文 为什么第 3 条带 cvs、第 4 条不带？答案写在各自的 diffstat 里：3/5 只改
drivers/media/i2c/cvs/core.c，合计「1 file changed, 4 insertions(+), 4 deletions(-)」—— 一个驱动，前缀写到驱动名。 原文4/5 改 25 个文件，从
gc0310.c 到 t4ka3.c，横跨二十多个 i2c 驱动， 「25 files changed, 51 insertions(+), 51 deletions(-)」——没有哪个驱动名能覆盖全部改动， 前缀只能停在类别层 i2c。 原文5/5 只改
drivers/media/pci/intel/ipu-bridge.c，前缀停在目录 media: pci: intel:， 没写文件名——目录已经是最小公共范围。 原文读法：前缀到哪一级，等于你要求哪一级的人来看。写到驱动名，是告诉那位驱动维护者「这是你的私事」； 停在
i2c，是告诉整个 i2c 类别「这是公共改动」。写深一级是越界，写浅一级会被当成别人的事。 ② 一条系列三种深度：前缀标归属，不照抄目录 drm/msm 的 GPU state capture 系列 16 条，前缀分三档：
结论：目录是文件放在哪，前缀是改动属于谁。两者一致是常态；不一致时以前缀为准，由正文解释为什么。
drm/msm: 2 条、 drm/msm/adreno: 3 条、drm/msm/a8xx: 11 条（含封面）。三条典型：drm/msm: Import adreno_snapshot.h 改的是 adreno/adreno_snapshot.h，321 行新头文件； 文件明明在 adreno/ 目录下，前缀却停在 drm/msm:。正文给了理由： 「Based on kgsl_snapshot.h from downstream KMD. We'll be re-using some of this for gen8 devcoredump.」—— 这份头文件服务整个 adreno 层和后续 gen8 的 devcoredump，不属于某一代 GPU。 原文drm/msm/a8xx: Export aperture helpers 改的是 adreno/a6xx_gpu.h 和 adreno/a8xx_gpu.c，其中一个是 a6xx 的头文件，前缀却写 a8xx。正文： 「We'll need these from gen8 gpu state snapshot code as well.」——需求来自 a8xx，归属就是 a8xx。 原文drm/msm/adreno: Fix PROTECT span length 只改 adreno/a6xx_gpu.h，前缀写 adreno—— 这是 Adreno 公共层的缺陷，不是 a8xx 专属。 原文结论：目录是文件放在哪，前缀是改动属于谁。两者一致是常态；不一致时以前缀为准，由正文解释为什么。
③ 同一件事两套写法：binding 补丁放前缀哪一头 同样是只改设备树 binding 的补丁，今天两个树的写法不同：
linux-media：
DRM/MSM：
没有全局标准，只有各树的惯例。判断方法很机械：
linux-media：
media: dt-bindings: imx908: Add Sony IMX908 sensor——子系统 media 在前， dt-bindings 在中间；文件是 Documentation/devicetree/bindings/media/i2c/sony,imx908.yaml。 原文DRM/MSM：
dt-bindings: display: msm: dsi-controller-main: Add MSM8952 compatible—— dt-bindings 直接放最左，display 是子系统层。 原文没有全局标准，只有各树的惯例。判断方法很机械：
git log --oneline -- <该文件>， 看同目录最近合入的提交怎么写，照抄。自己发明前缀，等于让维护者先花一轮邮件纠正格式。 ④ 一个系列散到九个前缀：前缀跟文件走，不跟产品走 MSM8952 v7 是 11 补丁的 SoC 支持系列：9 条 dt-bindings 分别落在 nvmem、iommu、watchdog、sram、 mailbox、clock、display、remoteproc、input 九个子系统，另外 2 条是
同一个产品，九块责任田。前缀不统一不是错误——统一的是产品，分散的是所有权。 每条补丁由不同子系统的维护者接走，所以每条都按那块田的惯例起名。 系列封面
arm64: dts: qcom:。dt-bindings: nvmem: Add compatible for MSM8952 改的是 bindings/nvmem/qcom,qfprom.yaml，加 1 行。 原文dt-bindings: iommu: qcom,iommu: Add MSM8952 IOMMU to SMMUv2 compatibles 改的是 bindings/iommu/qcom,iommu.yaml，同样 1 行。 原文arm64: dts: qcom: Add initial support for MSM8952 则归 arm64 设备树。 原文同一个产品，九块责任田。前缀不统一不是错误——统一的是产品，分散的是所有权。 每条补丁由不同子系统的维护者接走，所以每条都按那块田的惯例起名。 系列封面
⑤ 拿到一个标题，三步读出前缀 1. 找第一个冒号，左边是树：
2. 往右逐级缩范围：
3. 斜杠和冒号都是分隔符，别把
写的时候反过来：先确认所有被改文件的公共范围，再决定停在哪一级；拿不准就抄同目录最近提交的前缀。 一整个系列允许不同深度——今天两个系列都这么干。
media、drm/msm、dt-bindings、 net、arm64。它决定谁评审、进哪棵树。2. 往右逐级缩范围：
media → i2c → cvs；drm/msm → a8xx； dt-bindings → display → msm → dsi-controller-main。层级越深，承诺的改动面越小。3. 斜杠和冒号都是分隔符，别把
drm/msm/a8xx: 当目录硬读——同一棵树里两种写法可以混用， DRM 习惯斜杠，media 习惯冒号。写的时候反过来：先确认所有被改文件的公共范围，再决定停在哪一级；拿不准就抄同目录最近提交的前缀。 一整个系列允许不同深度——今天两个系列都这么干。
✨ 辅助彩蛋：拆系列的理由，一句话说清
/ section★ That way the task can be fragmented into manageable and independent chunks of work and makes this effort easier to review.
拆解 That way 承接上文的拆分方案；be fragmented into 是被切成……； manageable and independent 两个形容词分工明确——manageable 管规模（每块小到能审）， independent 管依赖（块与块可独立推进）；makes this effort easier to review 落点是评审成本， 不是作者的方便。
语境翻译 这样一来，整件事就能切成若干规模可控、可独立推进的块，评审起来也更容易。
怎么用 在封面信里解释「为什么把一大批改动拆成多个补丁」时，这句话同时回答了「拆成什么样」和「对谁有好处」。 比 This series is split into many patches 多两层信息：拆的标准（manageable / independent）和收益（easier to review）。
和你相关 拆系列时给维护者一个可判断的理由：不是我想拆，是拆完你能更快审。
🔗 原文
✍️ 今日练习
/ column✍️ 两条真实标题，只差一个前缀层级：<br> <code>[PATCH 3/5] media: i2c: cvs: Use named initializers for acpi_device_id</code><br> <code>[PATCH 4/5] media: i2c: Use named initializers for acpi_device_id</code><br><br> 已知：3/5 只改 <code>drivers/media/i2c/cvs/core.c</code>（1 file changed）； 4/5 改 25 个 i2c 驱动文件（25 files changed）。<br> ① 4/5 为什么不写成 <code>media: i2c: <某个驱动>:</code>？ ② 如果 4/5 硬写一个驱动名，会误导什么？ ③ 你要发一条只改 <code>drivers/media/i2c/imx283.c</code> 的补丁，前缀怎么写，依据是什么？
💡 显示答案
① 4/5 的改动不属于任何一个驱动：25 个文件横跨 gc0310 到 t4ka3 二十多个驱动， 没有任何一个驱动名能覆盖全部改动，最小能覆盖全部改动的责任单位是类别层 i2c，所以前缀停在 media: i2c:。<br> ② 写一个驱动名，等于把公共改动说成单个驱动的私事：另外二十多个驱动的维护者不会注意到， i2c 类别的评审也不会按公共改动的标准看它；对那个被点名的驱动维护者则是越权。<br> ③ 写 media: i2c: imx283: <祈使句>。依据两条：被改文件全在 drivers/media/i2c/imx283.c， 最小责任单位是 imx283 这个驱动；前缀形态照抄同目录最近合入提交的写法，不自创。
📖 原文：Pawel Zalewski (5):
media: cec: seco: Use named initializers for acpi_device_id
media: i2c: ccs: Unify list terminator for acpi_device_id
media: i2c: cvs: Use named initializers for acpi_device_id
media: i2c: Use named initializers for acpi_device_id
media: pci: intel: Use named initializers for acpi_device_id
📎 原文引用 每日一句：Read the prefix as an address — it tells you whose code you are touching, and how far the change reaches.
仿写示范