[PATCH v2 0/2] dt-bindings: media: qcom,x1e80100-camss: two minor changes

[PATCH v2 0/2] dt-bindings: media: qcom,x1e80100-camss: two minor changes

[Vladimir Zapolskiy]

The series contains a couple of minor improvements to qcom,x1e80100-camss
device tree binding scheme.

Changes from v1 to v2:
* removed Fixes tag from both changes per discussion (Bryan, Dmitry),
* added a note to 1/2 commit message that is an ABI change (Dmitry),
* added Bryan's Reviewed-by tag to 2/2 change.

Links to v1:
* 1/2 https://lore.kernel.org/all/20250610083318.2773727-1-vladimir.zapolskiy@linaro.org/
* 2/2 https://lore.kernel.org/all/20250610083318.2773727-2-vladimir.zapolskiy@linaro.org/

Vladimir Zapolskiy (2):
  dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically
  dt-bindings: media: qcom,x1e80100-camss: Fix isp unit address

 .../bindings/media/qcom,x1e80100-camss.yaml          | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

-- 
2.49.0

[PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Vladimir Zapolskiy]

Sort the entries of interconnect and interconnect-names lists in the
alphabetical order of values in the latter property.

This is a DT ABI change, however it is supposed to be acceptable,
because there are no users of this device tree binding in the upstream.

Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 .../devicetree/bindings/media/qcom,x1e80100-camss.yaml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
index 113565cf2a99..b18c7d1794ed 100644
--- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
@@ -100,8 +100,8 @@ properties:
     items:
       - const: ahb
       - const: hf_mnoc
-      - const: sf_mnoc
       - const: sf_icp_mnoc
+      - const: sf_mnoc
 
   iommus:
     maxItems: 8
@@ -320,15 +320,15 @@ examples:
                              &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
                             <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
                              &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
-                            <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
-                             &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
                             <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
+                             &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+                            <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
                              &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
 
             interconnect-names = "ahb",
                                  "hf_mnoc",
-                                 "sf_mnoc",
-                                 "sf_icp_mnoc";
+                                 "sf_icp_mnoc",
+                                 "sf_mnoc";
 
             iommus = <&apps_smmu 0x800 0x60>,
                      <&apps_smmu 0x860 0x60>,
-- 
2.49.0

[PATCH v2 2/2] dt-bindings: media: qcom,x1e80100-camss: Fix isp unit address

[Vladimir Zapolskiy]

According to the devicetree specification a unit address shall match
the first address value of the reg property.

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 .../devicetree/bindings/media/qcom,x1e80100-camss.yaml          | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
index b18c7d1794ed..303c1458d410 100644
--- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
@@ -189,7 +189,7 @@ examples:
         #address-cells = <2>;
         #size-cells = <2>;
 
-        camss: isp@acb6000 {
+        camss: isp@acb7000 {
             compatible = "qcom,x1e80100-camss";
 
             reg = <0 0x0acb7000 0 0x2000>,
-- 
2.49.0

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Krzysztof Kozlowski]

On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
> Sort the entries of interconnect and interconnect-names lists in the
> alphabetical order of values in the latter property.

We do not sort these entries alphabetically and you did not explain why
you are doing this.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Vladimir Zapolskiy]

On 6/24/25 13:10, Krzysztof Kozlowski wrote:
> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>> Sort the entries of interconnect and interconnect-names lists in the
>> alphabetical order of values in the latter property.
> 
> We do not sort these entries alphabetically and you did not explain why
> you are doing this.

I did it, because I assume that the preference is to sort all named
values alphanumerically.

Since my assumption is incorrect, I kindly ask to let me know, which
properties should have values sorted by alphanumerical order of
${property}-names values and which are not, there should be a method
to distinguish such different properties.

Below is a list of the most popular properties which are coupled with
"-names" suffixed properties:

clock
clock-output
dma
gpio-line
interconnect
interrupt
io-channel
iommu
mbox
memory-region
nvmem-cell
nvmem
phy
pinctrl
power-domain
pwm
reg
reset

Thank you in advance.

-- 
Best wishes,
Vladimir

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Krzysztof Kozlowski]

