[PATCH 1/3] ACPICA: Add support for FFH Opregion special context data

Rafael J. Wysocki rafael at kernel.org
Wed Jun 22 07:10:06 PDT 2022


On Wed, Jun 22, 2022 at 4:01 PM Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> On Wed, Jun 22, 2022 at 02:50:08PM +0200, Rafael J. Wysocki wrote:
> > On Thu, Jun 16, 2022 at 11:01 AM Sudeep Holla <sudeep.holla at arm.com> wrote:
> > >
> > > FFH(Fixed Function Hardware) Opregion is approved to be added in ACPIC 6.5 via
> >
> > s/ACPIC/ACPI/
> >
>
> Fixed and pushed in ACPICA PR.
>
> > > code first approach[1]. It requires special context data similar to GPIO and
> > > Generic Serial Bus as it needs to know platform specific offset and length.
> > >
> > > Add support for the special context data needed by FFH Opregion.
> > >
> > > FFH OpRegion enables advanced use of FFH on some architectures. For example,
> > > it could be used to easily proxy AML code to architecture-specific behavior
> > > (to ensure it is OS initiated)
> > >
> > > Actual behavior of FFH is ofcourse architecture specific and depends on
> > > the FFH bindings. The offset and length could have arch specific meaning
> > > or usage.
> > >
> > > [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3598
> > >
> > > Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> >
> > This looks reasonable to me and I see that you've already submitted a
> > pull request to the upstream ACPICA.
>
> I assume you would prefer me to post the other 2 patches once this lands
> in your -next.

That would be ideal, but technically I can apply an ACPICA patch in
advance once the corresponding pull request has been integrated
upstream.

> Worst case I would like to get the generic patch in along
> with ACPICA changes, I can then route the arm64 specific next cycle if it
> gets too late for v5.20

Let's try the normal flow and worry about workarounds if it gets late.



More information about the linux-arm-kernel mailing list