Re: [PATCH v2 0/4] platform/surface: Add platform profile driver for Surface devices

["Rafael J. Wysocki" <rafael@kernel.org>]

On Mon, Feb 15, 2021 at 5:36 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 2/15/21 4:29 PM, Rafael J. Wysocki wrote:
> > On Mon, Feb 15, 2021 at 4:22 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> On 2/15/21 3:54 PM, Rafael J. Wysocki wrote:
> >>> On Mon, Feb 15, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 2/11/21 9:16 PM, Maximilian Luz wrote:
> >>>>> This series adds a driver to provide platform profile support on 5th-
> >>>>> and later generation Microsoft Surface devices with a Surface System
> >>>>> Aggregator Module. On those devices, the platform profile can be used to
> >>>>> influence cooling behavior and power consumption.
> >>>>>
> >>>>> To achieve this, a new platform profile is introduced: the
> >>>>> 'balanced-performance' profile.
> >>>>>
> >>>>> In addition, a couple of fix-ups are performed:
> >>>>> - Hide CONFIG_ACPI_PLATFORM_PROFILE and change drivers so that it is
> >>>>>   selected instead of depended on.
> >>>>> - Fix some references to documentation in a comment.
> >>>>>
> >>>>> Note: This series (or more specifically "platform/surface: Add platform
> >>>>> profile driver") depends on the "platform/surface: Add Surface
> >>>>> Aggregator device registry" series.
> >>>>>
> >>>>> Changes in v2:
> >>>>>  - Introduce new 'balanced-performance' platform profile and change
> >>>>>    profile mapping in driver.
> >>>>>  - Perform some fix-ups for the ACPI platform profile implementation:
> >>>>>    - Fix some references to documentation in a comment.
> >>>>>    - Hide CONFIG_ACPI_PLATFORM_PROFILE
> >>>>
> >>>> Thanks, the entire series looks good to me, so for the series:
> >>>>
> >>>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> >>>>
> >>>> Rafael, can you (once 5.12-rc1 is out) pick 1-3/4 and then provide a
> >>>> stable branch for me to merge?
> >>>
> >>> Since [1-3/4] appear to be uncontroversial, so IMO it would be better
> >>> to merge them during the merge window, so they are present in
> >>> 5.12-rc1.
> >>
> >> So I just realized one problem with this plan, patch 1/4 depends
> >> on (modifies) Kconfig bits which are only in my tree / my 5.12 pull-req
> >> (which I send out earlier today).
> >
> > That should be fine.
> >
> > I will be sending the first batch of pull requests tomorrow.  Then I
> > will wait for them to be merged and I will merge the mainline back at
> > that point.  The new patches will be applied on top of that merge, so
> > if your 5.12 material is included in it, they should build without
> > problems.
>
> Ok, that sounds good to me.

In fact, my pull requests are ready right now, so I will be sending
them shortly, but that doesn\t change the subsequent steps.