From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A38AC433E6 for ; Wed, 27 Jan 2021 13:52:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2DB35207B7 for ; Wed, 27 Jan 2021 13:52:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232048AbhA0Nv1 (ORCPT ); Wed, 27 Jan 2021 08:51:27 -0500 Received: from mail-oo1-f51.google.com ([209.85.161.51]:44686 "EHLO mail-oo1-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231202AbhA0Nuy (ORCPT ); Wed, 27 Jan 2021 08:50:54 -0500 Received: by mail-oo1-f51.google.com with SMTP id n19so523788ooj.11; Wed, 27 Jan 2021 05:50:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sEOztENIm4lBjLjdgYkobjrAaOBHM+q4Q4zzeEUvgD8=; b=aq/4JlS4YVTtHcOXunMiXxGpgvBR62SCyXooVi1HjDDsiQ+F3u1lIL/xVn8s4bt+Np P+ggR4eYY9ZhzkAyH+J8URXZ8qlFk7/pC7o0VfpTkak+UsmnISEpXcdt62BYkJull06Q P9Hf3Eg0I028qzF+SYcmra+Vp6+Vey/gy7vfy621ZJC0vu/pbfeC8+inY1OIKpmHY1cZ fUbtRG892Vx0eHCp5xgW+cMpDEDXCIeSVg8WoUuogsX2PYvUwbanumCfnngRNZ+W2R1t 44qIr0DueXndTH/e6yeT+opmrnteqBCmFL0nbhBxH7p2cAARwJsElR31vmnVShorBaRV Benw== X-Gm-Message-State: AOAM533J8JEk4DSRARj7RKNPBY8tXk8WZeaVlk422I/+Dlvpbo2jaEvY 6qms6F2dFWYDm41T+D+nxK9NB0kLoBklkbZFqIU= X-Google-Smtp-Source: ABdhPJwxqmW4ZQMrt3FU6CfrZ9R3+3IKqVrt5Bs+JZW0EQ83HLgm8FeJZgkpuy6FUXXdfXcTpDHyyM6WOFBKti6WxHw= X-Received: by 2002:a4a:cb87:: with SMTP id y7mr7786272ooq.1.1611755412554; Wed, 27 Jan 2021 05:50:12 -0800 (PST) MIME-Version: 1.0 References: <20210126155723.9388-1-mika.westerberg@linux.intel.com> <20210126155723.9388-5-mika.westerberg@linux.intel.com> <20210127124935.GC2542@lahna.fi.intel.com> In-Reply-To: <20210127124935.GC2542@lahna.fi.intel.com> From: "Rafael J. Wysocki" Date: Wed, 27 Jan 2021 14:50:00 +0100 Message-ID: Subject: Re: [PATCH 4/6] ACPI: Execute platform _OSC also with query bit clear To: Mika Westerberg Cc: "Limonciello, Mario" , "Rafael J. Wysocki" , "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" , Michael Jamet , Yehezkel Bernat , Andreas Noever , Lukas Wunner , "Rafael J. Wysocki" , Christian Kellner , Len Brown , Greg Kroah-Hartman , ACPI Devel Maling List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Wed, Jan 27, 2021 at 1:49 PM Mika Westerberg wrote: > > On Tue, Jan 26, 2021 at 10:43:32PM +0000, Limonciello, Mario wrote: > > > I would put that information into the changelog. > > > > Thanks, @Mika Westerberg can you collapse that in when you re-spin the > > series? > > Sure. > > > > > > > Moreover, have you looked at acpi_pci_osc_control_set()? > > > > > > What it does is analogous to what you are proposing, but a bit > > > different, and I would like to preserve consistency between _OSC use > > > cases. > > > > > > So would it be possible to adjust the _SB _OSC evaluation flow to > > > follow the PCI _OSC one? That is, if any control bits are there, pass > > > them along with the last evaluation of _OSC with the query flag clear. > > > Or is the latter defective and if so then why? > > > > Basically the only difference is another line cloning OSC_CONTROL_DWORD from > > capbuf_ret to capbuf? > > > > Yes, this actually sounds like it better adheres to the spec to me. > > > > Quoting spec: > > " If the OS is granted control of a feature in the Control Field in one call to > > _OSC, then it must preserve the set state of that bit (requesting that feature) > > in all subsequent calls." > > However, the platform wide _OSC does not actually have this > OSC_CONTROL_DWORD at all ;-) Right. > I think what we do in this patch is already equivalent to what the PCI > _OSC is doing: > > 1. Query bit set _OSC > 2. Take the returned OSC_SUPPORT_DWORD buffer and > 3. Pass it to the _OSC with query bit clear. Yes, it is. Given the way the USB4 _OSC protocol is defined (which admittedly confused me somewhat), the code changes in this patch are fine by me. Thanks and sorry for the confusion.