Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp10125327rwp; Thu, 20 Jul 2023 15:14:03 -0700 (PDT) X-Google-Smtp-Source: APBJJlHQJpKOij3Qd6pKx5So3JuStJOpmHc1hT4bzwyKFC0CSOQCT8fEgu5hTb4Im8qtl5DzMEfE X-Received: by 2002:a17:902:e742:b0:1b6:7f96:42ca with SMTP id p2-20020a170902e74200b001b67f9642camr201682plf.66.1689891242935; Thu, 20 Jul 2023 15:14:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689891242; cv=none; d=google.com; s=arc-20160816; b=K7Cit/V+DTe0INpt1LY+I5LDb0V/ahUArlwZrfgJiQ/w/CXqmcbBuNcRogILtcC6Ch K6I8cLNLHRneSKh3vn7IuF3dYYfaXE5wVSPYf1oVaxquF0u255rY1qNGMK6Yl6i3WkGt GnuozwELYfEyXK+tnMq4YNRDKno3cpT7R+qPfjhjD0mc7UGrPkV/uF0iurFC9AwFUUIy snz5+vuLJ6f8b2q4nINofYM6ENYcJg82jh405rYDLgD1AHCoaL8QU8zOlwjrZXlVL0ed Va6UFHK6jBPE6timA+7Q/W/0Z4lfQ9caYJKR0o/bfrQ63JGplvdhGcIDR7Y/xi791uef DG1g== 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=m2x1wt5qi3oDapsSK9uxAmfkXgIoNkXDNbxajkUKd0s=; fh=TERk1ml3PZIXkkxSHdjaoxEYyL+DunkuUCrnjtMelDs=; b=0ioYcIUzVNoGeUM2+onxV5C7iLKvalnUZjyfzzYSfSOi2smDzlM0nq8jq5YsQKB5et etJHS/z4hVypRYeUm6EYnvUrX/MJzMQFulNRG/z3qZh2LzLUQRY3Na6vXFFr0YwrNGio zoa685ZaRxsXNbTBoCU5CJmo9VTOOCJtg1E9S5TMENPenlNNYru/sIkfFTkYd9mvNBk6 zAdr1qRo0CZP2d5hUtXclYalCaEFM2jHl2w2nU7lUPMXCo51pUJYUkKq1ODP8hgq5rTn pFCQk/71241+r3P4k1Ikf8YG7OiRNJ+NmX6uvRQgrFAi9EPqyU2pj6HiRUuQeDKzbzfL PFQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PckrirTH; 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 b15-20020a170902d50f00b001b8a840e783si1815026plg.442.2023.07.20.15.13.50; Thu, 20 Jul 2023 15:14:02 -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=PckrirTH; 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 S229752AbjGTVz4 (ORCPT + 99 others); Thu, 20 Jul 2023 17:55:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229610AbjGTVzz (ORCPT ); Thu, 20 Jul 2023 17:55:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5186D1719; Thu, 20 Jul 2023 14:55: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 DA93361C37; Thu, 20 Jul 2023 21:55:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB259C433C8; Thu, 20 Jul 2023 21:55:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689890153; bh=/bXS787t6CrBfx1QzszVq51xokDzGgEBIJZxAQSEBpc=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=PckrirTH+R/atkbCgfex4heLW9KXK7s+ISrPtn4IqPCDQOKZUWg1Hku404dLZZsBi NuuAgsruXLXuYa229tXINUGekioW5P7Daw5vmq90cy11jXiwkYB9r4Q+5N+La7zPDk 5WqD3lk4QWHGuFSFJug0czFpUN8scQsR9tJ+IWE8KHhCRC0TUgdK5LmS3cYU52B7qH 9e5rmBwkikmKUYtCWFxPRDrRYB+UqPcIPK0NqFdydH+LDgmkJl14xxSE3FtpsbiCvI 9KcFD7+bTSrCTKeTdQWB2g7KwQ6lw6itidOZ0E6XQVL48L8lzxOjEWHZyfxe0A+k0L Xv+29EkPDh4uA== Date: Thu, 20 Jul 2023 16:55:50 -0500 From: Bjorn Helgaas To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Emmanuel Grumbach , "Rafael J . Wysocki" , Heiner Kallweit , Lukas Wunner , Andy Shevchenko , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , "Pan, Xinhui" , David Airlie , Daniel Vetter , Jammy Zhou , Ken Wang , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Dean Luick , Jonas =?iso-8859-1?Q?Dre=DFler?= , stable@vger.kernel.org Subject: Re: [PATCH v5 05/11] drm/amdgpu: Use RMW accessors for changing LNKCTL Message-ID: <20230720215550.GA554900@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230717120503.15276-6-ilpo.jarvinen@linux.intel.com> 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 03:04:57PM +0300, Ilpo J?rvinen wrote: > Don't assume that only the driver would be accessing LNKCTL. ASPM > policy changes can trigger write to LNKCTL outside of driver's control. > And in the case of upstream bridge, the driver does not even own the > device it's changing the registers for. > > Use RMW capability accessors which do proper locking to avoid losing > concurrent updates to the register value. > > Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts") > Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") > Suggested-by: Lukas Wunner > Signed-off-by: Ilpo J?rvinen > Cc: stable@vger.kernel.org Do we have any reports of problems that are fixed by this patch (or by others in the series)? If not, I'm not sure it really fits the usual stable kernel criteria: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-kernel-rules.rst?id=v6.4 > --- > drivers/gpu/drm/amd/amdgpu/cik.c | 36 +++++++++----------------------- > drivers/gpu/drm/amd/amdgpu/si.c | 36 +++++++++----------------------- > 2 files changed, 20 insertions(+), 52 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c > index 5641cf05d856..e63abdf52b6c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/cik.c > +++ b/drivers/gpu/drm/amd/amdgpu/cik.c > @@ -1574,17 +1574,8 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev) > u16 bridge_cfg2, gpu_cfg2; > u32 max_lw, current_lw, tmp; > > - pcie_capability_read_word(root, PCI_EXP_LNKCTL, > - &bridge_cfg); > - pcie_capability_read_word(adev->pdev, PCI_EXP_LNKCTL, > - &gpu_cfg); > - > - tmp16 = bridge_cfg | PCI_EXP_LNKCTL_HAWD; > - pcie_capability_write_word(root, PCI_EXP_LNKCTL, tmp16); > - > - tmp16 = gpu_cfg | PCI_EXP_LNKCTL_HAWD; > - pcie_capability_write_word(adev->pdev, PCI_EXP_LNKCTL, > - tmp16); > + pcie_capability_set_word(root, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_HAWD); > + pcie_capability_set_word(adev->pdev, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_HAWD); > > tmp = RREG32_PCIE(ixPCIE_LC_STATUS1); > max_lw = (tmp & PCIE_LC_STATUS1__LC_DETECTED_LINK_WIDTH_MASK) >> > @@ -1637,21 +1628,14 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev) > msleep(100); > > /* linkctl */ > - pcie_capability_read_word(root, PCI_EXP_LNKCTL, > - &tmp16); > - tmp16 &= ~PCI_EXP_LNKCTL_HAWD; > - tmp16 |= (bridge_cfg & PCI_EXP_LNKCTL_HAWD); > - pcie_capability_write_word(root, PCI_EXP_LNKCTL, > - tmp16); > - > - pcie_capability_read_word(adev->pdev, > - PCI_EXP_LNKCTL, > - &tmp16); > - tmp16 &= ~PCI_EXP_LNKCTL_HAWD; > - tmp16 |= (gpu_cfg & PCI_EXP_LNKCTL_HAWD); > - pcie_capability_write_word(adev->pdev, > - PCI_EXP_LNKCTL, > - tmp16); > + pcie_capability_clear_and_set_word(root, PCI_EXP_LNKCTL, > + PCI_EXP_LNKCTL_HAWD, > + bridge_cfg & > + PCI_EXP_LNKCTL_HAWD); > + pcie_capability_clear_and_set_word(adev->pdev, PCI_EXP_LNKCTL, > + PCI_EXP_LNKCTL_HAWD, > + gpu_cfg & > + PCI_EXP_LNKCTL_HAWD); Wow, there's a lot of pointless-looking work going on here: set root PCI_EXP_LNKCTL_HAWD set GPU PCI_EXP_LNKCTL_HAWD for (i = 0; i < 10; i++) { read root PCI_EXP_LNKCTL read GPU PCI_EXP_LNKCTL clear root PCI_EXP_LNKCTL_HAWD if (root PCI_EXP_LNKCTL_HAWD was set) set root PCI_EXP_LNKCTL_HAWD clear GPU PCI_EXP_LNKCTL_HAWD if (GPU PCI_EXP_LNKCTL_HAWD was set) set GPU PCI_EXP_LNKCTL_HAWD } If it really *is* pointless, it would be nice to clean it up, but that wouldn't be material for this patch, so what you have looks good. > /* linkctl2 */ > pcie_capability_read_word(root, PCI_EXP_LNKCTL2, The PCI_EXP_LNKCTL2 stuff also includes RMW updates. I don't see any uses of PCI_EXP_LNKCTL2 outside this driver that look relevant, so I guess we don't care about making the PCI_EXP_LNKCTL2 updates atomic? Bjorn