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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 E8C44C432C0 for ; Wed, 20 Nov 2019 12:06:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B660A22311 for ; Wed, 20 Nov 2019 12:06:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574251599; bh=JcM4V7QiTMGd/hQNkQtYNyLH0bkfKtNQ0eTkMJQT6qU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=Im2+sBR+pCgsOxq88bQPOG0mxJV15fhE0kK04zLzaEE3t79vTwWum5rnhpKagvRHo 58CaET9+erDKdSMv+cKPS3U7q2Nd75PGmYpvrCbqTeNTBoGWGfswyi4H6QWb4W6y3V UaAYqILX2Nw0hlX5wtP6RhOAJ5/1mw2UDrnrJfPM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728911AbfKTMGj (ORCPT ); Wed, 20 Nov 2019 07:06:39 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:34344 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726689AbfKTMGj (ORCPT ); Wed, 20 Nov 2019 07:06:39 -0500 Received: by mail-oi1-f196.google.com with SMTP id l202so22292064oig.1; Wed, 20 Nov 2019 04:06:38 -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=ElT7EJNqtwpJJU4QjMYGJbxkB5AWzSyGEgl7I/cinCY=; b=hr58LFCDCSzTnyNwpoB7s6lVEQK1tD0HPWHIS2n6GAB5ej72KyYoWxDVPuG6sNHjvs +i4tXFgQDVRylOpu3hf2FssZKNbIqbCsa+E3BEmzYRP7vTR0cSph3tIUaYZykugeOW7P t90QAVn3U8koe1EJuWLYgSdBZuN4mMCyj80HpBMtqiBu84H0j+QJ2IBZwEhnD8rQIrck HV9KWTgi7j6l0PYBDAA74o09F2kZquV3ek0kCoNwOj4Fqfsxc0Pvc0mZoWxsux38nqHW HC3GbzvFznH8A1mjyj8cu9E5jHkPsW4KnCfqyBuEE+DyDbe5pENwkX16vE9xfYgW75Ue HiuQ== X-Gm-Message-State: APjAAAVuz/wWxvyOS57hTEz4oFSryCNSqyIZ23j8fGWrhg4ZHQnRPkbS T4KZbAWVlIqDB/GGVyH3dtzEMreRSc4rHPhnuwE= X-Google-Smtp-Source: APXvYqxheneYqbQjWsEAfSkE2ZQbClubvVZBCaL5vjr7E9PZ5SxHyJLeCYrf4NpLC+8pv/qSSK7clExZOkJduiPveC8= X-Received: by 2002:aca:c753:: with SMTP id x80mr2352248oif.115.1574251597887; Wed, 20 Nov 2019 04:06:37 -0800 (PST) MIME-Version: 1.0 References: <20191017121901.13699-1-kherbst@redhat.com> <20191119214955.GA223696@google.com> <20191120101816.GX11621@lahna.fi.intel.com> <20191120112212.GA11621@lahna.fi.intel.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Wed, 20 Nov 2019 13:06:26 +0100 Message-ID: Subject: Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges To: Karol Herbst Cc: "Rafael J. Wysocki" , Mika Westerberg , Bjorn Helgaas , LKML , Lyude Paul , "Rafael J . Wysocki" , Linux PCI , Linux PM , dri-devel , nouveau , Dave Airlie , Mario Limonciello Content-Type: text/plain; charset="UTF-8" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg > > > > wrote: > > > > > [cut] > > > > > > > > Oh, so does it look like we are trying to work around AML that tried > > > > to work around some problematic behavior in Linux at one point? > > > > > > Yes, it looks like so if I read the ASL right. > > > > OK, so that would call for a DMI-based quirk as the real cause for the > > issue seems to be the AML in question, which means a firmware problem. > > > > And I disagree as this is a linux specific workaround and windows goes > that path and succeeds. This firmware based workaround was added, > because it broke on Linux. Apparently so at the time it was added, but would it still break after the kernel changes made since then? Moreover, has it not become harmful now? IOW, wouldn't it work after removing the "Linux workaround" from the AML? The only way to verify that I can see would be to run the system with custom ACPI tables without the "Linux workaround" in the AML in question.