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

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