[GIT PULL 1/7] Device tree bindings changes for v7.4-rc1

[GIT PULL 1/7] Device tree bindings changes for v7.4-rc1

[Thierry Reding]

From: Thierry Reding <thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit cee9395acd8043be0644b25c34bfa86623f2b935:

  Linux 7.3-rc1 (2026-08-30 13:34:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.4-dt-bindings

for you to fetch changes up to 8370532640fa15b9480ba19af9314d3266c92aef:

  dt-bindings: soc: tegra: pmc: Document Tegra210B01 (2026-10-03 00:39:13 +0200)

Thanks,
Thierry

----------------------------------------------------------------
Device tree bindings changes for v7.4-rc1

This contains a minor fix for the Tegra132 external memory controller
bindings as well as additions of compatible strings for Tegra264 and
Tegra210-B01 to existing bindings. Also, the new Motorola Artix 4G and
Droid X2 devices are documented.

----------------------------------------------------------------
Aaron Kling (1):
      dt-bindings: soc: tegra: pmc: Document Tegra210B01

Svyatoslav Ryhel (1):
      dt-bindings: arm: tegra: Add Motorola Artix 4G and Droid X2

Thierry Reding (2):
      dt-bindings: memory: tegra: Fix Tegra132 compatible string
      dt-bindings: fuse: Document compatible string for Tegra264 FUSE

 Documentation/devicetree/bindings/arm/tegra.yaml               |  6 ++++++
 .../devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml          |  1 +
 .../bindings/memory-controllers/nvidia,tegra124-emc.yaml       | 10 +++++++---
 .../bindings/memory-controllers/nvidia,tegra124-mc.yaml        |  1 +
 .../devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml      |  5 ++++-
 5 files changed, 19 insertions(+), 4 deletions(-)

[GIT PULL 2/7] ARM: Core changes for v7.4-rc1

[Thierry Reding]

From: Thierry Reding <thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit cee9395acd8043be0644b25c34bfa86623f2b935:

  Linux 7.3-rc1 (2026-08-30 13:34:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.4-arm-core

for you to fetch changes up to 7b6c372ee6f28435e9c793808933258dd9938bf0:

  ARM: tegra: Fix Trun -> Turn typo (2026-10-03 00:06:57 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: Core changes for v7.4-rc1

Not much to see here, just a single trivial typofix.

----------------------------------------------------------------
Thierry Reding (1):
      ARM: tegra: Fix Trun -> Turn typo

 arch/arm/mach-tegra/sleep.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[GIT PULL 3/7] soc/tegra: Changes for v7.4-rc1

[Thierry Reding]

From: Thierry Reding <thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit cee9395acd8043be0644b25c34bfa86623f2b935:

  Linux 7.3-rc1 (2026-08-30 13:34:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.4-soc

for you to fetch changes up to 4eaed7ea6ab36e1160d660b05551702c36dfed6c:

  soc/tegra: flowctrl: Release OF node reference on error (2026-10-03 00:47:52 +0200)

Thanks,
Thierry

----------------------------------------------------------------
soc/tegra: Changes for v7.4-rc1

Adds various bits of core Tegra SoC support for Tegra410, Tegra264 and
Tegra210-B01. Tegra234 can now be woken up via PCIe. Some references
leak and other fixes round this off.

----------------------------------------------------------------
Aaron Kling (2):
      soc/tegra: fuse: Support revision B01
      soc/tegra: fuse: speedo-tegra210: Support revision B01

Alexandre Hamamdjian (1):
      soc/tegra: pmc: Add Tegra210B01 support

Geert Uytterhoeven (1):
      soc/tegra: pmc: Make sure clk_init_data is fully initialized

Jon Hunter (1):
      soc/tegra: fuse: Add Tegra264 support

Kartik Rajput (1):
      soc/tegra: pmc: Add PMC support for Tegra410

Manikanta Maddireddy (1):
      soc/tegra: pmc: Add PCIe wake event for Tegra234

Thierry Reding (1):
      soc/tegra: cbb: Fix loggger -> logger typo

Yuho Choi (1):
      soc/tegra: flowctrl: Release OF node reference on error

 drivers/soc/tegra/cbb/tegra194-cbb.c     |   2 +-
 drivers/soc/tegra/flowctrl.c             |   7 +-
 drivers/soc/tegra/fuse/fuse-tegra.c      |  12 ++-
 drivers/soc/tegra/fuse/fuse-tegra30.c    | 168 ++++++++++++++++++++++++++++++-
 drivers/soc/tegra/fuse/fuse.h            |   7 +-
 drivers/soc/tegra/fuse/speedo-tegra210.c |  22 +++-
 drivers/soc/tegra/fuse/tegra-apbmisc.c   |  51 ++++++----
 drivers/soc/tegra/pmc.c                  | 165 +++++++++++++++++++++++++++++-
 include/soc/tegra/fuse.h                 |   1 +
 9 files changed, 405 insertions(+), 30 deletions(-)

[GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Thierry Reding]

From: Thierry Reding <thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit cee9395acd8043be0644b25c34bfa86623f2b935:

  Linux 7.3-rc1 (2026-08-30 13:34:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.4-firmware

for you to fetch changes up to 1bbcf4a19f1495f769b69e9569d8c1e81df074f5:

  firmware: tegra: Remove redundant dev_err() (2026-10-03 01:13:35 +0200)

Thanks,
Thierry

----------------------------------------------------------------
firmware/tegra: Changes for v7.4-rc1

The bulk of this adds ACPI support to BPMP as well as a mechanism to
throttle bandwidth for various high speed interconnects. Some smaller
cleanup and typofixes are also included.

----------------------------------------------------------------
Aniruddha Rao (6):
      firmware: tegra: bpmp: Move channel initialization to helper
      firmware: tegra: bpmp: Add ACPI support
      firmware: tegra: bpmp: Add the Memory Bandwidth Throttler ABI definitions
      firmware: tegra: bpmp: Add MBWT BPMP helpers
      firmware: tegra: bpmp: Add MBWT sysfs interface
      firmware: tegra: bpmp: Allow BPMP debugfs population to be skipped

Hemanth Selam (1):
      soc/tegra: Fix typos in comments

Pan Chuang (1):
      firmware: tegra: Remove redundant dev_err()

 .../ABI/testing/sysfs-platform-tegra-bpmp          |  48 +++
 drivers/firmware/tegra/Makefile                    |   1 +
 drivers/firmware/tegra/bpmp-debugfs.c              |   9 +
 drivers/firmware/tegra/bpmp-private.h              |  39 ++
 drivers/firmware/tegra/bpmp-sysfs.c                | 207 ++++++++++
 drivers/firmware/tegra/bpmp-tegra186.c             |  14 +
 drivers/firmware/tegra/bpmp-tegra210.c             |  17 +-
 drivers/firmware/tegra/bpmp.c                      | 434 ++++++++++++++++++---
 include/soc/tegra/bpmp-abi.h                       | 165 +++++++-
 include/soc/tegra/bpmp.h                           |   2 +
 10 files changed, 880 insertions(+), 56 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-tegra-bpmp
 create mode 100644 drivers/firmware/tegra/bpmp-sysfs.c

[GIT PULL 5/7] ARM: tegra: Changes for v7.4-rc1

[Thierry Reding]

From: Thierry Reding <thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit cee9395acd8043be0644b25c34bfa86623f2b935:

  Linux 7.3-rc1 (2026-08-30 13:34:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.4-arm-dt

for you to fetch changes up to c79aff01aeda4885cf707c17eede8d19617b78f1:

  ARM: tegra: lg-x3: Add backlight LED controller node (2026-10-02 00:50:38 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Changes for v7.4-rc1

The TF701T and LG X3 devices see a lot of updates and device trees are
added for the Motorola Atrix 4G and Droid X2. The core power supply is
added on Tegra114 devices to make power domains work properly. AHUB on
Tegra124 is cleaned up a bit.

----------------------------------------------------------------
Mikko Perttunen (1):
      ARM: tegra: Add core supply for Tegra114 boards

Svyatoslav Ryhel (19):
      dt-bindings: arm: tegra: Add Motorola Artix 4G and Droid X2
      ARM: tegra: tf701t: Configure CPU DFLL clock node
      ARM: tegra: tf701t: Add core-supply to PMC node
      ARM: tegra: tf701t: Add MC and EMC timing nodes
      ARM: tegra: tf701t: Remove pin_ prefix from PMIC pinmux
      ARM: tegra: tf701t: Add thermal zones for nct1008 sensor
      ARM: tegra: tf701t: Tune MMC devices
      ARM: tegra: tf701t: Fix BCM43341 WiFi/BT chip configuration
      ARM: tegra: tf701t: Complete power sensor node
      ARM: tegra: tf701t: Configure UART-B line used for GPS
      ARM: tegra: tf701t: Add chosen node
      ARM: tegra: Add device-tree for Motorola Atrix 4G and Droid X2
      ARM: tegra: lg-x3: Adjust WiFi node
      ARM: tegra: lg-x3: Remove pinctrl-* properties duplication
      ARM: tegra: lg-x3: Lower supported suspend mode
      ARM: tegra: lg-x3: Add light sensor node
      ARM: tegra: lg-x3: Add flash LEDs controller node
      ARM: tegra: lg-x3: Add haptic engine node
      ARM: tegra: lg-x3: Add backlight LED controller node

Thierry Reding (4):
      dt-bindings: memory: tegra: Fix Tegra132 compatible string
      dt-bindings: fuse: Document compatible string for Tegra264 FUSE
      Merge branch 'for-7.4/dt-bindings' into for-7.4/dt-bindings
      ARM: tegra: Clean up AHUB on Tegra124

 Documentation/devicetree/bindings/arm/tegra.yaml   |    6 +
 .../bindings/fuse/nvidia,tegra20-fuse.yaml         |    1 +
 .../memory-controllers/nvidia,tegra124-emc.yaml    |   10 +-
 .../memory-controllers/nvidia,tegra124-mc.yaml     |    1 +
 arch/arm/boot/dts/nvidia/Makefile                  |    2 +
 arch/arm/boot/dts/nvidia/tegra114-asus-tf701t.dts  |  885 ++++++++++++++-
 arch/arm/boot/dts/nvidia/tegra114-dalmore.dts      |    4 +-
 arch/arm/boot/dts/nvidia/tegra114-roth.dts         |    4 +-
 arch/arm/boot/dts/nvidia/tegra114-tn7.dts          |    4 +-
 arch/arm/boot/dts/nvidia/tegra124.dtsi             |   16 +-
 .../boot/dts/nvidia/tegra20-motorola-daytona.dts   |  107 ++
 arch/arm/boot/dts/nvidia/tegra20-motorola-mot.dtsi | 1194 ++++++++++++++++++++
 .../boot/dts/nvidia/tegra20-motorola-olympus.dts   |  108 ++
 arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts       |    5 +-
 arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts       |    5 +-
 arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi        |  106 +-
 16 files changed, 2399 insertions(+), 59 deletions(-)
 create mode 100644 arch/arm/boot/dts/nvidia/tegra20-motorola-daytona.dts
 create mode 100644 arch/arm/boot/dts/nvidia/tegra20-motorola-mot.dtsi
 create mode 100644 arch/arm/boot/dts/nvidia/tegra20-motorola-olympus.dts

[GIT PULL 6/7] arm64: tegra: Changes for v7.4-rc1

[Thierry Reding]

From: Thierry Reding <thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit cee9395acd8043be0644b25c34bfa86623f2b935:

  Linux 7.3-rc1 (2026-08-30 13:34:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.4-arm64-dt

for you to fetch changes up to ad4deb2e42ebb94425c003ca3ca39691ebe61e0f:

  arm64: tegra: Add Tegra264 SDMMC1 device tree node (2026-10-03 00:56:24 +0200)

Thanks,
Thierry

----------------------------------------------------------------
arm64: tegra: Changes for v7.4-rc1

This set of changes contain a lot of cleanups to existing device trees,
most of which fix issues with the device tree validation.

There are also various improvements to Jetson AGX Thor and the DevKit as
well as IGX Orin, making all these Tegra264-based devices more capable.

----------------------------------------------------------------
Aaron Kling (1):
      arm64: tegra: Enable DMA Support on Tegra194 QSPI

Diogo Ivo (1):
      arm64: tegra: Move Tegra210 AHUB audio ports/endpoints to SoC DTSI

Jon Hunter (1):
      arm64: tegra: Add the USB Type-C controller for IGX Orin

Krzysztof Kozlowski (1):
      arm64: tegra: Replace spaces indentation with tabs

Manikanta Maddireddy (2):
      arm64: tegra: Use iommus for PCIe endpoint controllers
      arm64: tegra: Add PCIe wake GPIO for Jetson Orin NX/Nano

Prathamesh Shete (1):
      arm64: tegra: Add Tegra264 SDMMC1 device tree node

Thierry Reding (26):
      arm64: tegra: Add PWM controllers on Tegra264
      arm64: tegra: Add PWM fan on Jetson AGX Thor DevKit
      arm64: tegra: Reorder reg and reg-names to match bindings
      arm64: tegra: Add PCIe root ports on Tegra264
      arm64: tegra: Clean up AHUB on Tegra132
      arm64: tegra: Adjust AHUB range on Tegra210
      arm64: tegra: Clean up AHUB on Tegra186
      arm64: tegra: Clean up AHUB on Tegra194
      arm64: tegra: Clean up AHUB on Tegra234
      arm64: tegra: Clean up AHUB on Tegra264
      arm64: tegra: Clean up some whitespace issues on Tegra264
      arm64: tegra: Fix up cooling map names on Tegra194
      arm64: tegra: Fix up cooling map names on Tegra186
      arm64: tegra: Fix up cooling map names on Tegra210
      arm64: tegra: Use consistent key code for force-recovery button
      arm64: tegra: Enable GPIO keys on Jetson AGX Thor
      arm64: tegra: Add thermal zones for Tegra264
      arm64: tegra: Add cooling device on Jetson AGX Thor DevKit
      arm64: tegra: Enable built-in RTC on Jetson AGX Thor
      arm64: tegra: Add FUSE block on Tegra264
      arm64: tegra: Add missing *-cells properties for I2C controllers
      arm64: tegra: Add I2C aliases for Tegra264
      arm64: tegra: Add NVIDIA Jetson AGX Thor module EEPROM
      arm64: tegra: Add NVIDIA Jetson AGX Thor system EEPROM
      arm64: tegra: Add thermal sensor for Jetson AGX Thor
      arm64: tegra: Add Tegra132 specific compatible for AHUB

 arch/arm64/boot/dts/nvidia/tegra132.dtsi           |   22 +-
 .../dts/nvidia/tegra186-p3509-0000+p3636-0001.dts  |    8 +-
 arch/arm64/boot/dts/nvidia/tegra186.dtsi           |   76 +-
 arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts |    8 +-
 .../arm64/boot/dts/nvidia/tegra194-p3509-0000.dtsi |    8 +-
 arch/arm64/boot/dts/nvidia/tegra194.dtsi           |  113 +-
 arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 1120 -------------------
 arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 1011 +-----------------
 arch/arm64/boot/dts/nvidia/tegra210.dtsi           | 1126 +++++++++++++++++++-
 .../boot/dts/nvidia/tegra234-p3737-0000+p3701.dtsi |    9 +-
 .../dts/nvidia/tegra234-p3740-0002+p3701-0008.dts  |   45 +-
 .../boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi |   12 +-
 arch/arm64/boot/dts/nvidia/tegra234.dtsi           |   86 +-
 arch/arm64/boot/dts/nvidia/tegra264-p3834.dtsi     |   57 +
 .../boot/dts/nvidia/tegra264-p4071-0000+p3834.dtsi |  106 ++
 arch/arm64/boot/dts/nvidia/tegra264.dtsi           |  794 +++++++++-----
 .../boot/dts/nvidia/thermal/nvidia,tegra264-bpmp.h |   20 +
 17 files changed, 2030 insertions(+), 2591 deletions(-)
 create mode 100644 arch/arm64/boot/dts/nvidia/thermal/nvidia,tegra264-bpmp.h

[GIT PULL 7/7] arm64: tegra: Default configuration changes for v7.4-rc1

[Thierry Reding]

From: Thierry Reding <thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit cee9395acd8043be0644b25c34bfa86623f2b935:

  Linux 7.3-rc1 (2026-08-30 13:34:40 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.4-arm64-defconfig

for you to fetch changes up to d33a04d2712104a84357c6f485605a0a5528c5e3:

  arm64: defconfig: Enable I3C and SPD5118 hwmon (2026-10-03 00:49:35 +0200)

Thanks,
Thierry

----------------------------------------------------------------
arm64: tegra: Default configuration changes for v7.4-rc1

This is a single change that enables the I3C subsystem and the
DesignWare I3C master controller, along with the SPD5118 temperature
sensor, all of which are used on NVIDIA Vera devices.

----------------------------------------------------------------
Akhil R (1):
      arm64: defconfig: Enable I3C and SPD5118 hwmon

 arch/arm64/configs/defconfig | 3 +++
 1 file changed, 3 insertions(+)

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Arnd Bergmann]

On Sat, Oct 3, 2026, at 11:59, Thierry Reding wrote:
> ----------------------------------------------------------------
> firmware/tegra: Changes for v7.4-rc1
>
> The bulk of this adds ACPI support to BPMP as well as a mechanism to
> throttle bandwidth for various high speed interconnects. Some smaller
> cleanup and typofixes are also included.
>
> ----------------------------------------------------------------
> Aniruddha Rao (6):
>       firmware: tegra: bpmp: Move channel initialization to helper
>       firmware: tegra: bpmp: Add ACPI support

[adding ACPI maintainers to Cc]

I'd like some clarification about the process here, as I see that the
ACPI support patch ee98ea41ee3f ("firmware: tegra: bpmp: Add ACPI support")
only has a signoff from both of you and no other review tag.

Where is the ACPI binding documentation for this driver, and who is
responsible for reviewing it?

      Arnd

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Thierry Reding]

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

On Tue, Oct 13, 2026 at 07:22:23PM +0200, Arnd Bergmann wrote:
> On Sat, Oct 3, 2026, at 11:59, Thierry Reding wrote:
> > ----------------------------------------------------------------
> > firmware/tegra: Changes for v7.4-rc1
> >
> > The bulk of this adds ACPI support to BPMP as well as a mechanism to
> > throttle bandwidth for various high speed interconnects. Some smaller
> > cleanup and typofixes are also included.
> >
> > ----------------------------------------------------------------
> > Aniruddha Rao (6):
> >       firmware: tegra: bpmp: Move channel initialization to helper
> >       firmware: tegra: bpmp: Add ACPI support
> 
> [adding ACPI maintainers to Cc]
> 
> I'd like some clarification about the process here, as I see that the
> ACPI support patch ee98ea41ee3f ("firmware: tegra: bpmp: Add ACPI support")
> only has a signoff from both of you and no other review tag.
> 
> Where is the ACPI binding documentation for this driver, and who is
> responsible for reviewing it?

Hi Arnd, Rafael, Len,

Sorry for the late reply, this fell through the cracks.

Admittedly there's not much of a formal process here at all. Anything
I've received up to now seemed to be fairly straightforward support
extensions like this where the ACPI tables basically provide the same
information as the DT via standard resources like register ranges.

I suppose for anything beyond this, we'll want better documentation and
broader review.

Is there anything in particular that you're looking for? Should I guide
people internally to always Cc linux-acpi for anything that concerns
ACPI?

I'm not very familiar with ACPI, so I'm probably not the best reviewer,
but I'm sure I'll get the hang of it over time. Generally I think the
same principles that we use elsewhere apply: use ACPI standards where we
can (standard interfaces, resources, etc.) and if device-specific
configuration is needed, use _DSD key-value pairs to mirror what we've
done for DT (and also mirror back any new properties needed by ACPI to
DT schemas). For anything that isn't (and can't be) documented as part
of DT schemas and still custom descriptions are needed, we probably
should have some documentation in Documentation/firmware-guide/acpi.

One problem that I see with ACPI, and which we successfully side-stepped
with DT, is that we usually get "baked-in" ACPI tables, meaning we don't
have much of a choice but to accept whatever is provided. In a way that
is a step back for Linux, so hopefully we can get better practices in
place and avoid this turning into a big mess down the road.

Thierry

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

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Arnd Bergmann]

On Wed, Nov 4, 2026, at 13:42, Thierry Reding wrote:
> On Tue, Oct 13, 2026 at 07:22:23PM +0200, Arnd Bergmann wrote:
>> On Sat, Oct 3, 2026, at 11:59, Thierry Reding wrote:
>> 
>> Where is the ACPI binding documentation for this driver, and who is
>> responsible for reviewing it?
>
> Hi Arnd, Rafael, Len,
>
> Sorry for the late reply, this fell through the cracks.
>
> Admittedly there's not much of a formal process here at all. Anything
> I've received up to now seemed to be fairly straightforward support
> extensions like this where the ACPI tables basically provide the same
> information as the DT via standard resources like register ranges.
>
> I suppose for anything beyond this, we'll want better documentation and
> broader review.
>
> Is there anything in particular that you're looking for? Should I guide
> people internally to always Cc linux-acpi for anything that concerns
> ACPI?

I don't know, I'm also still learning about how this is done, I
was hoping that there was already an established way.

Having a review done by the ACPI maintainers would definitely
help from my point of view, but I'm not sure whether they are
set up for that, in case there are a lot of new drivers.

I assume there is a knowledge gap in both subsystem maintainers
regarding ACPI (certainly this is the case for me for drivers/bus,
drivers/firmware, drivers/soc, etc) and ACPI maintainers regarding
many of the subsystems that we support with DT.

> I'm not very familiar with ACPI, so I'm probably not the best reviewer,
> but I'm sure I'll get the hang of it over time. Generally I think the
> same principles that we use elsewhere apply: use ACPI standards where we
> can (standard interfaces, resources, etc.) and if device-specific
> configuration is needed, use _DSD key-value pairs to mirror what we've
> done for DT (and also mirror back any new properties needed by ACPI to
> DT schemas). For anything that isn't (and can't be) documented as part
> of DT schemas and still custom descriptions are needed, we probably
> should have some documentation in Documentation/firmware-guide/acpi.
>
> One problem that I see with ACPI, and which we successfully side-stepped
> with DT, is that we usually get "baked-in" ACPI tables, meaning we don't
> have much of a choice but to accept whatever is provided. In a way that
> is a step back for Linux, so hopefully we can get better practices in
> place and avoid this turning into a big mess down the road.

Hopefully there is a process in place to amend bindings in a backward
compatible way. I would always expect issues to come up during driver
review that lead to firmware binding changes. Since in this case
both the firmware and the driver are provided by NVIDIA, I don't
think we should treat the firmware as an opaque blob that can't
be changed as we might for other machines.

       Arnd

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Thierry Reding]

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

On Wed, Nov 04, 2026 at 03:11:09PM +0100, Arnd Bergmann wrote:
> On Wed, Nov 4, 2026, at 13:42, Thierry Reding wrote:
> > On Tue, Oct 13, 2026 at 07:22:23PM +0200, Arnd Bergmann wrote:
> >> On Sat, Oct 3, 2026, at 11:59, Thierry Reding wrote:
> >> 
> >> Where is the ACPI binding documentation for this driver, and who is
> >> responsible for reviewing it?
> >
> > Hi Arnd, Rafael, Len,
> >
> > Sorry for the late reply, this fell through the cracks.
> >
> > Admittedly there's not much of a formal process here at all. Anything
> > I've received up to now seemed to be fairly straightforward support
> > extensions like this where the ACPI tables basically provide the same
> > information as the DT via standard resources like register ranges.
> >
> > I suppose for anything beyond this, we'll want better documentation and
> > broader review.
> >
> > Is there anything in particular that you're looking for? Should I guide
> > people internally to always Cc linux-acpi for anything that concerns
> > ACPI?
> 
> I don't know, I'm also still learning about how this is done, I
> was hoping that there was already an established way.

Yeah, me too. Maybe Rafael and Len can provide some guidance here. I
don't know how ACPI on more traditional platforms works, but I imagine
that it's a lot of the same anyway, except perhaps that people have more
experience with the spec and today might be doing a good job already.

> Having a review done by the ACPI maintainers would definitely
> help from my point of view, but I'm not sure whether they are
> set up for that, in case there are a lot of new drivers.

I think platform maintainers need to be a first line of defense here
since they sit at the intersection of a lot of this. At least that's the
case for me. Also, I'm eager to learn how to do this right, but I'm
often at a loss of where to start. The spec is a bit daunting, and then
there's various extensions, too. Maybe the AI genies can help me ramp
up.

> I assume there is a knowledge gap in both subsystem maintainers
> regarding ACPI (certainly this is the case for me for drivers/bus,
> drivers/firmware, drivers/soc, etc) and ACPI maintainers regarding
> many of the subsystems that we support with DT.

Agreed. I've seen some patches where the ACPI support was as simple as
just adding an ID table entry and the rest was all standard, but I think
once we move beyond standard resources things might get a bit more
complicated. I imagine that ACPI may not even have specs for certain
aspects that we currently handle in DT...

> > I'm not very familiar with ACPI, so I'm probably not the best reviewer,
> > but I'm sure I'll get the hang of it over time. Generally I think the
> > same principles that we use elsewhere apply: use ACPI standards where we
> > can (standard interfaces, resources, etc.) and if device-specific
> > configuration is needed, use _DSD key-value pairs to mirror what we've
> > done for DT (and also mirror back any new properties needed by ACPI to
> > DT schemas). For anything that isn't (and can't be) documented as part
> > of DT schemas and still custom descriptions are needed, we probably
> > should have some documentation in Documentation/firmware-guide/acpi.
> >
> > One problem that I see with ACPI, and which we successfully side-stepped
> > with DT, is that we usually get "baked-in" ACPI tables, meaning we don't
> > have much of a choice but to accept whatever is provided. In a way that
> > is a step back for Linux, so hopefully we can get better practices in
> > place and avoid this turning into a big mess down the road.
> 
> Hopefully there is a process in place to amend bindings in a backward
> compatible way. I would always expect issues to come up during driver
> review that lead to firmware binding changes. Since in this case
> both the firmware and the driver are provided by NVIDIA, I don't
> think we should treat the firmware as an opaque blob that can't
> be changed as we might for other machines.

If we follow best practices that we've learned during the DT transition,
backwards-compatibility shouldn't be all that much of an issue, I think.
But maybe I'm a bit optimistic...

From my perspective, these kinds of processes need to be injected as
early into the chip development cycle as possible, which comes with its
own set of challenges (secrecy, timelines, ...). Even if you submit
patches for upstream relatively quickly, which we often do these days,
it's usually at a point where hardware is relatively fix already and it
becomes increasingly harder to update ACPI tables after that point.

I'll see if we can adjust some of our internal processes to get this
sort of feedback into the loop earlier on.

Thierry

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

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Rafael J. Wysocki (Intel)]

Thierry, Arnd,

On Wed, Nov 4, 2026 at 3:41 PM Thierry Reding <thierry.reding@kernel.org> wrote:
>
> On Wed, Nov 04, 2026 at 03:11:09PM +0100, Arnd Bergmann wrote:
> > On Wed, Nov 4, 2026, at 13:42, Thierry Reding wrote:
> > > On Tue, Oct 13, 2026 at 07:22:23PM +0200, Arnd Bergmann wrote:
> > >> On Sat, Oct 3, 2026, at 11:59, Thierry Reding wrote:
> > >>
> > >> Where is the ACPI binding documentation for this driver, and who is
> > >> responsible for reviewing it?
> > >
> > > Hi Arnd, Rafael, Len,
> > >
> > > Sorry for the late reply, this fell through the cracks.
> > >
> > > Admittedly there's not much of a formal process here at all. Anything
> > > I've received up to now seemed to be fairly straightforward support
> > > extensions like this where the ACPI tables basically provide the same
> > > information as the DT via standard resources like register ranges.
> > >
> > > I suppose for anything beyond this, we'll want better documentation and
> > > broader review.
> > >
> > > Is there anything in particular that you're looking for? Should I guide
> > > people internally to always Cc linux-acpi for anything that concerns
> > > ACPI?
> >
> > I don't know, I'm also still learning about how this is done, I
> > was hoping that there was already an established way.
>
> Yeah, me too. Maybe Rafael and Len can provide some guidance here.

I cannot speak for Len, and he has not been actively involved in the
maintenance of ACPI support in the kernel for several years.

As far as I'm concerned, the code maintained by me is mostly located
in drivers/acpi/ (as per the relevant MAINTAINERS entries) and it is
mostly generic code related to ACPI support.  I generally don't
maintain device drivers using ACPI support except for the ones under
drivers/acpi/ which mostly bind to devices representing interfaces
defined in the ACPI specification (which is kind of a special case).

But there is more.  There is ACPI support code in other places (like
for instance gpiolib-acpi maintained by Andy and Mika, or platform-x86
drivers maintained by Ilpo) and there are experienced kernel
developers in the ARM ecosystem with quite a bit of ACPI-related
knowledge (Hans, Jonathan, Sudeep, Lorenzo - all CCed) who can be
reached out to for guidance (and arguably they have more experience
with ARM platforms than I do).

> I don't know how ACPI on more traditional platforms works, but I imagine
> that it's a lot of the same anyway, except perhaps that people have more
> experience with the spec and today might be doing a good job already.

If you have any specific questions, I think I should be able to answer
at least some of them, but I'm afraid I cannot give you general
guidance on how to do ACPI support in device drivers that would be
universally useful.  Different drivers have different needs.

There are things in ACPI that are not present in DT and vice versa.
It also depends on what bus types we're talking about (platform vs PCI
vs USB etc).

