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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BCFCC433EF for ; Tue, 2 Nov 2021 16:00:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 72D8060C49 for ; Tue, 2 Nov 2021 16:00:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234655AbhKBQDH (ORCPT ); Tue, 2 Nov 2021 12:03:07 -0400 Received: from mail-ot1-f49.google.com ([209.85.210.49]:38812 "EHLO mail-ot1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234338AbhKBQDF (ORCPT ); Tue, 2 Nov 2021 12:03:05 -0400 Received: by mail-ot1-f49.google.com with SMTP id c2-20020a056830348200b0055a46c889a8so9921202otu.5; Tue, 02 Nov 2021 09:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lVZoZLYUpaZTi2RFg9sQqLoO8E1t6WatefP2gNVJXh0=; b=BElFdXZD8wmO+crOoTR43KGto43bFGM23Eo/9ypt4xmyJxUjZyBif34wUC5jgwOvFs bX0BM0vAsNvv1pJPPFp4/k0lpMEHQjN5sSJTGR5kXvhLCWFZqluEvIMOn5tGq0RGw9Wf jT8W0AloIHm5oSoU163GEu7CKaA8ienNGIujWvOe/Nq1jmEoGeXVq/rz3JqZqd+Uzlt0 qROIXaizF1rqat7dy03rQ8ANJz/zDE4QvQ7fKvASFMvhPfrJlDZBbfYyLTJjdKlLbBVo ozci4HeqMVOY6Z0m609ciHJZsKw3M7qHvPYvj0JVdljf197/OzqhJDd8LkiMhn0UEoB5 EEUg== X-Gm-Message-State: AOAM532sBAGbCiHf2MIXk9kSqtV5/klYH1grgjolZyXLyiMWbENrnyap /MKJ2D6ffAXWwf0LitLXIg== X-Google-Smtp-Source: ABdhPJy5Lv9+vYTWTHyrrDWVaGcPa3crXL5SfGnGCNqx3oF0uap1WO1+gdNe56Y4Qsn7XED5FXiGrA== X-Received: by 2002:a05:6830:1293:: with SMTP id z19mr27624339otp.353.1635868829838; Tue, 02 Nov 2021 09:00:29 -0700 (PDT) Received: from robh.at.kernel.org (66-90-148-213.dyn.grandenetworks.net. [66.90.148.213]) by smtp.gmail.com with ESMTPSA id p62sm600981oif.43.2021.11.02.09.00.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Nov 2021 09:00:29 -0700 (PDT) Received: (nullmailer pid 2970063 invoked by uid 1000); Tue, 02 Nov 2021 16:00:28 -0000 Date: Tue, 2 Nov 2021 11:00:27 -0500 From: Rob Herring To: Jim Quinlan Cc: linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Mark Brown , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, Florian Fainelli , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v6 7/9] PCI: brcmstb: Add control of subdevice voltage regulators Message-ID: References: <20211029200319.23475-1-jim2101024@gmail.com> <20211029200319.23475-8-jim2101024@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211029200319.23475-8-jim2101024@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 29, 2021 at 04:03:15PM -0400, Jim Quinlan wrote: > This Broadcom STB PCIe RC driver has one port and connects directly to one > device, be it a switch or an endpoint. We want to be able to turn on/off > any regulators for that device. Control of regulators is needed because of > the chicken-and-egg situation: although the regulator is "owned" by the > device and would be best handled by its driver, the device cannot be > discovered and probed unless its regulator is already turned on. I think this can be done in a much more simple way that avoids the prior patches using the pci_ops.add_bus() (and remove_bus()) hook. add_bus is called before the core scans a child bus. In the handler, you just need to get the bridge device, then the bridge DT node, and then get the regulators and enable. Given we're talking about standard properties in a standard (bridge) node, I think the implementation for .add_bus should be common (drivers/pci/of.c). It doesn't scale to be doing this in every host bridge driver. Rob 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F07FC433F5 for ; Tue, 2 Nov 2021 16:02:01 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 4A93F60C49 for ; Tue, 2 Nov 2021 16:02:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4A93F60C49 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:References: 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: List-Owner; bh=7oBOfjiwYW5mwP+V+4IjwpjUWNV7M0KFSObm8rtZktg=; b=V2ncCFwE8Kw4Ll ejMXC9EhOLmx05Pwhk5IPqJe2pYluEM1A4+KuykaJhxCbzUEUoQQCOZ3XQwny5KF5etgKxiL9reds hWKlwsI/i78EWe1HC0MOklwTG/OGnYm85Nnvzpc+ECKJdPD5onksu7qnZB8D7V2WC+nWYp3BnfU9P 4QydQxA4nqvod9BAUZWK4crGg7qH9VRYEFwD7EqwhV3jklWYW1yh+zdfNCK3gAPOLxHY2CzpfH3SX Hgf7WUsrI0VR89NA3AHxCfhYIJC5kjanNVWdgeUJNN9rbixfjZWeC1GlMEIGi09hfuCsvermnJmUd d8YYk9iuk11I9iTR6kXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mhwDD-002DFh-FW; Tue, 02 Nov 2021 16:00:35 +0000 Received: from mail-ot1-f54.google.com ([209.85.210.54]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mhwD9-002DEj-Ax; Tue, 02 Nov 2021 16:00:32 +0000 Received: by mail-ot1-f54.google.com with SMTP id l16-20020a9d6a90000000b0054e7ab56f27so30615172otq.12; Tue, 02 Nov 2021 09:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lVZoZLYUpaZTi2RFg9sQqLoO8E1t6WatefP2gNVJXh0=; b=tfnGV7xm5qdS0y8gGwMvdnfUwHSUHRlbToNX9VivN4D1gOYqjixDorN6V/jsMrjDDb ufx9dKYKFJVlC2Zns+m56Gn75JRMxV1MrpAy+RkTG+Z3j5V6lUpsprhYjZQFX10SnbdO AriH0NxZ+Biqps3+WMDjrfUDY10pkjrUlipMHnD67rXJ0yr2UuBByw1qLsqGMr1pv/M/ Mu79sagA0xJhr+6K2eIXVfMSrm767qtE9PvlpdoX7Ory0d5Ie7SlKRMivPy5efgHcS4R RPHuHrjcPRpR9nnXGZnn6mESDYd2pi0lMJqw8Sxt/X1Ve3EY+5KFppP68KyTnk9KpyW2 GT4Q== X-Gm-Message-State: AOAM530PrIZF76qqeX67Wq9E7o8Qf954+TbkS8Ez3qOL5BHdlAYQIHAP mWJ6wSmFtgzpaubaR1NQFA== X-Google-Smtp-Source: ABdhPJy5Lv9+vYTWTHyrrDWVaGcPa3crXL5SfGnGCNqx3oF0uap1WO1+gdNe56Y4Qsn7XED5FXiGrA== X-Received: by 2002:a05:6830:1293:: with SMTP id z19mr27624339otp.353.1635868829838; Tue, 02 Nov 2021 09:00:29 -0700 (PDT) Received: from robh.at.kernel.org (66-90-148-213.dyn.grandenetworks.net. [66.90.148.213]) by smtp.gmail.com with ESMTPSA id p62sm600981oif.43.2021.11.02.09.00.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Nov 2021 09:00:29 -0700 (PDT) Received: (nullmailer pid 2970063 invoked by uid 1000); Tue, 02 Nov 2021 16:00:28 -0000 Date: Tue, 2 Nov 2021 11:00:27 -0500 From: Rob Herring To: Jim Quinlan Cc: linux-pci@vger.kernel.org, Nicolas Saenz Julienne , Mark Brown , bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, Florian Fainelli , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v6 7/9] PCI: brcmstb: Add control of subdevice voltage regulators Message-ID: References: <20211029200319.23475-1-jim2101024@gmail.com> <20211029200319.23475-8-jim2101024@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211029200319.23475-8-jim2101024@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211102_090031_401926_A9A1D8DB X-CRM114-Status: GOOD ( 14.50 ) 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, Oct 29, 2021 at 04:03:15PM -0400, Jim Quinlan wrote: > This Broadcom STB PCIe RC driver has one port and connects directly to one > device, be it a switch or an endpoint. We want to be able to turn on/off > any regulators for that device. Control of regulators is needed because of > the chicken-and-egg situation: although the regulator is "owned" by the > device and would be best handled by its driver, the device cannot be > discovered and probed unless its regulator is already turned on. I think this can be done in a much more simple way that avoids the prior patches using the pci_ops.add_bus() (and remove_bus()) hook. add_bus is called before the core scans a child bus. In the handler, you just need to get the bridge device, then the bridge DT node, and then get the regulators and enable. Given we're talking about standard properties in a standard (bridge) node, I think the implementation for .add_bus should be common (drivers/pci/of.c). It doesn't scale to be doing this in every host bridge driver. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel