On Tue, Mar 31, 2026 at 10:00:01AM +0200, Krzysztof Kozlowski wrote: > On 31/03/2026 09:53, Thierry Reding wrote: > > On Mon, Mar 30, 2026 at 01:45:24PM +0200, Krzysztof Kozlowski wrote: > >> On 29/03/2026 17:10, Thierry Reding wrote: > >>> From: Thierry Reding > >>> > >>> Hi ARM SoC maintainers, > >>> > >>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f: > >>> > >>> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800) > >>> > >>> are available in the Git repository at: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm64-dt > >>> > >>> for you to fetch changes up to c70e6bc11d2008fbb19695394b69fd941ab39030: > >>> > >>> arm64: tegra: Add Tegra264 GPIO controllers (2026-03-28 01:36:46 +0100) > >>> > >>> Thanks, > >>> Thierry > >>> > >>> ---------------------------------------------------------------- > >>> arm64: tegra: Device tree changes for v7.1-rc1 > >>> > >>> Various fixes and new additions across a number of devices. GPIO and PCI > >>> are enabled on Tegra264 and the Jetson AGX Thor Developer Kit, allowing > >>> it to boot via network and mass storage. > >>> > >>> ---------------------------------------------------------------- > >>> Diogo Ivo (1): > >>> arm64: tegra: smaug: Enable SPI-NOR flash > >>> > >>> Jon Hunter (1): > >>> arm64: tegra: Fix RTC aliases > >>> > >>> Prathamesh Shete (1): > >>> arm64: tegra: Add Tegra264 GPIO controllers > >>> > >>> Thierry Reding (6): > >>> dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller > >> > >> > >> This is unreviewed/unacked binding where PCI maintainers had 1 day to > >> react to your v3. > > > > Rob gave a reviewed-by on this about a week ago: > > > > https://lore.kernel.org/linux-tegra/177440189257.2451552.18196101830235626115.robh@kernel.org/ > > Rob, although knows a lot about PCI, is not a formally a PCI subsystem > maintainer. > > > > > In my experience the PCI maintainers typically defer review of the DT > > bindings to DT maintainers, so I considered Rob's R-b sufficient. > > Sure and they acknowledge this, that review is done and patch can go > other way, with "Ack". No they don't. The vast majority of the PCI DT bindings patches are indeed applied by the PCI maintainers, but for those that aren't (there are, admittedly, only a handful over the last few years) there were no Acked-bys from the PCI maintainers. > Where is the Ack? Again, this is where your rules start to fail to meet demands. As it is, the only option that we have is to get DT and drivers merged, then wait for an entire cycle before we can merge the DT parts, otherwise we break DT validation. > > > >> Maybe they had more time for previous versions, but > >> nevertheless it is also part of other patchset, so it will get into the > >> kernel other tree and nothing on v3 posting: > >> https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/ > >> gives hints that there will be cross tree merge. > > > > Maybe look at the cover letter: > > > > https://lore.kernel.org/all/20260326135855.2795149-1-thierry.reding@kernel.org/ > > > > I clearly pointed out the build dependencies and suggested a shared > > branch to resolve them in both trees. Given that the bindings were > > No problem, that's a valid solution. Can you point me with a lore link > to the shared branch posting (these tags/pull requests must be posted on > the lists)? Or to an ack from PCI maintainers? > > The commit itself does not have an Ack, but maybe was just missed. Yes, the DT bindings patch does not have an Acked-by, but again, I didn't think that was necessary, especially since we were going to have a cross-merge anyway. Here's the PR for PCI: https://lore.kernel.org/linux-tegra/20260329155040.1448158-1-thierry.reding@kernel.org/ Thierry