> > Having a review done by the ACPI maintainers would definitely

So as per the above, who exactly do you mean by "ACPI maintainers"?
If you mean "the people maintaining the code in drivers/acpi/", that's
just me and quite frankly, I'm not sure if my review, specifically,
would be super-useful for driver development (the fact that my review
bandwidth is almost completely saturated nowadays aside).

My recommendation would be to ask other people within the ARM
ecosystem who have more experience with ACPI for help.

> > help from my point of view, but I'm not sure whether they are
> > set up for that, in case there are a lot of new drivers.

I am not and had I been trying to do it, it wouldn't have scaled anyway.

> I think platform maintainers need to be a first line of defense here
> since they sit at the intersection of a lot of this. At least that's the
> case for me. Also, I'm eager to learn how to do this right, but I'm
> often at a loss of where to start. The spec is a bit daunting, and then
> there's various extensions, too. Maybe the AI genies can help me ramp
> up.

My advice would be to reach out to people within your ecosystem in the
first place.

> > I assume there is a knowledge gap in both subsystem maintainers
> > regarding ACPI (certainly this is the case for me for drivers/bus,
> > drivers/firmware, drivers/soc, etc) and ACPI maintainers regarding
> > many of the subsystems that we support with DT.
>
> Agreed. I've seen some patches where the ACPI support was as simple as
> just adding an ID table entry and the rest was all standard, but I think
> once we move beyond standard resources things might get a bit more
> complicated. I imagine that ACPI may not even have specs for certain
> aspects that we currently handle in DT...

