Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp7261278rwp; Tue, 18 Jul 2023 12:28:40 -0700 (PDT) X-Google-Smtp-Source: APBJJlGLBfssejpfy1V4UgHUCjvsS20Sn/DDZ/P85D5+MEoROAG6r9vB29ctPb/rmoMsZHQ9b3KN X-Received: by 2002:a17:902:e80b:b0:1b8:17e8:5472 with SMTP id u11-20020a170902e80b00b001b817e85472mr763707plg.1.1689708520564; Tue, 18 Jul 2023 12:28:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689708520; cv=none; d=google.com; s=arc-20160816; b=OuGcCrZLZxe4ms3g85F0Y3cC5DvnVdbCIVwGLB3C5tD9Gdan4nmWetLC4q9asO91Qc cBZeZ93Wo8LNcYUgctCE3a3/62wEk+vNB/PqK15qwbcYycI8mwqNiOpzVIX5SHX3FX9N fqnpLgf7lfO/KddKa5WTeM9O5J2ZLEORpZEJCUZUElxKHDBa6V3MkjtzKzOUZeMqhgAg 8JIHj+j3PX/BbQqnWAqIhw8BAfxwZf9sPcGeBCnUddeOf9ca17wdCInencGTwIdeEC0+ ChqpC2UOqSMZT8X8CyN8IuIsM1ji19ZBt1hWiTwQ+eoz9+AFluSqqeNQAA2lGwZlvm7x ZxKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=8cRpTuuvHZpIuESJN+d0zyRlchCUCA6cwNpOH06S38w=; fh=aBvfzkgaAdW7q7G3PvBVSJeKa4S6BJozRMsOV6eF6rE=; b=fp2lUQeIVFRSrkCiOdPoQ2RcUU9aaZJELLWjJ/kHCCPfevmOGTD21UG9DqX2lGVlJt o3IkrE184iiBbVy91nt5dH++pTTwDkkp/f52ifbt7/GBI4SpkW37xMmx4NW5JDzwdyc2 lS2p6FCB+y52XPSDACx9cdU/3GUgombyMK9t/18WoIZ07t4Kiwxv4xsMQ7e5hhjuNDcb nbGF27Da5kW6u6CuBqC20n2pXe+bqS4LeGlKXIudzexWiLKOthNCEFilCiEsBHKHH0XN jUOuIoNG/OTNxT8EuRY0B3GgtSken8jwOXNTp3Hq3J6aTLRT5/tuHZd/wJbdZajnp9wy XQXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=n6TT8nZL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n9-20020a170902e54900b001bb12510890si1989888plf.642.2023.07.18.12.28.27; Tue, 18 Jul 2023 12:28:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=n6TT8nZL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229562AbjGRTY7 (ORCPT + 99 others); Tue, 18 Jul 2023 15:24:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjGRTY5 (ORCPT ); Tue, 18 Jul 2023 15:24:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1ADAF198D; Tue, 18 Jul 2023 12:24:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9FDB0616B9; Tue, 18 Jul 2023 19:24:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9E60C433C7; Tue, 18 Jul 2023 19:24:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689708293; bh=qdAhpK1XWeLAN71lc0Y9kyyM+NLhNWrfXG4CFOZK0OA=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=n6TT8nZLi9Pu6qYPkbR79iGdZf/xTelKI4ID1ZvYs+ryvcky461erRgFpveupe0bW vQlmqTc2yT6Wv5QvPjbNK6zf6FKtcfgdb1cnVzLFFqhaakQe/2YIlYuhSlmDktNMU5 D9jLWi+YFgLffoeWTZiOlduz+2+zJIz9TR6A8GLxl6CIqv1GdV9Wf0pwGhYDNMpckK 6ffhu3AN24Jo1+5iUtdo2a81G01f6QOx/E8hdQhHwIeBWoTOXNZFPheEvoeDedkEgT i8eLcdxr2B//lGlpmdc9D++BTG1+NbR7HM0530JhdzFOabGgVfNfZTIRiphDD1VOOR V/79lOQ+fkd2g== Date: Tue, 18 Jul 2023 14:24:50 -0500 From: Bjorn Helgaas To: "Limonciello, Mario" Cc: Kai-Heng Feng , Kuppuswamy Sathyanarayanan , linux-pci@vger.kernel.org, "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Vidya Sagar , Michael Bottini , intel-wired-lan@osuosl.org, bhelgaas@google.com, Mika Westerberg Subject: Re: [Intel-wired-lan] [PATCH] PCI/ASPM: Enable ASPM on external PCIe devices Message-ID: <20230718192450.GA489825@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 17, 2023 at 11:51:32AM -0500, Limonciello, Mario wrote: > On 7/16/2023 10:34 PM, Kai-Heng Feng wrote: > > On Sat, Jul 15, 2023 at 12:37 AM Mario Limonciello wrote: > > > On 7/14/23 03:17, Kai-Heng Feng wrote: > > > > The main point is OS should stick to the BIOS default, which is the > > > > only ASPM setting tested before putting hardware to the market. > > > > > > Unfortunately; I don't think you can jump to this conclusion. I think using the BIOS default as a limit is problematic. I think it would be perfectly reasonable for a BIOS to (a) configure only devices it needs for console and boot, leaving others at power-on defaults, and (b) configure devices in the safest configuration possible on the assumption that an OS can decide the runtime policy itself. Obviously I'm not a BIOS writer (though I sure wish I could talk to some!), so maybe these are bad assumptions. > > > A big difference in the Windows world to Linux world is that OEMs ship > > > with a factory Windows image that may set policies like this. OEM > > > "platform" drivers can set registry keys too. I suppose this means that the OEM image contains drivers that aren't in the Microsoft media, and those drivers may set constraints on ASPM usage? If you boot the Microsoft media that lacks those drivers, maybe it doesn't bother to configure ASPM for those devices? Linux currently configures ASPM for everything at enumeration-time, so we do it even if there's no driver. > > I wonder if there's any particular modification should be improved for > > this patch? > > Knowing this information I personally think the original patch that started > this thread makes a lot of sense. I'm still opposed to using dev_is_removable() as a predicate because I don't think it has any technical connection to ASPM configuration. Bjorn