From patchwork Sun Jun 11 17:19:08 2023
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: "Maciej W. Rozycki" <macro@orcam.me.uk>
X-Patchwork-Id: 13275291
Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net
 [23.128.96.19])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87B16C2C2
	for <netdev@vger.kernel.org>; Sun, 11 Jun 2023 17:19:11 +0000 (UTC)
Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34])
	by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1EE00E5F;
	Sun, 11 Jun 2023 10:19:10 -0700 (PDT)
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id 1966992009E; Sun, 11 Jun 2023 19:19:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id 134EB92009D;
	Sun, 11 Jun 2023 18:19:09 +0100 (BST)
Date: Sun, 11 Jun 2023 18:19:08 +0100 (BST)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Bjorn Helgaas <bhelgaas@google.com>,
    Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
    Oliver O'Halloran <oohall@gmail.com>,
    Michael Ellerman <mpe@ellerman.id.au>,
 Nicholas Piggin <npiggin@gmail.com>,
    Christophe Leroy <christophe.leroy@csgroup.eu>,
    Saeed Mahameed <saeedm@nvidia.com>, Leon Romanovsky <leon@kernel.org>,
    "David S. Miller" <davem@davemloft.net>,
    Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>,
    Paolo Abeni <pabeni@redhat.com>
cc: Alex Williamson <alex.williamson@redhat.com>,
  Lukas Wunner <lukas@wunner.de>,
  Mika Westerberg <mika.westerberg@linux.intel.com>,
  Stefan Roese <sr@denx.de>, Jim Wilson <wilson@tuliptree.org>,
  David Abdurachmanov <david.abdurachmanov@gmail.com>, =?utf-8?q?Pali_Roh?=
	=?utf-8?q?=C3=A1r?= <pali@kernel.org>, linux-pci@vger.kernel.org,
  linuxppc-dev@lists.ozlabs.org, linux-rdma@vger.kernel.org,
  netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v9 00/14] pci: Work around ASMedia ASM2824 PCIe link training
 failures
Message-ID: <alpine.DEB.2.21.2305310024400.59226@angie.orcam.me.uk>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,HDRS_LCASE,
	SPF_HELO_NONE,SPF_NONE,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

Hi,

 This is v9 of the change to work around a PCIe link training phenomenon 
where a pair of devices both capable of operating at a link speed above 
2.5GT/s seems unable to negotiate the link speed and continues training 
indefinitely with the Link Training bit switching on and off repeatedly 
and the data link layer never reaching the active state.

 With several requests addressed and a few extra issues spotted this
version has now grown to 14 patches.  It has been verified for device 
enumeration with and without PCI_QUIRKS enabled, using the same piece of 
RISC-V hardware as previously.  Hot plug or reset events have not been 
verified, as this is difficult if at all feasible with hardware in 
question.

 Last iteration: 
<https://lore.kernel.org/r/alpine.DEB.2.21.2304060100160.13659@angie.orcam.me.uk/>, 
and my input to it:
<https://lore.kernel.org/r/alpine.DEB.2.21.2306080224280.36323@angie.orcam.me.uk/>.

  Maciej