That certainly is true, but the ACPI specification is under active
development and pieces that are missing can be added to it.  There is
a process for that in place and ARM people take part in it.

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Andy Shevchenko]

On Wed, Nov 04, 2026 at 05:28:18PM +0100, Rafael J. Wysocki (Intel) wrote:
> On Wed, Nov 4, 2026 at 3:41 PM Thierry Reding <thierry.reding@kernel.org> wrote:
> > On Wed, Nov 04, 2026 at 03:11:09PM +0100, Arnd Bergmann wrote:
> > > On Wed, Nov 4, 2026, at 13:42, Thierry Reding wrote:
> > > > On Tue, Oct 13, 2026 at 07:22:23PM +0200, Arnd Bergmann wrote:
> > > >> On Sat, Oct 3, 2026, at 11:59, Thierry Reding wrote:
> > > >>
> > > >> Where is the ACPI binding documentation for this driver, and who is
> > > >> responsible for reviewing it?
> > > >
> > > > Sorry for the late reply, this fell through the cracks.
> > > >
> > > > Admittedly there's not much of a formal process here at all. Anything
> > > > I've received up to now seemed to be fairly straightforward support
> > > > extensions like this where the ACPI tables basically provide the same
> > > > information as the DT via standard resources like register ranges.
> > > >
> > > > I suppose for anything beyond this, we'll want better documentation and
> > > > broader review.
> > > >
> > > > Is there anything in particular that you're looking for? Should I guide
> > > > people internally to always Cc linux-acpi for anything that concerns
> > > > ACPI?
> > >
> > > I don't know, I'm also still learning about how this is done, I
> > > was hoping that there was already an established way.
> >
> > Yeah, me too. Maybe Rafael and Len can provide some guidance here.
> 
> I cannot speak for Len, and he has not been actively involved in the
> maintenance of ACPI support in the kernel for several years.
> 
> As far as I'm concerned, the code maintained by me is mostly located
> in drivers/acpi/ (as per the relevant MAINTAINERS entries) and it is
> mostly generic code related to ACPI support.  I generally don't
> maintain device drivers using ACPI support except for the ones under
> drivers/acpi/ which mostly bind to devices representing interfaces
> defined in the ACPI specification (which is kind of a special case).
> 
> But there is more.  There is ACPI support code in other places (like
> for instance gpiolib-acpi maintained by Andy and Mika, or platform-x86
> drivers maintained by Ilpo) and there are experienced kernel
> developers in the ARM ecosystem with quite a bit of ACPI-related
> knowledge (Hans, Jonathan, Sudeep, Lorenzo - all CCed) who can be
> reached out to for guidance (and arguably they have more experience
> with ARM platforms than I do).
> 
> > I don't know how ACPI on more traditional platforms works, but I imagine
> > that it's a lot of the same anyway, except perhaps that people have more
> > experience with the spec and today might be doing a good job already.
> 
> If you have any specific questions, I think I should be able to answer
> at least some of them, but I'm afraid I cannot give you general
> guidance on how to do ACPI support in device drivers that would be
> universally useful.  Different drivers have different needs.
> 
> There are things in ACPI that are not present in DT and vice versa.
> It also depends on what bus types we're talking about (platform vs PCI
> vs USB etc).

