[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