On 24/06/2025 13:38, Vladimir Zapolskiy wrote:
> On 6/24/25 13:10, Krzysztof Kozlowski wrote:
>> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>>> Sort the entries of interconnect and interconnect-names lists in the
>>> alphabetical order of values in the latter property.
>>
>> We do not sort these entries alphabetically and you did not explain why
>> you are doing this.
> 
> I did it, because I assume that the preference is to sort all named
> values alphanumerically.

Where is such preference documented?

> 
> Since my assumption is incorrect, I kindly ask to let me know, which
> properties should have values sorted by alphanumerical order of
> ${property}-names values and which are not, there should be a method
> to distinguish such different properties.

None of them "should" as in "break ABI" or "change something later". I
don't understand why again we keep discussing such trivialities which
are neither documented nor have ever been expressed as desired by any
maintainers. This reminds me how much wasted cycles we spend on
discussions on reworking all camss bindings so they will have some sort
by address. Entire discussion was ignoring my clear feedback and the
only, only one rule we communicated, just dragging it more and more.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Vladimir Zapolskiy]

On 6/24/25 15:04, Krzysztof Kozlowski wrote:
> On 24/06/2025 13:38, Vladimir Zapolskiy wrote:
>> On 6/24/25 13:10, Krzysztof Kozlowski wrote:
>>> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>>>> Sort the entries of interconnect and interconnect-names lists in the
>>>> alphabetical order of values in the latter property.
>>>
>>> We do not sort these entries alphabetically and you did not explain why
>>> you are doing this.
>>
>> I did it, because I assume that the preference is to sort all named
>> values alphanumerically.
> 
> Where is such preference documented?

There is no such preference documented, as I stated it was my assumption
and it was based on your firm insistance to apply a particular sorting
order for regs, clocks and interrupts properties. Apparently you are
fine with out of the same sort order for 'interconnects' values, the
criteria of picked properties remains unclear for me.

>>
>> Since my assumption is incorrect, I kindly ask to let me know, which
>> properties should have values sorted by alphanumerical order of
>> ${property}-names values and which are not, there should be a method
>> to distinguish such different properties.
> 
> None of them "should" as in "break ABI" or "change something later". I
> don't understand why again we keep discussing such trivialities which

A triviality for you is not a universal triviality, that's why people
ask questions to remove uncertainty, the question asked above has never
been discussed with me, and the answer is not given also.

Regarding "breaking the ABI", it's been discussed earlier that no dt
binding user in the upstream implies no ABI break practically.

I believe this change shall be dropped from the series, it's not
important at all.

-- 
Best wishes,
Vladimir

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Krzysztof Kozlowski]

On 24/06/2025 15:29, Vladimir Zapolskiy wrote:
> On 6/24/25 15:04, Krzysztof Kozlowski wrote:
>> On 24/06/2025 13:38, Vladimir Zapolskiy wrote:
>>> On 6/24/25 13:10, Krzysztof Kozlowski wrote:
>>>> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>>>>> Sort the entries of interconnect and interconnect-names lists in the
>>>>> alphabetical order of values in the latter property.
>>>>
>>>> We do not sort these entries alphabetically and you did not explain why
>>>> you are doing this.
>>>
>>> I did it, because I assume that the preference is to sort all named
>>> values alphanumerically.
>>
>> Where is such preference documented?
> 
> There is no such preference documented, as I stated it was my assumption
> and it was based on your firm insistance to apply a particular sorting
> order for regs, clocks and interrupts properties. Apparently you are

Hm? And the rule is by name? I don't think I ever expressed that or
insisted on some sorting by name. During previous talks on camss
numerous times you ignored the ONLY rule of sorting I was insisting:
keep the same as all other devices. That was the one and only rule.

> fine with out of the same sort order for 'interconnects' values, the
> criteria of picked properties remains unclear for me.

I don't understand why it is unclear. That time with Bryan you both
received VERY CLEAR feedback from me: there is no such rule of sorting
any values. Yet you were pushing the discussion and patchset like there
was something.


Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Krzysztof Kozlowski]