And don't forget the big player(s) such as Microsoft that from time to time
creates an "extension" to the ACPI (in means of additional tables or how some
of the existing data should be interpreted if it's not clear from the ACPI
specification). For instance, above mentioned USB ACPI support for some cases
heavily relies on the MS "extensions". Or earlycon support for ACPI is based
on MS defined SPCR table. And so on...

> > > Having a review done by the ACPI maintainers would definitely
> 
> So as per the above, who exactly do you mean by "ACPI maintainers"?
> If you mean "the people maintaining the code in drivers/acpi/", that's
> just me and quite frankly, I'm not sure if my review, specifically,
> would be super-useful for driver development (the fact that my review
> bandwidth is almost completely saturated nowadays aside).
> 
> My recommendation would be to ask other people within the ARM
> ecosystem who have more experience with ACPI for help.
> 
> > > help from my point of view, but I'm not sure whether they are
> > > set up for that, in case there are a lot of new drivers.
> 
> I am not and had I been trying to do it, it wouldn't have scaled anyway.
> 
> > I think platform maintainers need to be a first line of defense here
> > since they sit at the intersection of a lot of this. At least that's the
> > case for me. Also, I'm eager to learn how to do this right, but I'm
> > often at a loss of where to start. The spec is a bit daunting, and then
> > there's various extensions, too. Maybe the AI genies can help me ramp
> > up.
> 
> My advice would be to reach out to people within your ecosystem in the
> first place.
> 
> > > I assume there is a knowledge gap in both subsystem maintainers
> > > regarding ACPI (certainly this is the case for me for drivers/bus,
> > > drivers/firmware, drivers/soc, etc) and ACPI maintainers regarding
> > > many of the subsystems that we support with DT.
> >
> > Agreed. I've seen some patches where the ACPI support was as simple as
> > just adding an ID table entry and the rest was all standard, but I think
> > once we move beyond standard resources things might get a bit more
> > complicated. I imagine that ACPI may not even have specs for certain
> > aspects that we currently handle in DT...
> 
> That certainly is true, but the ACPI specification is under active
> development and pieces that are missing can be added to it.  There is
> a process for that in place and ARM people take part in it.


