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 3C190C77B72 for ; Mon, 17 Apr 2023 21:41:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230463AbjDQVly (ORCPT ); Mon, 17 Apr 2023 17:41:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230417AbjDQVlu (ORCPT ); Mon, 17 Apr 2023 17:41:50 -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 CCC865BA7; Mon, 17 Apr 2023 14:41:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 678FF622AE; Mon, 17 Apr 2023 21:41:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 989E9C433D2; Mon, 17 Apr 2023 21:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681767680; bh=zwSRHL7ia0cXc0WBv9dvwcdxlWGC4zBtxTop1dSNYPk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=BZYR+QYjlaOb8ePdTFcn/eLhe3xwTb+cYq+quPwgRwGOmQucQabJYPajz0AfLQwTy gllUtHWvaUFC/tyjCTKLdQ7oHfbysQkCsdk608LTZbx8vqcD6/hesMBfdBGMAsUkZe 0sRTQw5yPyz5oQDNOynhCOfomFNjsQmKuNJ0WC9v98o2HfyD8vxpeUlkTMj+5qtrAA 7qGYdfWJ6a7kgeiiemL/KEbUlTqLTchU0BapdSAm0hjrgaea3zmCh3rvCKdS5jT4Bu wggtRWJhEGqtAzAlgy1NMkcyJ8vSno7KgSa4XWIRSvEwdIJpzMDUbGH2p58VXwXju+ EYKBETTkZHa9Q== Date: Mon, 17 Apr 2023 16:41:19 -0500 From: Bjorn Helgaas To: Florian Fainelli Cc: Jim Quinlan , linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Cyril Brulebois , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Message-ID: <20230417214119.GA53173@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 14, 2023 at 01:33:29PM -0700, Florian Fainelli wrote: > On 4/14/23 13:27, Bjorn Helgaas wrote: > > On Tue, Apr 11, 2023 at 12:59:17PM -0400, Jim Quinlan wrote: > ... > > > The HW+driver is able to tell us when mode (a) mode is needed. But there > > > is no easy way to tell if L1SS mode should be configured. In certain > > > situations, getting this wrong may cause a panic during boot time. So we > > > rely on the DT prop "brcm,enable-l1ss" to tell us when mode (c) is desired. > > > Using this mode only makes sense when the downstream device is L1SS-capable > > > and the OS has been configured to activate L1SS > > > (e.g. policy==powersupersave). > > > > I'm really concerned about the user experience here. I assume users > > do not want to edit the DT based on what device they plug in. They > > shouldn't need to (and probably won't) know whether the device > > supports L1SS. > > > > I hate kernel/module parameters, but I think even that would be better > > then having to edit the DT. > > The problem I see with kernel/module parameters is that it is really hard to > differentiate whether they should be applied across all instances of the > device/drivers or just for one in particular. > > The Raspberry Pi 4 is a single pcie-brcmstb instance, but we have other > systems supported by that driver on Set-top-box and Cable Modem chips for > instance where we may have different types of end-points being connected, > some of which could be Multi-chip-module (MCM) where everything is known > ahead of time, and sometimes cards that are plugged to full-sized PCIe or > mini-PCIe connectors, where some amount of runtime discoverability is > involved. > > Without inventing some custom modular parameter syntax, it may not work that > well. The Device Tree properties at least easily allow for per-instance > configuration. We do have this already (from Documentation/admin-guide/kernel-parameters.txt): pci=option[,option...] [PCI] various PCI subsystem options. Some options herein operate on a specific device or a set of devices (). These are specified in one of the following formats: [:]:.[/.]* pci::[::] Note: the first format specifies a PCI bus/device/function address which may change if new hardware is inserted, if motherboard firmware changes, or due to changes caused by other kernel parameters. If the domain is left unspecified, it is taken to be zero. Optionally, a path to a device through multiple device/function addresses can be specified after the base address (this is more robust against renumbering issues). The second format selects devices using IDs from the configuration space which may match multiple devices in the system. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0301EC77B72 for ; Mon, 17 Apr 2023 21:42:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=ufV4d7BHCYdotE11geuzZ+ESfqTVdvg90PTYaH1BnnU=; b=Wc14POzmUi8oNI m9MRTOyyAu4zqs/VNb3Sa/4W2SD3Ei/gN6EALP7+Gky4QhZmLILmQLhtH42dcwyG0X+kVybB1xavk 99ZEbv8P3AQRibp4fgr5JUBpVc2NghoCk6PcoJAFcsebEGzVNMyMgXFxseoyxEi0p2P6xJ5mQRPhq dtj5uzHLMP0J95D6RGN35gE+vccbRwpuc9044QQV4KpGn62vkDarivNCn9ye4XjYnGibVdP7eygBR Deesek53ZhHTQ/RyoB+VKF6mcsudaoYth4RQ94B2rEo4p+h3Yl2qpHKbwkmBKIWJNaoS7hiL+kHGv hDA6S2vb64ZD0CtO4kDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1poWbF-0007i4-1e; Mon, 17 Apr 2023 21:41:25 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1poWbC-0007gu-2Y; Mon, 17 Apr 2023 21:41:24 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 678E861262; Mon, 17 Apr 2023 21:41:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 989E9C433D2; Mon, 17 Apr 2023 21:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681767680; bh=zwSRHL7ia0cXc0WBv9dvwcdxlWGC4zBtxTop1dSNYPk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=BZYR+QYjlaOb8ePdTFcn/eLhe3xwTb+cYq+quPwgRwGOmQucQabJYPajz0AfLQwTy gllUtHWvaUFC/tyjCTKLdQ7oHfbysQkCsdk608LTZbx8vqcD6/hesMBfdBGMAsUkZe 0sRTQw5yPyz5oQDNOynhCOfomFNjsQmKuNJ0WC9v98o2HfyD8vxpeUlkTMj+5qtrAA 7qGYdfWJ6a7kgeiiemL/KEbUlTqLTchU0BapdSAm0hjrgaea3zmCh3rvCKdS5jT4Bu wggtRWJhEGqtAzAlgy1NMkcyJ8vSno7KgSa4XWIRSvEwdIJpzMDUbGH2p58VXwXju+ EYKBETTkZHa9Q== Date: Mon, 17 Apr 2023 16:41:19 -0500 From: Bjorn Helgaas To: Florian Fainelli Cc: Jim Quinlan , linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Bjorn Helgaas , Lorenzo Pieralisi , Cyril Brulebois , Phil Elwell , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device Message-ID: <20230417214119.GA53173@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230417_144122_924481_979C5C1D X-CRM114-Status: GOOD ( 33.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 14, 2023 at 01:33:29PM -0700, Florian Fainelli wrote: > On 4/14/23 13:27, Bjorn Helgaas wrote: > > On Tue, Apr 11, 2023 at 12:59:17PM -0400, Jim Quinlan wrote: > ... > > > The HW+driver is able to tell us when mode (a) mode is needed. But there > > > is no easy way to tell if L1SS mode should be configured. In certain > > > situations, getting this wrong may cause a panic during boot time. So we > > > rely on the DT prop "brcm,enable-l1ss" to tell us when mode (c) is desired. > > > Using this mode only makes sense when the downstream device is L1SS-capable > > > and the OS has been configured to activate L1SS > > > (e.g. policy==powersupersave). > > > > I'm really concerned about the user experience here. I assume users > > do not want to edit the DT based on what device they plug in. They > > shouldn't need to (and probably won't) know whether the device > > supports L1SS. > > > > I hate kernel/module parameters, but I think even that would be better > > then having to edit the DT. > > The problem I see with kernel/module parameters is that it is really hard to > differentiate whether they should be applied across all instances of the > device/drivers or just for one in particular. > > The Raspberry Pi 4 is a single pcie-brcmstb instance, but we have other > systems supported by that driver on Set-top-box and Cable Modem chips for > instance where we may have different types of end-points being connected, > some of which could be Multi-chip-module (MCM) where everything is known > ahead of time, and sometimes cards that are plugged to full-sized PCIe or > mini-PCIe connectors, where some amount of runtime discoverability is > involved. > > Without inventing some custom modular parameter syntax, it may not work that > well. The Device Tree properties at least easily allow for per-instance > configuration. We do have this already (from Documentation/admin-guide/kernel-parameters.txt): pci=option[,option...] [PCI] various PCI subsystem options. Some options herein operate on a specific device or a set of devices (). These are specified in one of the following formats: [:]:.[/.]* pci::[::] Note: the first format specifies a PCI bus/device/function address which may change if new hardware is inserted, if motherboard firmware changes, or due to changes caused by other kernel parameters. If the domain is left unspecified, it is taken to be zero. Optionally, a path to a device through multiple device/function addresses can be specified after the base address (this is more robust against renumbering issues). The second format selects devices using IDs from the configuration space which may match multiple devices in the system. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel