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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E88C3C77B7C for ; Mon, 1 May 2023 20:55:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229816AbjEAUze (ORCPT ); Mon, 1 May 2023 16:55:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229627AbjEAUzd (ORCPT ); Mon, 1 May 2023 16:55:33 -0400 Received: from bmailout2.hostsharing.net (bmailout2.hostsharing.net [83.223.78.240]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8EB112F for ; Mon, 1 May 2023 13:55:31 -0700 (PDT) Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 8996C2800B6ED; Mon, 1 May 2023 22:55:29 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 7857E4A8DC; Mon, 1 May 2023 22:55:29 +0200 (CEST) Date: Mon, 1 May 2023 22:55:29 +0200 From: Lukas Wunner To: Jim Quinlan Cc: Bjorn Helgaas , Jim Quinlan , linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Cyril Brulebois , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, Florian Fainelli , Lorenzo Pieralisi , Krzysztof Wilczy??ski , Rob Herring , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v4 3/5] PCI: brcmstb: Set PCIe transaction completion timeout Message-ID: <20230501205529.GA3626@wunner.de> References: <20230428223500.23337-4-jim2101024@gmail.com> <20230430191323.GA388047@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Sun, Apr 30, 2023 at 05:24:26PM -0400, Jim Quinlan wrote: > I've been maintaining this driver for over eight years or so and we've > done fine with the HW default completion timeout value. > Only recently has a major customer requested that this timeout value > be changed, and their reason was so they could > avoid a CPU abort when using L1SS. > > Now we could set this value to a big number for all cases and not > require "brcm,completion-timeout-us". I cannot see any > downsides, other than another customer coming along asking us to > double the default or lessen it. The Completion Timeout is configurable in the Device Control 2 Register (PCIe r2.1 sec 7.8.16). Your controller does expose that register: DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled, ARIFwd- AtomicOpsCtl: ReqEn- EgressBlck- Why does your controller allow configuration of the timeout in a proprietary register in addition to DevCtl2? If you make the Completion Timeout configurable, please do so in a spec-compliant way, i.e. via DevCtl2, so that it works for other products as well. If the proprietary register has advantages over DevCtl2 (e.g. finer granularity), perhaps you can divert accesses to the Completion Timeout Value in DevCtl2 to your proprietary register. Thanks, Lukas