On top of the above in Linux we also developed some "extensions", for instance
how I²C muxes are described, or how some multi-functional devices are being
enumerated. These specifics we usually document under
Documentation/firmware-guide/acpi/ (see i2c-muxes.rst for the mentioned case).

-- 
With Best Regards,
Andy Shevchenko

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Jonathan Cameron]

On Wed, 4 Nov 2026 19:08:01 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Wed, Nov 04, 2026 at 05:28:18PM +0100, Rafael J. Wysocki (Intel) wrote:
> > On Wed, Nov 4, 2026 at 3:41 PM Thierry Reding <thierry.reding@kernel.org> wrote:  
> > > On Wed, Nov 04, 2026 at 03:11:09PM +0100, Arnd Bergmann wrote:  
> > > > On Wed, Nov 4, 2026, at 13:42, Thierry Reding wrote:  
> > > > > On Tue, Oct 13, 2026 at 07:22:23PM +0200, Arnd Bergmann wrote:  
> > > > >> On Sat, Oct 3, 2026, at 11:59, Thierry Reding wrote:
> > > > >>
> > > > >> Where is the ACPI binding documentation for this driver, and who is
> > > > >> responsible for reviewing it?  
> > > > >
> > > > > Sorry for the late reply, this fell through the cracks.
> > > > >
> > > > > Admittedly there's not much of a formal process here at all. Anything
> > > > > I've received up to now seemed to be fairly straightforward support
> > > > > extensions like this where the ACPI tables basically provide the same
> > > > > information as the DT via standard resources like register ranges.
> > > > >
> > > > > I suppose for anything beyond this, we'll want better documentation and
> > > > > broader review.
> > > > >
> > > > > Is there anything in particular that you're looking for? Should I guide
> > > > > people internally to always Cc linux-acpi for anything that concerns
> > > > > ACPI?  
> > > >
> > > > I don't know, I'm also still learning about how this is done, I
> > > > was hoping that there was already an established way.  
> > >
> > > Yeah, me too. Maybe Rafael and Len can provide some guidance here.  
> > 
> > I cannot speak for Len, and he has not been actively involved in the
> > maintenance of ACPI support in the kernel for several years.
> > 
> > As far as I'm concerned, the code maintained by me is mostly located
> > in drivers/acpi/ (as per the relevant MAINTAINERS entries) and it is
> > mostly generic code related to ACPI support.  I generally don't
> > maintain device drivers using ACPI support except for the ones under
> > drivers/acpi/ which mostly bind to devices representing interfaces
> > defined in the ACPI specification (which is kind of a special case).
> > 
> > But there is more.  There is ACPI support code in other places (like
> > for instance gpiolib-acpi maintained by Andy and Mika, or platform-x86
> > drivers maintained by Ilpo) and there are experienced kernel
> > developers in the ARM ecosystem with quite a bit of ACPI-related
> > knowledge (Hans, Jonathan, Sudeep, Lorenzo - all CCed) who can be
> > reached out to for guidance (and arguably they have more experience
> > with ARM platforms than I do).
> >   
> > > I don't know how ACPI on more traditional platforms works, but I imagine
> > > that it's a lot of the same anyway, except perhaps that people have more
> > > experience with the spec and today might be doing a good job already.  
> > 
> > If you have any specific questions, I think I should be able to answer
> > at least some of them, but I'm afraid I cannot give you general
> > guidance on how to do ACPI support in device drivers that would be
> > universally useful.  Different drivers have different needs.
> > 
> > There are things in ACPI that are not present in DT and vice versa.
> > It also depends on what bus types we're talking about (platform vs PCI
> > vs USB etc).  
> 
> And don't forget the big player(s) such as Microsoft that from time to time
> creates an "extension" to the ACPI (in means of additional tables or how some
> of the existing data should be interpreted if it's not clear from the ACPI
> specification). For instance, above mentioned USB ACPI support for some cases
> heavily relies on the MS "extensions". Or earlycon support for ACPI is based
> on MS defined SPCR table. And so on...
> 
> > > > Having a review done by the ACPI maintainers would definitely  
> > 
> > So as per the above, who exactly do you mean by "ACPI maintainers"?
> > If you mean "the people maintaining the code in drivers/acpi/", that's
> > just me and quite frankly, I'm not sure if my review, specifically,
> > would be super-useful for driver development (the fact that my review
> > bandwidth is almost completely saturated nowadays aside).
> > 
> > My recommendation would be to ask other people within the ARM
> > ecosystem who have more experience with ACPI for help.
> >   
> > > > help from my point of view, but I'm not sure whether they are
> > > > set up for that, in case there are a lot of new drivers.  
> > 
> > I am not and had I been trying to do it, it wouldn't have scaled anyway.
> >   
> > > I think platform maintainers need to be a first line of defense here
> > > since they sit at the intersection of a lot of this. At least that's the
> > > case for me. Also, I'm eager to learn how to do this right, but I'm
> > > often at a loss of where to start. The spec is a bit daunting, and then
> > > there's various extensions, too. Maybe the AI genies can help me ramp
> > > up.  
> > 
> > My advice would be to reach out to people within your ecosystem in the
> > first place.

