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

[Thierry Reding <thierry.reding@kernel.org>]

[-- 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 --]