linux-next: manual merge of the i2c tree with the arm-soc tree

linux-next: manual merge of the i2c tree with the arm-soc tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

Hi all,

's linux-next merge of the i2c tree got a conflict in:

  Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml

between commit:

  804ebc2bdcc85 ("dt-bindings: i2c: nvidia,tegra20-i2c: Document Tegra264 I2C")

from the arm-soc tree and commit:

  69329daf16af7 ("dt-bindings: i2c: nvidia,tegra20-i2c: Add Tegra256 I2C compatible")

from the i2c tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
index f0693b872cb6b,32c3b69ccf342..0000000000000
--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
@@@ -80,12 -80,11 +80,17 @@@ properties
            support for 64 KiB transactions whereas earlier chips supported no
            more than 4 KiB per transactions.
          const: nvidia,tegra194-i2c
+       - description: |
+           Tegra256 has 8 generic I2C controllers. The controllers are similar to
+           the previous generations, but have a different parent clock and hence
+           the timing parameters are configured differently.
+         const: nvidia,tegra256-i2c
 +      - description:
 +          Tegra264 has 17 generic I2C controllers, two of which are in the AON
 +          (always-on) partition of the SoC. In addition to the features from
 +          Tegra194, a SW mutex register is added to support use of the same I2C
 +          instance across multiple firmwares.
 +        const: nvidia,tegra264-i2c
  
    reg:
      maxItems: 1
@@@ -192,7 -191,7 +197,11 @@@ allOf
              contains:
                enum:
                  - nvidia,tegra194-i2c
+                 - nvidia,tegra256-i2c
 +                - nvidia,tegra264-i2c
      then:
        required:
          - resets

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the i2c tree with the arm-soc tree

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]


> 's linux-next merge of the i2c tree got a conflict in:
> 
>   Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
> 
> between commit:
> 
>   804ebc2bdcc85 ("dt-bindings: i2c: nvidia,tegra20-i2c: Document Tegra264 I2C")
> 
> from the arm-soc tree and commit:

? Usually such patches go via I2C? And v6 was still under discussion? Do
i miss something?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: linux-next: manual merge of the i2c tree with the arm-soc tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Mon, Sep 15, 2025 at 11:04:56PM +0200, Wolfram Sang wrote:

> > 's linux-next merge of the i2c tree got a conflict in:
> > 
> >   Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
> > 
> > between commit:
> > 
> >   804ebc2bdcc85 ("dt-bindings: i2c: nvidia,tegra20-i2c: Document Tegra264 I2C")
> > 
> > from the arm-soc tree and commit:

> ? Usually such patches go via I2C? And v6 was still under discussion? Do
> i miss something?

IIRC it came into arm-soc from Tegra but ICBW there.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the i2c tree with the arm-soc tree

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On Mon, Sep 15, 2025 at 11:13:06PM +0100, Mark Brown wrote:
> On Mon, Sep 15, 2025 at 11:04:56PM +0200, Wolfram Sang wrote:
> 
> > > 's linux-next merge of the i2c tree got a conflict in:
> > > 
> > >   Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
> > > 
> > > between commit:
> > > 
> > >   804ebc2bdcc85 ("dt-bindings: i2c: nvidia,tegra20-i2c: Document Tegra264 I2C")
> > > 
> > > from the arm-soc tree and commit:
> 
> > ? Usually such patches go via I2C? And v6 was still under discussion? Do
> > i miss something?
> 
> IIRC it came into arm-soc from Tegra but ICBW there.

In the past I've usually picked up DT bindings patches into the Tegra
tree because they are needed in order to validate the corresponding DT
changes.

Note also that I only applied the DT bindings patch from the v6 series
because it was already acked by device tree maintainers and there have
not been any objections to the DT bits, nor are they relevant to the
driver changes still being reviewed.

In the meantime, we have follow-on patches for Tegra264 that are being
blocked by the lack of I2C DT nodes. In order to unblock those I want to
get the DT bindings patch merged along with the DT changes for v6.18 so
that we can make progress on these other patches.

We'll continue revising the driver series and address all the feedback
that's been provided.

Thanks,
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: linux-next: manual merge of the i2c tree with the arm-soc tree

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

Hi Thierry,

> Note also that I only applied the DT bindings patch from the v6 series
> because it was already acked by device tree maintainers and there have
> not been any objections to the DT bits, nor are they relevant to the
> driver changes still being reviewed.

May I suggest then to send the DT bindings patch seperately next time?
We can apply it earlier then, so you can continue your work. I prefer to
take binding patches via the I2C tree so I can chime in if necessary and
also to keep the merge conflicts low.

Happy hacking,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: linux-next: manual merge of the i2c tree with the arm-soc tree

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Wed, Sep 17, 2025 at 11:14:45PM +0200, Wolfram Sang wrote:
> Hi Thierry,
> 
> > Note also that I only applied the DT bindings patch from the v6 series
> > because it was already acked by device tree maintainers and there have
> > not been any objections to the DT bits, nor are they relevant to the
> > driver changes still being reviewed.
> 
> May I suggest then to send the DT bindings patch seperately next time?
> We can apply it earlier then, so you can continue your work. I prefer to
> take binding patches via the I2C tree so I can chime in if necessary and
> also to keep the merge conflicts low.

Yes, maybe sending DT patches separately is a better approach. I'm sure
somebody else will find that objectionable, but... oh well.

checkpatch also tends to warn about patches using compatible strings
that it cannot find any trace of, which has always been a good argument
in favour of sending series with all of the pieces.

So if you were to pick up the DT bindings patch, then I still cannot
apply patches to the Tegra tree that use compatible strings introduced
in that DT bindings patch because it'll cause checkpatch to warn about
it. I can of course ignore that warning, but the warning causes things
like b4 to fail, which then makes all of these tools almost pointless
to use.

Honestly, I don't know what the right solution is here. Seems to me like
no matter how you do it there's some downside.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

linux-next: manual merge of the i2c tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

Hi all,

Today's linux-next merge of the i2c tree got a conflict in:

  include/uapi/linux/virtio_ids.h

between commit:

  46abe13b5e3d ("firmware: arm_scmi: Add virtio transport")

from the arm-soc tree and commit:

  8fb12751ac78 ("i2c: virtio: add a virtio i2c frontend driver")

from the i2c tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/virtio_ids.h
index f74155f6882d,99aa27b100bc..000000000000
--- a/include/uapi/linux/virtio_ids.h
+++ b/include/uapi/linux/virtio_ids.h
@@@ -55,7 -55,7 +55,8 @@@
  #define VIRTIO_ID_FS			26 /* virtio filesystem */
  #define VIRTIO_ID_PMEM			27 /* virtio pmem */
  #define VIRTIO_ID_MAC80211_HWSIM	29 /* virtio mac80211-hwsim */
 +#define VIRTIO_ID_SCMI			32 /* virtio SCMI */
+ #define VIRTIO_ID_I2C_ADAPTER		34 /* virtio i2c adapter */
  #define VIRTIO_ID_BT			40 /* virtio bluetooth */
  
  /*

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]