It is a bit of a guessing game to figure out who are the right people today
when it comes to ACPI and both ARM and x86 platforms. 

They fall into a few categories and it depends on what you are trying to
do.  Starting point is push back hard on your firmware folk wrt to shipping
something random without an upstream discussion first.  You wouldn't expect
that to work for dt, it shouldn't work for ACPI either. Features
will get rejected if people try to just do something that works for them
(same as a weird custom DT binding gets rejected).

1) Basic stand alone driver stuff.  Mostly that's all pretty standard
   and follow the specs where possible.  If there are gaps start asking
   questions. Linux definitely  doesn't support all the stuff that has been
   added to the spec in recent years.  So this covers things like register
   addresses, interrupts etc.  All fine, hopefully a subsystem maintainer
   can take a look and will have enough of any idea.  If not ping the folk
   on this thread for help.  Things are a bit flexible for consumer type
   devices where fixed and bodges are common, generally less so if it is
   server grade hardware.

2) Stuff that is an ACPI spec gap or place where we'd expect generalization.
   There are several examples of this on list this week and a few more in
   my inbox.  The particular series here might fall into this category.
   I've not figured out enough of the details yet to say definitively.

I'd also expect a driver using AML as the target interface to either
point at a published spec doc, or to include some snippets
of the AML - that can be a lot easier to read than the driver code
(imagine reading DT by only looking at how drivers parse it).

FWIW The driver feature in question looks like it is doing something a bit similar
to the PCI trace and tune driver Hisilicon has (though IIRC that has
a presence as a PCI driver) https://docs.kernel.org/trace/hisi-ptt.html
or if you squint at it differently resctrl / mpam fb.

Given that has new ABI etc, I'd expect that to have gotten broader review
as well.  Probably keeping it to linux-tegra and lkml alone wasn't
going to result in anyone noticing!

https://lore.kernel.org/all/?q=20260929095915.2215685-1-anrao@nvidia.com

Anyhow, feel free to reach out if you want some feedback on this or
similar. I can perhaps at least point you to someone who knows a
specific area better than me.

Jonathan
 
> >   
> > > > I assume there is a knowledge gap in both subsystem maintainers
> > > > regarding ACPI (certainly this is the case for me for drivers/bus,
> > > > drivers/firmware, drivers/soc, etc) and ACPI maintainers regarding
> > > > many of the subsystems that we support with DT.  
> > >
> > > Agreed. I've seen some patches where the ACPI support was as simple as
> > > just adding an ID table entry and the rest was all standard, but I think
> > > once we move beyond standard resources things might get a bit more
> > > complicated. I imagine that ACPI may not even have specs for certain
> > > aspects that we currently handle in DT...  
> > 
> > That certainly is true, but the ACPI specification is under active
> > development and pieces that are missing can be added to it.  There is
> > a process for that in place and ARM people take part in it.  
> 
> 
> On top of the above in Linux we also developed some "extensions", for instance
> how I²C muxes are described, or how some multi-functional devices are being
> enumerated. These specifics we usually document under
> Documentation/firmware-guide/acpi/ (see i2c-muxes.rst for the mentioned case).
> 

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Sudeep Holla]

Hi all,

On Wed, Nov 04, 2026 at 04:11:25PM -0800, Jonathan Cameron wrote:
> 
> It is a bit of a guessing game to figure out who are the right people today
> when it comes to ACPI and both ARM and x86 platforms. 
> 
> They fall into a few categories and it depends on what you are trying to
> do.  Starting point is push back hard on your firmware folk wrt to shipping
> something random without an upstream discussion first.  You wouldn't expect
> that to work for dt, it shouldn't work for ACPI either. Features
> will get rejected if people try to just do something that works for them
> (same as a weird custom DT binding gets rejected).
> 
> 1) Basic stand alone driver stuff.  Mostly that's all pretty standard
>    and follow the specs where possible.  If there are gaps start asking
>    questions. Linux definitely  doesn't support all the stuff that has been
>    added to the spec in recent years.  So this covers things like register
>    addresses, interrupts etc.  All fine, hopefully a subsystem maintainer
>    can take a look and will have enough of any idea.  If not ping the folk
>    on this thread for help.  Things are a bit flexible for consumer type
>    devices where fixed and bodges are common, generally less so if it is
>    server grade hardware.
> 
> 2) Stuff that is an ACPI spec gap or place where we'd expect generalization.
>    There are several examples of this on list this week and a few more in
>    my inbox.  The particular series here might fall into this category.
>    I've not figured out enough of the details yet to say definitively.
> 