On 25/06/2025 08:58, Krzysztof Kozlowski wrote:
> On 24/06/2025 15:29, Vladimir Zapolskiy wrote:
>> On 6/24/25 15:04, Krzysztof Kozlowski wrote:
>>> On 24/06/2025 13:38, Vladimir Zapolskiy wrote:
>>>> On 6/24/25 13:10, Krzysztof Kozlowski wrote:
>>>>> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>>>>>> Sort the entries of interconnect and interconnect-names lists in the
>>>>>> alphabetical order of values in the latter property.
>>>>>
>>>>> We do not sort these entries alphabetically and you did not explain why
>>>>> you are doing this.
>>>>
>>>> I did it, because I assume that the preference is to sort all named
>>>> values alphanumerically.
>>>
>>> Where is such preference documented?
>>
>> There is no such preference documented, as I stated it was my assumption
>> and it was based on your firm insistance to apply a particular sorting
>> order for regs, clocks and interrupts properties. Apparently you are
> 
> Hm? And the rule is by name? I don't think I ever expressed that or
> insisted on some sorting by name. During previous talks on camss
> numerous times you ignored the ONLY rule of sorting I was insisting:
> keep the same as all other devices. That was the one and only rule.
> 
>> fine with out of the same sort order for 'interconnects' values, the
>> criteria of picked properties remains unclear for me.
> 
> I don't understand why it is unclear. That time with Bryan you both
> received VERY CLEAR feedback from me: there is no such rule of sorting
> any values. Yet you were pushing the discussion and patchset like there
> was something.
> 
Look, the first reply:

https://lore.kernel.org/all/65e5796a-8b8d-44f0-aef4-e420083b9d52@kernel.org/

"You are supposed to keep the same order, as much as
possible."

What rule is unclear here?

Even more precise reply from me:

https://lore.kernel.org/all/8f11c99b-f3ca-4501-aec4-0795643fc3a9@kernel.org/

"I don't imply sorting by name is any better. "

And:

"The only rule is that all
devices from same family type must have the same order."


And now you claim there was from me "firm insistance to apply a
particular sorting" in context of name?

So again, my entire feedback repeated multiple times during that
discussion is totally ignored and twisted to some fake new rule of name
sorting.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Vladimir Zapolskiy]

On 6/25/25 10:01, Krzysztof Kozlowski wrote:
> On 25/06/2025 08:58, Krzysztof Kozlowski wrote:
>> On 24/06/2025 15:29, Vladimir Zapolskiy wrote:
>>> On 6/24/25 15:04, Krzysztof Kozlowski wrote:
>>>> On 24/06/2025 13:38, Vladimir Zapolskiy wrote:
>>>>> On 6/24/25 13:10, Krzysztof Kozlowski wrote:
>>>>>> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>>>>>>> Sort the entries of interconnect and interconnect-names lists in the
>>>>>>> alphabetical order of values in the latter property.
>>>>>>
>>>>>> We do not sort these entries alphabetically and you did not explain why
>>>>>> you are doing this.
>>>>>
>>>>> I did it, because I assume that the preference is to sort all named
>>>>> values alphanumerically.
>>>>
>>>> Where is such preference documented?
>>>
>>> There is no such preference documented, as I stated it was my assumption
>>> and it was based on your firm insistance to apply a particular sorting
>>> order for regs, clocks and interrupts properties. Apparently you are
>>
>> Hm? And the rule is by name? I don't think I ever expressed that or
>> insisted on some sorting by name. During previous talks on camss
>> numerous times you ignored the ONLY rule of sorting I was insisting:
>> keep the same as all other devices. That was the one and only rule.
>>
>>> fine with out of the same sort order for 'interconnects' values, the
>>> criteria of picked properties remains unclear for me.
>>
>> I don't understand why it is unclear. That time with Bryan you both
>> received VERY CLEAR feedback from me: there is no such rule of sorting
>> any values. Yet you were pushing the discussion and patchset like there
>> was something.
>>
> Look, the first reply:
> 
> https://lore.kernel.org/all/65e5796a-8b8d-44f0-aef4-e420083b9d52@kernel.org/
> 
> "You are supposed to keep the same order, as much as
> possible."
> 
> What rule is unclear here?

At the moment of the given comment "the same order" was not "sorting by
values", it was "sorting to address".

Check the next message right in the same thread:

https://lore.kernel.org/all/c1539cce-92eb-43fc-9267-f6e002611bbb@linaro.org/

"We always sort by address". And that was the correct statement at
the time of the discussion.

Did it help to "keep the same order" in any sense? No, the message was
plainly ignored, and after the long discussion with you the sorting order
has been brutally enforced to become the new "sorting by values" order,
and to my sincere today's surprise there is no such rule. Apparently now
I have to believe it was Bryan's and my voluntary and deliberate decision
to change the sorting order, all right.

