[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