Nicely summarised or categorised Jonathan. Nothing much to add.

For most of the IP/devices/firmware associated with Arm, we are involved
in any specification work if there are any. However that doesn't include
3rd party IPs/devices used on Arm based platforms though.

> I'd also expect a driver using AML as the target interface to either
> point at a published spec doc, or to include some snippets
> of the AML - that can be a lot easier to read than the driver code
> (imagine reading DT by only looking at how drivers parse it).
> 

Ideally, it should be just HID that any vendor needs to publish unless
they make use of any custom methods or something device specific like
DSD/DSM. I would expect most of the devices to use standard methods and
properties that are already well defined in the ACPI spec.

> FWIW The driver feature in question looks like it is doing something a bit similar
> to the PCI trace and tune driver Hisilicon has (though IIRC that has
> a presence as a PCI driver) https://docs.kernel.org/trace/hisi-ptt.html
> or if you squint at it differently resctrl / mpam fb.
> 
> Given that has new ABI etc, I'd expect that to have gotten broader review
> as well.  Probably keeping it to linux-tegra and lkml alone wasn't
> going to result in anyone noticing!
> 
> https://lore.kernel.org/all/?q=20260929095915.2215685-1-anrao@nvidia.com
> 

Agreed, it shouldn't hurt to cc linux-acpi for such driver ACPI enablement
patches.

-- 
Regards,
Sudeep

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Arnd Bergmann]

On Thu, Nov 5, 2026, at 10:30, Sudeep Holla wrote:
> On Wed, Nov 04, 2026 at 04:11:25PM -0800, Jonathan Cameron wrote:

>> 1) Basic stand alone driver stuff.  Mostly that's all pretty standard
>>    and follow the specs where possible.  If there are gaps start asking
>>    questions. Linux definitely  doesn't support all the stuff that has been
>>    added to the spec in recent years.  So this covers things like register
>>    addresses, interrupts etc.  All fine, hopefully a subsystem maintainer
>>    can take a look and will have enough of any idea.  If not ping the folk
>>    on this thread for help.  Things are a bit flexible for consumer type
>>    devices where fixed and bodges are common, generally less so if it is
>>    server grade hardware.
>> 
>> 2) Stuff that is an ACPI spec gap or place where we'd expect generalization.
>>    There are several examples of this on list this week and a few more in
>>    my inbox.  The particular series here might fall into this category.
>>    I've not figured out enough of the details yet to say definitively.
>> 
>
> Nicely summarised or categorised Jonathan. Nothing much to add.

+1

>> I'd also expect a driver using AML as the target interface to either
>> point at a published spec doc, or to include some snippets
>> of the AML - that can be a lot easier to read than the driver code
>> (imagine reading DT by only looking at how drivers parse it).
>> 
>
> Ideally, it should be just HID that any vendor needs to publish unless
> they make use of any custom methods or something device specific like
> DSD/DSM. I would expect most of the devices to use standard methods and
> properties that are already well defined in the ACPI spec.

>> Given that has new ABI etc, I'd expect that to have gotten broader review
>> as well.  Probably keeping it to linux-tegra and lkml alone wasn't
>> going to result in anyone noticing!
>> 
>> https://lore.kernel.org/all/?q=20260929095915.2215685-1-anrao@nvidia.com
>> 
>
> Agreed, it shouldn't hurt to cc linux-acpi for such driver ACPI enablement
> patches.

Is the "BMRQ" in
https://lore.kernel.org/all/20260929095915.2215685-3-anrao@nvidia.com/
a custom method then? 

How does this relate to the EC and PCC interfaces in ACPI systems?

In current mainline, I see that the bpmp driver is used on DT systems
by the tegra specific cpufreq, memory and pci drivers, but I would
expect that on ACPI those all use shared drivers. Are there any other
users that are not already covered on ACPI?

     Arnd

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Sudeep Holla]

On Thu, Nov 05, 2026 at 10:54:42AM +0100, Arnd Bergmann wrote:
> On Thu, Nov 5, 2026, at 10:30, Sudeep Holla wrote:
> > On Wed, Nov 04, 2026 at 04:11:25PM -0800, Jonathan Cameron wrote:
> 
> >> 1) Basic stand alone driver stuff.  Mostly that's all pretty standard
> >>    and follow the specs where possible.  If there are gaps start asking
> >>    questions. Linux definitely  doesn't support all the stuff that has been
> >>    added to the spec in recent years.  So this covers things like register
> >>    addresses, interrupts etc.  All fine, hopefully a subsystem maintainer
> >>    can take a look and will have enough of any idea.  If not ping the folk
> >>    on this thread for help.  Things are a bit flexible for consumer type
> >>    devices where fixed and bodges are common, generally less so if it is
> >>    server grade hardware.
> >> 
> >> 2) Stuff that is an ACPI spec gap or place where we'd expect generalization.
> >>    There are several examples of this on list this week and a few more in
> >>    my inbox.  The particular series here might fall into this category.
> >>    I've not figured out enough of the details yet to say definitively.
> >> 
> >
> > Nicely summarised or categorised Jonathan. Nothing much to add.
> 
> +1
> 
> >> I'd also expect a driver using AML as the target interface to either
> >> point at a published spec doc, or to include some snippets
> >> of the AML - that can be a lot easier to read than the driver code
> >> (imagine reading DT by only looking at how drivers parse it).
> >> 
> >
> > Ideally, it should be just HID that any vendor needs to publish unless
> > they make use of any custom methods or something device specific like
> > DSD/DSM. I would expect most of the devices to use standard methods and
> > properties that are already well defined in the ACPI spec.
> 
> >> Given that has new ABI etc, I'd expect that to have gotten broader review
> >> as well.  Probably keeping it to linux-tegra and lkml alone wasn't
> >> going to result in anyone noticing!
> >> 
> >> https://lore.kernel.org/all/?q=20260929095915.2215685-1-anrao@nvidia.com
> >> 
> >
> > Agreed, it shouldn't hurt to cc linux-acpi for such driver ACPI enablement
> > patches.
> 
> Is the "BMRQ" in
> https://lore.kernel.org/all/20260929095915.2215685-3-anrao@nvidia.com/
> a custom method then? 
> 

I’ve quickly reviewed the patch; it does implements a custom method BMRQ
rather than a standard or out-of-the-box solution. More details on this is
used based on my understanding below.

> How does this relate to the EC and PCC interfaces in ACPI systems?
> 

I am still evaluating how the BPMP driver is intended to operate on ACPI
systems. In the meantime, I share the same questions noted above. The current
commit message lists several driver features that may not be required for
ACPI, which has introduced some clarity issues regarding the intended design.

> In current mainline, I see that the bpmp driver is used on DT systems
> by the tegra specific cpufreq, memory and pci drivers, but I would
> expect that on ACPI those all use shared drivers. Are there any other
> users that are not already covered on ACPI?
> 

For ACPI systems, CPUFreq operates through CPPC via PCC, MEMIO, or
supported backends.

My understanding is that the BMRQ method is called by tegra_bpmp_transfer(),
which supports Tegra-specific drivers for power domains, clocks, resets,
I2C, PCIe, and memory. On ACPI, these can be abstracted through PCC
OpRegions as part of standard methods like _ON/_OFF or other device state
methods. Although device/memory DVFS is trickier since the ACPI
specification lacks standard methods for it today, the commit message
implies these components are largely unused on ACPI systems.

I have raised a query on the thread to clarify this.

-- 
Regards,
Sudeep

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Thierry Reding]

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