> Even more precise reply from me:
> 
> https://lore.kernel.org/all/8f11c99b-f3ca-4501-aec4-0795643fc3a9@kernel.org/
> 
> "I don't imply sorting by name is any better."
> 
> And:
> 
> "The only rule is that all
> devices from same family type must have the same order."
> 
> 
> And now you claim there was from me "firm insistance to apply a
> particular sorting" in context of name?
> 
> So again, my entire feedback repeated multiple times during that
> discussion is totally ignored and twisted to some fake new rule of name
> sorting.
> 

Thank you for the explanation, and not just your messages are ignored
sometimes, it happens with anybody regularly.

--
Best wishes,
Vladimir

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Bryan O'Donoghue]

On 25/06/2025 15:07, Vladimir Zapolskiy wrote:
> On 6/25/25 10:01, Krzysztof Kozlowski wrote:
>> On 25/06/2025 08:58, Krzysztof Kozlowski wrote:
>>> On 24/06/2025 15:29, Vladimir Zapolskiy wrote:
>>>> On 6/24/25 15:04, Krzysztof Kozlowski wrote:
>>>>> On 24/06/2025 13:38, Vladimir Zapolskiy wrote:
>>>>>> On 6/24/25 13:10, Krzysztof Kozlowski wrote:
>>>>>>> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>>>>>>>> Sort the entries of interconnect and interconnect-names lists in 
>>>>>>>> the
>>>>>>>> alphabetical order of values in the latter property.
>>>>>>>
>>>>>>> We do not sort these entries alphabetically and you did not 
>>>>>>> explain why
>>>>>>> you are doing this.
>>>>>>
>>>>>> I did it, because I assume that the preference is to sort all named
>>>>>> values alphanumerically.
>>>>>
>>>>> Where is such preference documented?
>>>>
>>>> There is no such preference documented, as I stated it was my 
>>>> assumption
>>>> and it was based on your firm insistance to apply a particular sorting
>>>> order for regs, clocks and interrupts properties. Apparently you are
>>>
>>> Hm? And the rule is by name? I don't think I ever expressed that or
>>> insisted on some sorting by name. During previous talks on camss
>>> numerous times you ignored the ONLY rule of sorting I was insisting:
>>> keep the same as all other devices. That was the one and only rule.
>>>
>>>> fine with out of the same sort order for 'interconnects' values, the
>>>> criteria of picked properties remains unclear for me.
>>>
>>> I don't understand why it is unclear. That time with Bryan you both
>>> received VERY CLEAR feedback from me: there is no such rule of sorting
>>> any values. Yet you were pushing the discussion and patchset like there
>>> was something.
>>>
>> Look, the first reply:
>>
>> https://lore.kernel.org/all/65e5796a-8b8d-44f0-aef4- 
>> e420083b9d52@kernel.org/
>>
>> "You are supposed to keep the same order, as much as
>> possible."
>>
>> What rule is unclear here?
> 
> At the moment of the given comment "the same order" was not "sorting by
> values", it was "sorting to address".
> 
> Check the next message right in the same thread:
> 
> https://lore.kernel.org/all/c1539cce-92eb-43fc-9267- 
> f6e002611bbb@linaro.org/
> 
> "We always sort by address". And that was the correct statement at
> the time of the discussion.
> 
> Did it help to "keep the same order" in any sense? No, the message was
> plainly ignored, and after the long discussion with you the sorting order
> has been brutally enforced to become the new "sorting by values" order,
> and to my sincere today's surprise there is no such rule. Apparently now
> I have to believe it was Bryan's and my voluntary and deliberate decision
> to change the sorting order, all right.
> 
>> Even more precise reply from me:
>>
>> https://lore.kernel.org/all/8f11c99b-f3ca-4501- 
>> aec4-0795643fc3a9@kernel.org/
>>
>> "I don't imply sorting by name is any better."
>>
>> And:
>>
>> "The only rule is that all
>> devices from same family type must have the same order."
>>
>>
>> And now you claim there was from me "firm insistance to apply a
>> particular sorting" in context of name?
>>
>> So again, my entire feedback repeated multiple times during that
>> discussion is totally ignored and twisted to some fake new rule of name
>> sorting.
>>
> 
> Thank you for the explanation, and not just your messages are ignored
> sometimes, it happens with anybody regularly.
> 
> -- 
> Best wishes,
> Vladimir

