[GIT PULL 1/4] dt-bindings: Changes for v6.20-rc1

[Thierry Reding]

On Fri, Jan 23, 2026 at 08:43:44AM +0100, Krzysztof Kozlowski wrote:
> On 22/01/2026 13:20, Thierry Reding wrote:
> > On Thu, Jan 22, 2026 at 12:02:04PM +0100, Geert Uytterhoeven wrote:
> >> Hi Krzysztof,
> >>
> >> On Thu, 22 Jan 2026 at 11:08, Krzysztof Kozlowski <krzk at kernel.org> wrote:
> >>> On Sun, Jan 18, 2026 at 09:03:00AM +0100, Thierry Reding wrote:
> >>>> The following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:
> >>>>
> >>>>   Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-6.20-dt-bindings
> >>>>
> >>>> for you to fetch changes up to b2788f6320722d6059f849f35a77eb082608c627:
> >>>>
> >>>>   ASoC: dt-bindings: realtek,rt5640: Document port node (2026-01-17 01:58:18 +0100)
> >>>>
> >>>> Thanks,
> >>>> Thierry
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> dt-bindings: Changes for v6.20-rc1
> >>>>
> >>>> This series updates various DT bindings for Tegra architecture,
> >>>> primarily focusing on schema validation fixes and new feature
> >>>> documentation for Tegra234 and Tegra264 SoCs. Key changes include
> >>>> correcting realtek,rt5640 audio codec bindings (adding missing ports,
> >>>> clocks, and jack-detect sources), converting Tegra20 NAND bindings to
> >>>> YAML, and updating memory, DMA, and IOMMU definitions for Tegra264
> >>>> (introducing CMDQV and DBB clock support). Additionally, it resolves
> >>>> legacy warnings for Tegra30/132 display and VI interfaces.
> >>>
> >>> Same comment as was for Geert, I am surprised to see DT bindings as
> >>> separate pull and I see drivers were alerady merged, so I will defer
> >>> entire Tegra pull to Arnd.
> >>
> >> The soc tree used to have a separate branch for dt-bindings.
> >> Hence several soc submaintainers still use that split for their PRs.
> > 
> > Yeah. I usually also only put things in the PR for ARM SoC that have no
> > related driver changes (fixups, conversions, ...) and therefore nobody
> > else feels responsible for picking up.
> 
> Why these are still separate? There are few options here:
> 1. These were needed by the drivers you sent in pull: should be in that
> driver pull. It seems Geert confirmed this was the case with Renesas.
> BTW, checkpatch asks for that somewhat - you will have checkpatch
> warning of undocumented compatibles and you are not suppose to have such
> warnings.

Yes, most of the time they'll be in this type of pull request and I
don't usually apply them when they are in this category.

> 2. These were needed by the new DTS you sent in pull: should be in that
> DTS pull.

This happens sometimes. In that case what I will usually do is have them
on a separate branch that is merged into the branch with the DTS changes
so that they are separate but the dependency is explicit.

> 3. These were not needed by anything yet or they document compatibles
> already in the tree: that's the only case I imagine having them on
> separate branch. You can take such bindings when subsystem maintainers
> do not - they ignore them. 90% of bindings in this pull are not like that!

This is typically the majority of patches that end up in the Tegra
dt-bindings branch. It's random assortments of things that nobody seems
to feel responsible for and they concern primarily Tegra, so I consider
the Tegra tree to be the fallback and will vacuum these up.

In this particular case I was heavily relying on Patchwork and missed
that Mark had already applied them. Jon pointed it out to me, and so did
Rob, so I removed them. Unfortunately, I didn't send out an updated PR
in time, so Arnd ended up pulling this into ARM SoC.

Let me check in with Arnd to see if that one PR can be backed out, so we
can iron this out.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260127/93780b94/attachment-0001.sig>