On Thu, Nov 05, 2026 at 10:23:24AM +0000, Sudeep Holla wrote:
> On Thu, Nov 05, 2026 at 10:54:42AM +0100, Arnd Bergmann wrote:
> > On Thu, Nov 5, 2026, at 10:30, Sudeep Holla wrote:
> > > On Wed, Nov 04, 2026 at 04:11:25PM -0800, Jonathan Cameron wrote:
> > 
> > >> 1) Basic stand alone driver stuff.  Mostly that's all pretty standard
> > >>    and follow the specs where possible.  If there are gaps start asking
> > >>    questions. Linux definitely  doesn't support all the stuff that has been
> > >>    added to the spec in recent years.  So this covers things like register
> > >>    addresses, interrupts etc.  All fine, hopefully a subsystem maintainer
> > >>    can take a look and will have enough of any idea.  If not ping the folk
> > >>    on this thread for help.  Things are a bit flexible for consumer type
> > >>    devices where fixed and bodges are common, generally less so if it is
> > >>    server grade hardware.
> > >> 
> > >> 2) Stuff that is an ACPI spec gap or place where we'd expect generalization.
> > >>    There are several examples of this on list this week and a few more in
> > >>    my inbox.  The particular series here might fall into this category.
> > >>    I've not figured out enough of the details yet to say definitively.
> > >> 
> > >
> > > Nicely summarised or categorised Jonathan. Nothing much to add.
> > 
> > +1
> > 
> > >> I'd also expect a driver using AML as the target interface to either
> > >> point at a published spec doc, or to include some snippets
> > >> of the AML - that can be a lot easier to read than the driver code
> > >> (imagine reading DT by only looking at how drivers parse it).
> > >> 
> > >
> > > Ideally, it should be just HID that any vendor needs to publish unless
> > > they make use of any custom methods or something device specific like
> > > DSD/DSM. I would expect most of the devices to use standard methods and
> > > properties that are already well defined in the ACPI spec.
> > 
> > >> Given that has new ABI etc, I'd expect that to have gotten broader review
> > >> as well.  Probably keeping it to linux-tegra and lkml alone wasn't
> > >> going to result in anyone noticing!
> > >> 
> > >> https://lore.kernel.org/all/?q=20260929095915.2215685-1-anrao@nvidia.com
> > >> 
> > >
> > > Agreed, it shouldn't hurt to cc linux-acpi for such driver ACPI enablement
> > > patches.
> > 
> > Is the "BMRQ" in
> > https://lore.kernel.org/all/20260929095915.2215685-3-anrao@nvidia.com/
> > a custom method then? 
> > 
> 
> I’ve quickly reviewed the patch; it does implements a custom method BMRQ
> rather than a standard or out-of-the-box solution. More details on this is
> used based on my understanding below.

To get everyone on the same page: in a nutshell, BPMP is a separate
processor that handles various aspects of power management (Boot and
Power Management Processor). The CPU communicates with it over a shared
memory region and a mailbox/doorbell for signalling.

> > How does this relate to the EC and PCC interfaces in ACPI systems?
> > 
> 
> I am still evaluating how the BPMP driver is intended to operate on ACPI
> systems. In the meantime, I share the same questions noted above. The current
> commit message lists several driver features that may not be required for
> ACPI, which has introduced some clarity issues regarding the intended design.

My understanding is that an ACPI systems, as opposed to DT where we do
this all through kernel drivers, the inter-processor communication is
done via AML. This is because standard power management operations use
this same mechanism to enable clocks, deassert resets, etc.

> > In current mainline, I see that the bpmp driver is used on DT systems
> > by the tegra specific cpufreq, memory and pci drivers, but I would
> > expect that on ACPI those all use shared drivers. Are there any other
> > users that are not already covered on ACPI?
> > 
> 
> For ACPI systems, CPUFreq operates through CPPC via PCC, MEMIO, or
> supported backends.
> 
> My understanding is that the BMRQ method is called by tegra_bpmp_transfer(),
> which supports Tegra-specific drivers for power domains, clocks, resets,
> I2C, PCIe, and memory. On ACPI, these can be abstracted through PCC
> OpRegions as part of standard methods like _ON/_OFF or other device state
> methods. Although device/memory DVFS is trickier since the ACPI
> specification lacks standard methods for it today, the commit message
> implies these components are largely unused on ACPI systems.

I think this goes back to the disconnect from the patch thread and
earlier in this discussion: the intent was very much to encapsulate all
the power management within standard ACPI methods, and that's working
fine, hence why clocks, resets and power domains are not getting exposed
on ACPI systems.

However, there's no equivalent in ACPI to expose these MBWT knobs, hence
the need to expose this through BPMP directly.

Thierry

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

Re: [GIT PULL 4/7] firmware/tegra: Changes for v7.4-rc1

[Sudeep Holla]

On Thu, Nov 05, 2026 at 02:31:31PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2026 at 10:23:24AM +0000, Sudeep Holla wrote:
> > On Thu, Nov 05, 2026 at 10:54:42AM +0100, Arnd Bergmann wrote:
> > > On Thu, Nov 5, 2026, at 10:30, Sudeep Holla wrote:

[...]

> > 
> > I’ve quickly reviewed the patch; it does implements a custom method BMRQ
> > rather than a standard or out-of-the-box solution. More details on this is
> > used based on my understanding below.
> 
> To get everyone on the same page: in a nutshell, BPMP is a separate
> processor that handles various aspects of power management (Boot and
> Power Management Processor). The CPU communicates with it over a shared
> memory region and a mailbox/doorbell for signalling.
> 

I interpret this as PCC is used where needed and that aligns well with
my understanding.

> > > How does this relate to the EC and PCC interfaces in ACPI systems?
> > > 
> > 
> > I am still evaluating how the BPMP driver is intended to operate on ACPI
> > systems. In the meantime, I share the same questions noted above. The current
> > commit message lists several driver features that may not be required for
> > ACPI, which has introduced some clarity issues regarding the intended design.
> 
> My understanding is that an ACPI systems, as opposed to DT where we do
> this all through kernel drivers, the inter-processor communication is
> done via AML. This is because standard power management operations use
> this same mechanism to enable clocks, deassert resets, etc.
> 

Thanks for confirming this. I think we are almost aligned with respect to
the expectations from any ACPI system firmware.

> > > In current mainline, I see that the bpmp driver is used on DT systems
> > > by the tegra specific cpufreq, memory and pci drivers, but I would
> > > expect that on ACPI those all use shared drivers. Are there any other
> > > users that are not already covered on ACPI?
> > > 
> > 
> > For ACPI systems, CPUFreq operates through CPPC via PCC, MEMIO, or
> > supported backends.
> > 
> > My understanding is that the BMRQ method is called by tegra_bpmp_transfer(),
> > which supports Tegra-specific drivers for power domains, clocks, resets,
> > I2C, PCIe, and memory. On ACPI, these can be abstracted through PCC
> > OpRegions as part of standard methods like _ON/_OFF or other device state
> > methods. Although device/memory DVFS is trickier since the ACPI
> > specification lacks standard methods for it today, the commit message
> > implies these components are largely unused on ACPI systems.
> 
> I think this goes back to the disconnect from the patch thread and
> earlier in this discussion: the intent was very much to encapsulate all
> the power management within standard ACPI methods, and that's working
> fine, hence why clocks, resets and power domains are not getting exposed
> on ACPI systems.
> 

Agreed and I think we are aligned.

> However, there's no equivalent in ACPI to expose these MBWT knobs, hence
> the need to expose this through BPMP directly.
> 

IIUC this is Memory Bandwidth Throttling and shouldn't that align with
Arm MPAM and resctrl framework in the kernel ? We now have MPAM via PCC,
so if the firmware exposes the right interface, you must be able to reuse
that. Even otherwise, shouldn't to make this fit with resctrl ? What am I
missing ?

-- 
Regards,
Sudeep