Lets put a cap on this discussion.

The direction is to follow what's already upstream.

---
bod

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Krzysztof Kozlowski]

On 25/06/2025 16:07, Vladimir Zapolskiy wrote:
> On 6/25/25 10:01, Krzysztof Kozlowski wrote:
>> On 25/06/2025 08:58, Krzysztof Kozlowski wrote:
>>> On 24/06/2025 15:29, Vladimir Zapolskiy wrote:
>>>> On 6/24/25 15:04, Krzysztof Kozlowski wrote:
>>>>> On 24/06/2025 13:38, Vladimir Zapolskiy wrote:
>>>>>> On 6/24/25 13:10, Krzysztof Kozlowski wrote:
>>>>>>> On 24/06/2025 11:42, Vladimir Zapolskiy wrote:
>>>>>>>> Sort the entries of interconnect and interconnect-names lists in the
>>>>>>>> alphabetical order of values in the latter property.
>>>>>>>
>>>>>>> We do not sort these entries alphabetically and you did not explain why
>>>>>>> you are doing this.
>>>>>>
>>>>>> I did it, because I assume that the preference is to sort all named
>>>>>> values alphanumerically.
>>>>>
>>>>> Where is such preference documented?
>>>>
>>>> There is no such preference documented, as I stated it was my assumption
>>>> and it was based on your firm insistance to apply a particular sorting
>>>> order for regs, clocks and interrupts properties. Apparently you are
>>>
>>> Hm? And the rule is by name? I don't think I ever expressed that or
>>> insisted on some sorting by name. During previous talks on camss
>>> numerous times you ignored the ONLY rule of sorting I was insisting:
>>> keep the same as all other devices. That was the one and only rule.
>>>
>>>> fine with out of the same sort order for 'interconnects' values, the
>>>> criteria of picked properties remains unclear for me.
>>>
>>> I don't understand why it is unclear. That time with Bryan you both
>>> received VERY CLEAR feedback from me: there is no such rule of sorting
>>> any values. Yet you were pushing the discussion and patchset like there
>>> was something.
>>>
>> Look, the first reply:
>>
>> https://lore.kernel.org/all/65e5796a-8b8d-44f0-aef4-e420083b9d52@kernel.org/
>>
>> "You are supposed to keep the same order, as much as
>> possible."
>>
>> What rule is unclear here?
> 
> At the moment of the given comment "the same order" was not "sorting by
> values", it was "sorting to address".
> 
> Check the next message right in the same thread:
> 
> https://lore.kernel.org/all/c1539cce-92eb-43fc-9267-f6e002611bbb@linaro.org/
> 
> "We always sort by address". And that was the correct statement at

Hm? This was not a true statement and anyway this was not from me. Why
are you both with Bryan creating some fake rules and then later use them
in arguments in discussions?

We don't talk here what sort of rule other person invented.

> the time of the discussion.
> 
> Did it help to "keep the same order" in any sense? No, the message was
> plainly ignored, and after the long discussion with you the sorting order

And that's some sort of my job to read every possible comment
everywhere? I have way too many emails to respond to, so no, I will
ignore most of them.

> has been brutally enforced to become the new "sorting by values" order,

What? Where? This never happened!

Point me to any guidance by DT maintainers. Not to some other people
telling you random stuff.

> and to my sincere today's surprise there is no such rule. Apparently now
> I have to believe it was Bryan's and my voluntary and deliberate decision
> to change the sorting order, all right.

Point to arguments where any DT maintainer asked you to sort by value.


Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: media: qcom,x1e80100-camss: Sort interconnects alphabetically

[Bryan O'Donoghue]

On 26/06/2025 10:11, Krzysztof Kozlowski wrote:
> Hm? This was not a true statement and anyway this was not from me. Why
> are you both with Bryan creating some fake rules and then later use them
> in arguments in discussions?
> 
> We don't talk here what sort of rule other person invented.

Ah here lads stop dragging this up

https://lore.kernel.org/all/c1539cce-92eb-43fc-9267-f6e002611bbb@linaro.org/
Date: Mon, 30 Sep 2024 09:55:19 +0100	

We've subsequently discussed this twice now face-to-face, subsequently.

It's very clearly not OK to reorder the interconnect nodes.

Stop @ me about this.

---
bod