Verisilicon has a series of display controllers prefixed with DC and
with self-identification facility like their GC series GPUs.
Add a device tree binding for it.
Depends on the specific DC model, it can have either one or two display
outputs, and each display output could be set to DPI signal or "DP"
signal (which seems to be some plain parallel bus to HDMI controllers).
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
Changes in v3:
- Added SoC-specific compatible string, and arm the binding with clock /
port checking for the specific SoC (with a 2-output DC).
Changes in v2:
- Fixed misspelt "versilicon" in title.
- Moved minItems in clock properties to be earlier than items.
- Re-aligned multi-line clocks and resets in example.
.../bindings/display/verisilicon,dc.yaml | 146 ++++++++++++++++++
1 file changed, 146 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/verisilicon,dc.yaml
diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
new file mode 100644
index 0000000000000..522a544498bea
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Verisilicon DC-series display controllers
+
+maintainers:
+ - Icenowy Zheng <uwu@icenowy.me>
+
+properties:
+ $nodename:
+ pattern: "^display@[0-9a-f]+$"
+
+ compatible:
+ items:
+ - enum:
+ - thead,th1520-dc8200
+ - const: verisilicon,dc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 4
+ items:
+ - description: DC Core clock
+ - description: DMA AXI bus clock
+ - description: Configuration AHB bus clock
+ - description: Pixel clock of output 0
+ - description: Pixel clock of output 1
+
+ clock-names:
+ minItems: 4
+ items:
+ - const: core
+ - const: axi
+ - const: ahb
+ - const: pix0
+ - const: pix1
+
+ resets:
+ items:
+ - description: DC Core reset
+ - description: DMA AXI bus reset
+ - description: Configuration AHB bus reset
+
+ reset-names:
+ items:
+ - const: core
+ - const: axi
+ - const: ahb
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The first output channel , endpoint 0 should be
+ used for DPI format output and endpoint 1 should be used
+ for DP format output.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The second output channel if the DC variant
+ supports. Follow the same endpoint addressing rule with
+ the first port.
+
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: thead,th1520-dc8200
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ ports:
+ required:
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/thead,th1520-clk-ap.h>
+ #include <dt-bindings/reset/thead,th1520-reset.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ display@ffef600000 {
+ compatible = "thead,th1520-dc8200", "verisilicon,dc";
+ reg = <0xff 0xef600000 0x0 0x100000>;
+ interrupts = <93 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_vo CLK_DPU_CCLK>,
+ <&clk_vo CLK_DPU_ACLK>,
+ <&clk_vo CLK_DPU_HCLK>,
+ <&clk_vo CLK_DPU_PIXELCLK0>,
+ <&clk_vo CLK_DPU_PIXELCLK1>;
+ clock-names = "core", "axi", "ahb", "pix0", "pix1";
+ resets = <&rst TH1520_RESET_ID_DPU_CORE>,
+ <&rst TH1520_RESET_ID_DPU_AXI>,
+ <&rst TH1520_RESET_ID_DPU_AHB>;
+ reset-names = "core", "axi", "ahb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpu_out_dp1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+ };
+ };
--
2.52.0On 24/11/2025 11:52, Icenowy Zheng wrote: > Verisilicon has a series of display controllers prefixed with DC and > with self-identification facility like their GC series GPUs. > > Add a device tree binding for it. > > Depends on the specific DC model, it can have either one or two display > outputs, and each display output could be set to DPI signal or "DP" > signal (which seems to be some plain parallel bus to HDMI controllers). > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Wrong DCO chain order. You send it as icenowy.me, so this must be last SoB. This identity is the last one certifying DCO. Please kindly read submitting patches, so you know what you are certifying here. > --- > Changes in v3: > - Added SoC-specific compatible string, and arm the binding with clock / > port checking for the specific SoC (with a 2-output DC). > > Changes in v2: > - Fixed misspelt "versilicon" in title. > - Moved minItems in clock properties to be earlier than items. > - Re-aligned multi-line clocks and resets in example. > > .../bindings/display/verisilicon,dc.yaml | 146 ++++++++++++++++++ > 1 file changed, 146 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > new file mode 100644 > index 0000000000000..522a544498bea > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > @@ -0,0 +1,146 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Verisilicon DC-series display controllers > + > +maintainers: > + - Icenowy Zheng <uwu@icenowy.me> > + > +properties: > + $nodename: > + pattern: "^display@[0-9a-f]+$" > + > + compatible: > + items: > + - enum: > + - thead,th1520-dc8200 > + - const: verisilicon,dc I do not see any explanation of exception for generic compatibles, maybe except "self-identification" remark. Rob already pointed this out, so be explicit in commit msg why you are using a generic compatible. > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + clocks: > + minItems: 4 This is not flexible. Device either has or has not these clocks. > + items: > + - description: DC Core clock > + - description: DMA AXI bus clock > + - description: Configuration AHB bus clock > + - description: Pixel clock of output 0 > + - description: Pixel clock of output 1 > + Best regards, Krzysztof
在 2025-11-24星期一的 12:01 +0100，Krzysztof Kozlowski写道： > On 24/11/2025 11:52, Icenowy Zheng wrote: > > Verisilicon has a series of display controllers prefixed with DC > > and > > with self-identification facility like their GC series GPUs. > > > > Add a device tree binding for it. > > > > Depends on the specific DC model, it can have either one or two > > display > > outputs, and each display output could be set to DPI signal or "DP" > > signal (which seems to be some plain parallel bus to HDMI > > controllers). > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> > > Wrong DCO chain order. You send it as icenowy.me, so this must be > last > SoB. This identity is the last one certifying DCO. Please kindly read > submitting patches, so you know what you are certifying here. > > > --- > > Changes in v3: > > - Added SoC-specific compatible string, and arm the binding with > > clock / > > port checking for the specific SoC (with a 2-output DC). > > > > Changes in v2: > > - Fixed misspelt "versilicon" in title. > > - Moved minItems in clock properties to be earlier than items. > > - Re-aligned multi-line clocks and resets in example. > > > > .../bindings/display/verisilicon,dc.yaml | 146 > > ++++++++++++++++++ > > 1 file changed, 146 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > new file mode 100644 > > index 0000000000000..522a544498bea > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > @@ -0,0 +1,146 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Verisilicon DC-series display controllers > > + > > +maintainers: > > + - Icenowy Zheng <uwu@icenowy.me> > > + > > +properties: > > + $nodename: > > + pattern: "^display@[0-9a-f]+$" > > + > > + compatible: > > + items: > > + - enum: > > + - thead,th1520-dc8200 > > + - const: verisilicon,dc > > I do not see any explanation of exception for generic compatibles, > maybe > except "self-identification" remark. Rob already pointed this out, so > be > explicit in commit msg why you are using a generic compatible. Well I only get the meaning of "a SoC specific compatible is required" in his review message. I think my binding now requires both a SoC-specific compatible and a generic compatible, which should be okay to satisfy Rob's original review. > > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + clocks: > > + minItems: 4 > > This is not flexible. Device either has or has not these clocks. The existence of all these clocks are verified by diagrams in manuals of two different SoCs with DC8200 (T-Head TH1520 and StarFive JH7110). Maybe a explicit `maxItems: 5` is needed here, but as my DT passes dtbs_check, I don't think it's necessary? Or maybe I should drop the flexibility now and use a `minItems: 5` here (and leave DC8000 support as another story)? (The Eswin EIC7700 manual does not have a diagram showing external connections of the DC, like the two SoCs I mentioned above). > > > + items: > > + - description: DC Core clock > > + - description: DMA AXI bus clock > > + - description: Configuration AHB bus clock > > + - description: Pixel clock of output 0 > > + - description: Pixel clock of output 1 > > + > > > > Best regards, > Krzysztof
On 26/11/2025 10:50, Icenowy Zheng wrote: >>> +maintainers: >>> + - Icenowy Zheng <uwu@icenowy.me> >>> + >>> +properties: >>> + $nodename: >>> + pattern: "^display@[0-9a-f]+$" >>> + >>> + compatible: >>> + items: >>> + - enum: >>> + - thead,th1520-dc8200 >>> + - const: verisilicon,dc >> >> I do not see any explanation of exception for generic compatibles, >> maybe >> except "self-identification" remark. Rob already pointed this out, so >> be >> explicit in commit msg why you are using a generic compatible. > > Well I only get the meaning of "a SoC specific compatible is required" > in his review message. > > I think my binding now requires both a SoC-specific compatible and a > generic compatible, which should be okay to satisfy Rob's original > review. You will get then the same questions for me - what justifies generic compatible. You should be on this explicit, because otherwise people misinterpret some commits and patches, and they think the generic compatible is allowed for them as well. > >> >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + interrupts: >>> + maxItems: 1 >>> + >>> + clocks: >>> + minItems: 4 >> >> This is not flexible. Device either has or has not these clocks. > > The existence of all these clocks are verified by diagrams in manuals So not flexible, then: > of two different SoCs with DC8200 (T-Head TH1520 and StarFive JH7110). > > Maybe a explicit `maxItems: 5` is needed here, but as my DT passes > dtbs_check, I don't think it's necessary? No, drop minItems only. > > Or maybe I should drop the flexibility now and use a `minItems: 5` here > (and leave DC8000 support as another story)? (The Eswin EIC7700 manual > does not have a diagram showing external connections of the DC, like > the two SoCs I mentioned above). You document here only the devices explicitly mentioned in the binding. You cannot add here constraints or clocks for some device which is not in the binding and I see only th1520 in the binding. Best regards, Krzysztof
在 2025-11-26星期三的 11:22 +0100，Krzysztof Kozlowski写道： > On 26/11/2025 10:50, Icenowy Zheng wrote: > > > > +maintainers: > > > > + - Icenowy Zheng <uwu@icenowy.me> > > > > + > > > > +properties: > > > > + $nodename: > > > > + pattern: "^display@[0-9a-f]+$" > > > > + > > > > + compatible: > > > > + items: > > > > + - enum: > > > > + - thead,th1520-dc8200 > > > > + - const: verisilicon,dc > > > > > > I do not see any explanation of exception for generic > > > compatibles, > > > maybe > > > except "self-identification" remark. Rob already pointed this > > > out, so > > > be > > > explicit in commit msg why you are using a generic compatible. > > > > Well I only get the meaning of "a SoC specific compatible is > > required" > > in his review message. > > > > I think my binding now requires both a SoC-specific compatible and > > a > > generic compatible, which should be okay to satisfy Rob's original > > review. > > You will get then the same questions for me - what justifies generic > compatible. You should be on this explicit, because otherwise people > misinterpret some commits and patches, and they think the generic > compatible is allowed for them as well. I came across a comment on Mali Valhall bindings that says `Mali Valhall GPU model/revision is fully discoverable`, just after the compatible string. Should I add a comment like this, or should I make things more clear in the commit message? > > > > > > > > > > + > > > > + reg: > > > > + maxItems: 1 > > > > + > > > > + interrupts: > > > > + maxItems: 1 > > > > + > > > > + clocks: > > > > + minItems: 4 > > > > > > This is not flexible. Device either has or has not these clocks. > > > > The existence of all these clocks are verified by diagrams in > > manuals > > So not flexible, then: > > > of two different SoCs with DC8200 (T-Head TH1520 and StarFive > > JH7110). > > > > Maybe a explicit `maxItems: 5` is needed here, but as my DT passes > > dtbs_check, I don't think it's necessary? > > No, drop minItems only. > > > > > Or maybe I should drop the flexibility now and use a `minItems: 5` > > here > > (and leave DC8000 support as another story)? (The Eswin EIC7700 > > manual > > does not have a diagram showing external connections of the DC, > > like > > the two SoCs I mentioned above). > > You document here only the devices explicitly mentioned in the > binding. > You cannot add here constraints or clocks for some device which is > not > in the binding and I see only th1520 in the binding. > > Best regards, > Krzysztof
On 27/11/2025 14:47, Icenowy Zheng wrote: > 在 2025-11-26星期三的 11:22 +0100，Krzysztof Kozlowski写道： >> On 26/11/2025 10:50, Icenowy Zheng wrote: >>>>> +maintainers: >>>>> + - Icenowy Zheng <uwu@icenowy.me> >>>>> + >>>>> +properties: >>>>> + $nodename: >>>>> + pattern: "^display@[0-9a-f]+$" >>>>> + >>>>> + compatible: >>>>> + items: >>>>> + - enum: >>>>> + - thead,th1520-dc8200 >>>>> + - const: verisilicon,dc >>>> >>>> I do not see any explanation of exception for generic >>>> compatibles, >>>> maybe >>>> except "self-identification" remark. Rob already pointed this >>>> out, so >>>> be >>>> explicit in commit msg why you are using a generic compatible. >>> >>> Well I only get the meaning of "a SoC specific compatible is >>> required" >>> in his review message. >>> >>> I think my binding now requires both a SoC-specific compatible and >>> a >>> generic compatible, which should be okay to satisfy Rob's original >>> review. >> >> You will get then the same questions for me - what justifies generic >> compatible. You should be on this explicit, because otherwise people >> misinterpret some commits and patches, and they think the generic >> compatible is allowed for them as well. > > I came across a comment on Mali Valhall bindings that says `Mali > Valhall GPU model/revision is fully discoverable`, just after the > compatible string. > > Should I add a comment like this, or should I make things more clear in > the commit message? Just say in the commit msg in the sentence about "self-identification facility" that therefore you use generic compatible (or "generic compatible is suitable"). Please trim the context when replying. Look below: > >> >>> >>>> >>>>> + >>>>> + reg: >>>>> + maxItems: 1 >>>>> + >>>>> + interrupts: >>>>> + maxItems: 1 >>>>> + >>>>> + clocks: >>>>> + minItems: 4 >>>> >>>> This is not flexible. Device either has or has not these clocks. >>> >>> The existence of all these clocks are verified by diagrams in >>> manuals >> >> So not flexible, then: >> >>> of two different SoCs with DC8200 (T-Head TH1520 and StarFive >>> JH7110). >>> >>> Maybe a explicit `maxItems: 5` is needed here, but as my DT passes >>> dtbs_check, I don't think it's necessary? >> >> No, drop minItems only. >> >>> >>> Or maybe I should drop the flexibility now and use a `minItems: 5` >>> here >>> (and leave DC8000 support as another story)? (The Eswin EIC7700 >>> manual >>> does not have a diagram showing external connections of the DC, >>> like >>> the two SoCs I mentioned above). >> >> You document here only the devices explicitly mentioned in the >> binding. >> You cannot add here constraints or clocks for some device which is >> not >> in the binding and I see only th1520 in the binding. >> >> Best regards, >> Krzysztof > Is all this needed for me? If it is there I will waste time scrolling through it looking for your questions. Think how your patchset and replies are received by reviewer. Best regards, Krzysztof
在 2025-11-26星期三的 11:22 +0100，Krzysztof Kozlowski写道： > On 26/11/2025 10:50, Icenowy Zheng wrote: > > > > +maintainers: > > > > + - Icenowy Zheng <uwu@icenowy.me> > > > > + > > > > +properties: > > > > + $nodename: > > > > + pattern: "^display@[0-9a-f]+$" > > > > + > > > > + compatible: > > > > + items: > > > > + - enum: > > > > + - thead,th1520-dc8200 > > > > + - const: verisilicon,dc > > > > > > I do not see any explanation of exception for generic > > > compatibles, > > > maybe > > > except "self-identification" remark. Rob already pointed this > > > out, so > > > be > > > explicit in commit msg why you are using a generic compatible. > > > > Well I only get the meaning of "a SoC specific compatible is > > required" > > in his review message. > > > > I think my binding now requires both a SoC-specific compatible and > > a > > generic compatible, which should be okay to satisfy Rob's original > > review. > > You will get then the same questions for me - what justifies generic > compatible. You should be on this explicit, because otherwise people > misinterpret some commits and patches, and they think the generic > compatible is allowed for them as well. > > > > > > > > > > + > > > > + reg: > > > > + maxItems: 1 > > > > + > > > > + interrupts: > > > > + maxItems: 1 > > > > + > > > > + clocks: > > > > + minItems: 4 > > > > > > This is not flexible. Device either has or has not these clocks. > > > > The existence of all these clocks are verified by diagrams in > > manuals > > So not flexible, then: > > > of two different SoCs with DC8200 (T-Head TH1520 and StarFive > > JH7110). > > > > Maybe a explicit `maxItems: 5` is needed here, but as my DT passes > > dtbs_check, I don't think it's necessary? > > No, drop minItems only. Well, okay, sounds reasonable. > > > > > Or maybe I should drop the flexibility now and use a `minItems: 5` > > here > > (and leave DC8000 support as another story)? (The Eswin EIC7700 > > manual > > does not have a diagram showing external connections of the DC, > > like > > the two SoCs I mentioned above). > > You document here only the devices explicitly mentioned in the > binding. > You cannot add here constraints or clocks for some device which is > not > in the binding and I see only th1520 in the binding. > > Best regards, > Krzysztof
在 2025-11-24星期一的 12:01 +0100，Krzysztof Kozlowski写道： > On 24/11/2025 11:52, Icenowy Zheng wrote: > > Verisilicon has a series of display controllers prefixed with DC > > and > > with self-identification facility like their GC series GPUs. > > > > Add a device tree binding for it. > > > > Depends on the specific DC model, it can have either one or two > > display > > outputs, and each display output could be set to DPI signal or "DP" > > signal (which seems to be some plain parallel bus to HDMI > > controllers). > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> > > Wrong DCO chain order. You send it as icenowy.me, so this must be > last > SoB. This identity is the last one certifying DCO. Please kindly read > submitting patches, so you know what you are certifying here. Well I mapped the @iscas.ac.cn mail to the @icenowy.me one in the last patch. Or maybe I should make it the first patch? > > > --- > > Changes in v3: > > - Added SoC-specific compatible string, and arm the binding with > > clock / > > port checking for the specific SoC (with a 2-output DC). > > > > Changes in v2: > > - Fixed misspelt "versilicon" in title. > > - Moved minItems in clock properties to be earlier than items. > > - Re-aligned multi-line clocks and resets in example. > > > > .../bindings/display/verisilicon,dc.yaml | 146 > > ++++++++++++++++++ > > 1 file changed, 146 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > new file mode 100644 > > index 0000000000000..522a544498bea > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > @@ -0,0 +1,146 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Verisilicon DC-series display controllers > > + > > +maintainers: > > + - Icenowy Zheng <uwu@icenowy.me> > > + > > +properties: > > + $nodename: > > + pattern: "^display@[0-9a-f]+$" > > + > > + compatible: > > + items: > > + - enum: > > + - thead,th1520-dc8200 > > + - const: verisilicon,dc > > I do not see any explanation of exception for generic compatibles, > maybe > except "self-identification" remark. Rob already pointed this out, so > be > explicit in commit msg why you are using a generic compatible. > > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + clocks: > > + minItems: 4 > > This is not flexible. Device either has or has not these clocks. > > > + items: > > + - description: DC Core clock > > + - description: DMA AXI bus clock > > + - description: Configuration AHB bus clock > > + - description: Pixel clock of output 0 > > + - description: Pixel clock of output 1 > > + > > > > Best regards, > Krzysztof
On 24/11/2025 12:04, Icenowy Zheng wrote: > 在 2025-11-24星期一的 12:01 +0100，Krzysztof Kozlowski写道： >> On 24/11/2025 11:52, Icenowy Zheng wrote: >>> Verisilicon has a series of display controllers prefixed with DC >>> and >>> with self-identification facility like their GC series GPUs. >>> >>> Add a device tree binding for it. >>> >>> Depends on the specific DC model, it can have either one or two >>> display >>> outputs, and each display output could be set to DPI signal or "DP" >>> signal (which seems to be some plain parallel bus to HDMI >>> controllers). >>>> Signed-off-by: Icenowy Zheng <uwu@icenowy.me> >>> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> >> >> Wrong DCO chain order. You send it as icenowy.me, so this must be >> last >> SoB. This identity is the last one certifying DCO. Please kindly read >> submitting patches, so you know what you are certifying here. > > Well I mapped the @iscas.ac.cn mail to the @icenowy.me one in the last > patch. > > Or maybe I should make it the first patch? .mailmap has effect on b4 and git send-email, so maybe that's the answer. The problem is that: 1. This email has sender address @icenowy.me 2. It's SoB is not the last one. This needs to be fixed. The order of patches for me does not matter, I don't think it would fix the issue here either. Anyway, please trim your responses, so I will not have to scroll through lines of code to find that you did not respond there. Best regards, Krzysztof
在 2025-11-24星期一的 12:09 +0100，Krzysztof Kozlowski写道： > On 24/11/2025 12:04, Icenowy Zheng wrote: > > 在 2025-11-24星期一的 12:01 +0100，Krzysztof Kozlowski写道： > > > On 24/11/2025 11:52, Icenowy Zheng wrote: > > > > Verisilicon has a series of display controllers prefixed with > > > > DC > > > > and > > > > with self-identification facility like their GC series GPUs. > > > > > > > > Add a device tree binding for it. > > > > > > > > Depends on the specific DC model, it can have either one or two > > > > display > > > > outputs, and each display output could be set to DPI signal or > > > > "DP" > > > > signal (which seems to be some plain parallel bus to HDMI > > > > controllers). > > > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> > > > > > > Wrong DCO chain order. You send it as icenowy.me, so this must be > > > last > > > SoB. This identity is the last one certifying DCO. Please kindly > > > read > > > submitting patches, so you know what you are certifying here. > > > > Well I mapped the @iscas.ac.cn mail to the @icenowy.me one in the > > last > > patch. > > > > Or maybe I should make it the first patch? > > .mailmap has effect on b4 and git send-email, so maybe that's the > answer. The problem is that: > 1. This email has sender address @icenowy.me > 2. It's SoB is not the last one. Well, I think a patch that is already sent shouldn't have the From field changing when bumping revision, and a patch modified by one identity should have the modifying one's SoB added. So here I am using the @icenowy.me mail (which can represent the @iscas.ac.cn mail according to the mailmap) to send the patch that is processed by @iscas.ac.cn mail. Sending the patch with @iscas.ac.cn mail needs some extra setup (because of some weird security requirement). > > This needs to be fixed. The order of patches for me does not matter, > I > don't think it would fix the issue here either. > > Anyway, please trim your responses, so I will not have to scroll > through > lines of code to find that you did not respond there. > > > > Best regards, > Krzysztof
On 24/11/2025 12:13, Icenowy Zheng wrote: > 在 2025-11-24星期一的 12:09 +0100，Krzysztof Kozlowski写道： >> On 24/11/2025 12:04, Icenowy Zheng wrote: >>> 在 2025-11-24星期一的 12:01 +0100，Krzysztof Kozlowski写道： >>>> On 24/11/2025 11:52, Icenowy Zheng wrote: >>>>> Verisilicon has a series of display controllers prefixed with >>>>> DC >>>>> and >>>>> with self-identification facility like their GC series GPUs. >>>>> >>>>> Add a device tree binding for it. >>>>> >>>>> Depends on the specific DC model, it can have either one or two >>>>> display >>>>> outputs, and each display output could be set to DPI signal or >>>>> "DP" >>>>> signal (which seems to be some plain parallel bus to HDMI >>>>> controllers). >>>>>> Signed-off-by: Icenowy Zheng <uwu@icenowy.me> >>>>> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> >>>> >>>> Wrong DCO chain order. You send it as icenowy.me, so this must be >>>> last >>>> SoB. This identity is the last one certifying DCO. Please kindly >>>> read >>>> submitting patches, so you know what you are certifying here. >>> >>> Well I mapped the @iscas.ac.cn mail to the @icenowy.me one in the >>> last >>> patch. >>> >>> Or maybe I should make it the first patch? >> >> .mailmap has effect on b4 and git send-email, so maybe that's the >> answer. The problem is that: >> 1. This email has sender address @icenowy.me >> 2. It's SoB is not the last one. > > Well, I think a patch that is already sent shouldn't have the From > field changing when bumping revision, and a patch modified by one > identity should have the modifying one's SoB added. > > So here I am using the @icenowy.me mail (which can represent the > @iscas.ac.cn mail according to the mailmap) to send the patch that is > processed by @iscas.ac.cn mail. > > Sending the patch with @iscas.ac.cn mail needs some extra setup > (because of some weird security requirement). I did not ask you to change from. Please read carefully "You send it as icenowy.me, so this must be last sob" and later I re-iterated. If you insist on not fixing the chain, that's a NAK from me because you must follow the DCO process. Best regards, Krzysztof
On Mon, Nov 24, 2025 at 12:27:09PM +0100, Krzysztof Kozlowski wrote: > On 24/11/2025 12:13, Icenowy Zheng wrote: > > 在 2025-11-24星期一的 12:09 +0100，Krzysztof Kozlowski写道： > >> On 24/11/2025 12:04, Icenowy Zheng wrote: > >>> 在 2025-11-24星期一的 12:01 +0100，Krzysztof Kozlowski写道： > >>>> On 24/11/2025 11:52, Icenowy Zheng wrote: > >>>>> Verisilicon has a series of display controllers prefixed with > >>>>> DC > >>>>> and > >>>>> with self-identification facility like their GC series GPUs. > >>>>> > >>>>> Add a device tree binding for it. > >>>>> > >>>>> Depends on the specific DC model, it can have either one or two > >>>>> display > >>>>> outputs, and each display output could be set to DPI signal or > >>>>> "DP" > >>>>> signal (which seems to be some plain parallel bus to HDMI > >>>>> controllers). > >>>>>> Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > >>>>> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> > >>>> > >>>> Wrong DCO chain order. You send it as icenowy.me, so this must be > >>>> last > >>>> SoB. This identity is the last one certifying DCO. Please kindly > >>>> read > >>>> submitting patches, so you know what you are certifying here. > >>> > >>> Well I mapped the @iscas.ac.cn mail to the @icenowy.me one in the > >>> last > >>> patch. > >>> > >>> Or maybe I should make it the first patch? > >> > >> .mailmap has effect on b4 and git send-email, so maybe that's the > >> answer. The problem is that: > >> 1. This email has sender address @icenowy.me > >> 2. It's SoB is not the last one. > > > > Well, I think a patch that is already sent shouldn't have the From > > field changing when bumping revision, and a patch modified by one > > identity should have the modifying one's SoB added. > > > > So here I am using the @icenowy.me mail (which can represent the > > @iscas.ac.cn mail according to the mailmap) to send the patch that is > > processed by @iscas.ac.cn mail. > > > > Sending the patch with @iscas.ac.cn mail needs some extra setup > > (because of some weird security requirement). > > I did not ask you to change from. Please read carefully "You send it as > icenowy.me, so this must be last sob" > > and later I re-iterated. > > If you insist on not fixing the chain, that's a NAK from me because you > must follow the DCO process. I don't really get what the fuss is with the dual signoff, what's the point having both when they represent the same person? Pretty sure it was you (Krzysztof) and Arnd that told me not to both doing the double signoff. I send lots of stuff w/ my kernel.org address but only ever sign off with my work email since that's where attribution is going.
On 24/11/2025 13:05, Conor Dooley wrote: > On Mon, Nov 24, 2025 at 12:27:09PM +0100, Krzysztof Kozlowski wrote: >> On 24/11/2025 12:13, Icenowy Zheng wrote: >>> 在 2025-11-24星期一的 12:09 +0100，Krzysztof Kozlowski写道： >>>> On 24/11/2025 12:04, Icenowy Zheng wrote: >>>>> 在 2025-11-24星期一的 12:01 +0100，Krzysztof Kozlowski写道： >>>>>> On 24/11/2025 11:52, Icenowy Zheng wrote: >>>>>>> Verisilicon has a series of display controllers prefixed with >>>>>>> DC >>>>>>> and >>>>>>> with self-identification facility like their GC series GPUs. >>>>>>> >>>>>>> Add a device tree binding for it. >>>>>>> >>>>>>> Depends on the specific DC model, it can have either one or two >>>>>>> display >>>>>>> outputs, and each display output could be set to DPI signal or >>>>>>> "DP" >>>>>>> signal (which seems to be some plain parallel bus to HDMI >>>>>>> controllers). >>>>>>>> Signed-off-by: Icenowy Zheng <uwu@icenowy.me> >>>>>>> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> >>>>>> >>>>>> Wrong DCO chain order. You send it as icenowy.me, so this must be >>>>>> last >>>>>> SoB. This identity is the last one certifying DCO. Please kindly >>>>>> read >>>>>> submitting patches, so you know what you are certifying here. >>>>> >>>>> Well I mapped the @iscas.ac.cn mail to the @icenowy.me one in the >>>>> last >>>>> patch. >>>>> >>>>> Or maybe I should make it the first patch? >>>> >>>> .mailmap has effect on b4 and git send-email, so maybe that's the >>>> answer. The problem is that: >>>> 1. This email has sender address @icenowy.me >>>> 2. It's SoB is not the last one. >>> >>> Well, I think a patch that is already sent shouldn't have the From >>> field changing when bumping revision, and a patch modified by one >>> identity should have the modifying one's SoB added. >>> >>> So here I am using the @icenowy.me mail (which can represent the >>> @iscas.ac.cn mail according to the mailmap) to send the patch that is >>> processed by @iscas.ac.cn mail. >>> >>> Sending the patch with @iscas.ac.cn mail needs some extra setup >>> (because of some weird security requirement). >> >> I did not ask you to change from. Please read carefully "You send it as >> icenowy.me, so this must be last sob" >> >> and later I re-iterated. >> >> If you insist on not fixing the chain, that's a NAK from me because you >> must follow the DCO process. > > I don't really get what the fuss is with the dual signoff, what's the > point having both when they represent the same person? Pretty sure it > was you (Krzysztof) and Arnd that told me not to both doing the double > signoff. I do not object having or not having dual signed off HERE. I never said that. Just like I never said "From" has to be changed. So repeating THIRD time: sender's SoB cannot be somewhere else than the last one. ... and before you attribute me another thing I did not say - if you change the "From" field, rules will be different a bit... Best regards, Krzysztof
On Mon, Nov 24, 2025 at 01:08:00PM +0100, Krzysztof Kozlowski wrote: > On 24/11/2025 13:05, Conor Dooley wrote: > > > > I don't really get what the fuss is with the dual signoff, what's the > > point having both when they represent the same person? Pretty sure it > > was you (Krzysztof) and Arnd that told me not to both doing the double > > signoff. > > I do not object having or not having dual signed off HERE. > > I never said that. Just like I never said "From" has to be changed. I didn't say you objected to both being there. *I* am saying that it is probably not worth doing. That's especially the case when it is adding complication about correct ordering of signoffs and maybe interacting with how git-send-email decides to insert From: fields. > So repeating THIRD time: sender's SoB cannot be somewhere else than the > last one. > > ... and before you attribute me another thing I did not say - if you > change the "From" field, rules will be different a bit...
On 24/11/2025 13:20, Conor Dooley wrote: > On Mon, Nov 24, 2025 at 01:08:00PM +0100, Krzysztof Kozlowski wrote: >> On 24/11/2025 13:05, Conor Dooley wrote: >>> >>> I don't really get what the fuss is with the dual signoff, what's the >>> point having both when they represent the same person? Pretty sure it >>> was you (Krzysztof) and Arnd that told me not to both doing the double >>> signoff. >> >> I do not object having or not having dual signed off HERE. >> >> I never said that. Just like I never said "From" has to be changed. > > I didn't say you objected to both being there. *I* am saying that it is Ah, sure. Yes, if both identities work I would propose to skip second SoB. But I also stopped objecting of having two identities listed, as long as they are correct. > probably not worth doing. That's especially the case when it is adding > complication about correct ordering of signoffs and maybe interacting with > how git-send-email decides to insert From: fields. > Best regards, Krzysztof
在 2025-11-24星期一的 13:31 +0100，Krzysztof Kozlowski写道： > On 24/11/2025 13:20, Conor Dooley wrote: > > On Mon, Nov 24, 2025 at 01:08:00PM +0100, Krzysztof Kozlowski > > wrote: > > > On 24/11/2025 13:05, Conor Dooley wrote: > > > > > > > > I don't really get what the fuss is with the dual signoff, > > > > what's the > > > > point having both when they represent the same person? Pretty > > > > sure it > > > > was you (Krzysztof) and Arnd that told me not to both doing the > > > > double > > > > signoff. > > > > > > I do not object having or not having dual signed off HERE. > > > > > > I never said that. Just like I never said "From" has to be > > > changed. > > > > I didn't say you objected to both being there. *I* am saying that > > it is > > Ah, sure. Yes, if both identities work I would propose to skip second > SoB. But I also stopped objecting of having two identities listed, as > long as they are correct. Well it's unfortunate that some policy now requires me to list the second identity. Should I resend the whole patchset with the ISCAS mail? (The problem with it is that it forces application-specific password, and with git-send-email lacking a proper key store, this makes the password a one-time one.) > > > probably not worth doing. That's especially the case when it is > > adding > > complication about correct ordering of signoffs and maybe > > interacting with > > how git-send-email decides to insert From: fields. > > > > > > Best regards, > Krzysztof
On 24/11/2025 16:25, Icenowy Zheng wrote: > 在 2025-11-24星期一的 13:31 +0100，Krzysztof Kozlowski写道： >> On 24/11/2025 13:20, Conor Dooley wrote: >>> On Mon, Nov 24, 2025 at 01:08:00PM +0100, Krzysztof Kozlowski >>> wrote: >>>> On 24/11/2025 13:05, Conor Dooley wrote: >>>>> >>>>> I don't really get what the fuss is with the dual signoff, >>>>> what's the >>>>> point having both when they represent the same person? Pretty >>>>> sure it >>>>> was you (Krzysztof) and Arnd that told me not to both doing the >>>>> double >>>>> signoff. >>>> >>>> I do not object having or not having dual signed off HERE. >>>> >>>> I never said that. Just like I never said "From" has to be >>>> changed. >>> >>> I didn't say you objected to both being there. *I* am saying that >>> it is >> >> Ah, sure. Yes, if both identities work I would propose to skip second >> SoB. But I also stopped objecting of having two identities listed, as >> long as they are correct. > > Well it's unfortunate that some policy now requires me to list the > second identity. No policy asked you... > > Should I resend the whole patchset with the ISCAS mail? You can, it probably would solve the issue, unless you change the author, but why you cannot do what I asked at the beginning - set correct order of SoBs, so the @icenowy.me being the last? Best regards, Krzysztof
在 2025-11-24星期一的 18:40 +0100，Krzysztof Kozlowski写道： > On 24/11/2025 16:25, Icenowy Zheng wrote: > > 在 2025-11-24星期一的 13:31 +0100，Krzysztof Kozlowski写道： > > > On 24/11/2025 13:20, Conor Dooley wrote: > > > > On Mon, Nov 24, 2025 at 01:08:00PM +0100, Krzysztof Kozlowski > > > > wrote: > > > > > On 24/11/2025 13:05, Conor Dooley wrote: > > > > > > > > > > > > I don't really get what the fuss is with the dual signoff, > > > > > > what's the > > > > > > point having both when they represent the same person? > > > > > > Pretty > > > > > > sure it > > > > > > was you (Krzysztof) and Arnd that told me not to both doing > > > > > > the > > > > > > double > > > > > > signoff. > > > > > > > > > > I do not object having or not having dual signed off HERE. > > > > > > > > > > I never said that. Just like I never said "From" has to be > > > > > changed. > > > > > > > > I didn't say you objected to both being there. *I* am saying > > > > that > > > > it is > > > > > > Ah, sure. Yes, if both identities work I would propose to skip > > > second > > > SoB. But I also stopped objecting of having two identities > > > listed, as > > > long as they are correct. > > > > Well it's unfortunate that some policy now requires me to list the > > second identity. > > No policy asked you... Local policy here, sigh... > > > > > Should I resend the whole patchset with the ISCAS mail? > > You can, it probably would solve the issue, unless you change the > author, but why you cannot do what I asked at the beginning - set > correct order of SoBs, so the @icenowy.me being the last? Well because previous revisions of the patch comes with only @icenowy.me SoB, and I think SoB is append-only... > > > Best regards, > Krzysztof
On 24/11/2025 18:42, Icenowy Zheng wrote: >>>> >>>> Ah, sure. Yes, if both identities work I would propose to skip >>>> second >>>> SoB. But I also stopped objecting of having two identities >>>> listed, as >>>> long as they are correct. >>> >>> Well it's unfortunate that some policy now requires me to list the >>> second identity. >> >> No policy asked you... > > Local policy here, sigh... It sounded like you complain about our process... > >> >>> >>> Should I resend the whole patchset with the ISCAS mail? >> >> You can, it probably would solve the issue, unless you change the >> author, but why you cannot do what I asked at the beginning - set >> correct order of SoBs, so the @icenowy.me being the last? > > Well because previous revisions of the patch comes with only > @icenowy.me SoB, and I think SoB is append-only... You cannot change other people SoB, but your own you can. Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.