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
> '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?
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.
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
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
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
© 2016 - 2025 Red Hat, Inc.