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

Arnd Bergmann arnd at arndb.de
Thu Nov 5 01:54:42 PST 2026


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



More information about the linux-arm-kernel mailing list