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 X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61579C433C1 for ; Mon, 29 Mar 2021 20:46:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36A4861996 for ; Mon, 29 Mar 2021 20:46:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230482AbhC2Uq2 (ORCPT ); Mon, 29 Mar 2021 16:46:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:49404 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231134AbhC2Upy (ORCPT ); Mon, 29 Mar 2021 16:45:54 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 00E9861924; Mon, 29 Mar 2021 20:45:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617050754; bh=Tn6txlmT/d5Y6cdWpSK86evJAyAI5ibaFDr8ZhPHJ7I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ilUFPx4hc92t2Aj4EYfhXwfBLx9FIgfYhx08XN4s09fLHol3ENfrlglaL1lCfsKaE QBBft64uV6XYkBYaIVasY9QFVUV0Ysk2k/5cHBw+UuGX3E8iOTAl6TOASLulPINCNu NegRpZT1iGQaUWL6fDINp2rePSxHQeySAt6qyuOufxvqzuqTNYd64lPcqcFIKTvAhs fi+JyNlIHBXJpL+ocTnGeKCtU/4NqjHv2OrL3JhRyBLMi2GShp23yJ/5C2fo+rOcLg QkEV5uVt+e1NL3alss/vkRHLGWAmLOWZ5BwgiZ4J931YIcStCVo55Etf9VKzFkBDO0 NdTMOLu6/6l8A== Date: Mon, 29 Mar 2021 21:45:43 +0100 From: Mark Brown To: Jim Quinlan Cc: linux-pci , Nicolas Saenz Julienne , Rob Herring , bcm-kernel-feedback-list , Jim Quinlan , Lorenzo Pieralisi , Bjorn Helgaas , Florian Fainelli , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v3 2/6] PCI: brcmstb: Add control of EP voltage regulators Message-ID: <20210329204543.GJ5166@sirena.org.uk> References: <20210326191906.43567-1-jim2101024@gmail.com> <20210326191906.43567-3-jim2101024@gmail.com> <20210329162539.GG5166@sirena.org.uk> <20210329171613.GI5166@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EVh9lyqKgK19OcEf" Content-Disposition: inline In-Reply-To: X-Cookie: Never give an inch! User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --EVh9lyqKgK19OcEf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 29, 2021 at 03:48:46PM -0400, Jim Quinlan wrote: > I'm not concerned about a namespace collision and I don't think you > should be concerned either. First, this driver is for Broadcom STB > PCIe chips and boards, and we also deliver the DT to the customers. > We typically do not have any other regulators in the DT besides the > ones I am proposing. For example, the 7216 SOC DT has 0 other You may not describe these regulators in the DT but you must have other regulators in your system, most devices need power to operate. In any case "this works for me with my DT on my system and nobody will ever change our reference design" isn't really a great approach, frankly it's not a claim I entirely believe and even if it turns out to be true for your systems if we establish this as being how regulators work for soldered down PCI devices everyone else is going to want to do the same thing, most likely making the same claims for how much control they have over the systems things will run on. > regulators -- no namespace collision possible. Our DT-generating > scripts also flag namespace issues. I admit that this driver is also > used by RPi chips, but I can easily exclude this feature from the RPI > if Nicolas has any objection. That's certainly an issue, obviously the RPI is the sort of system where I'd imagine this would be particularly useful. > Further, if you want, I can restrict the search to the two regulators > I am proposing to add to pci-bus.yaml: "vpcie12v-supply" and > "vpcie3v3-supply". No, that doesn't help - what happens if someone uses separate regulators for different PCI devices? The reason the supplies are device namespaced is that each device can look up it's own supplies and label them how it wants without reference to anything else on the board. Alternatively what happens if some device has another supply it needs to power on (eg, something that wants a clean LDO output for analogue use)? > Is the above enough to alleviate your concerns about global namespace collision? Not really. TBH it looks like this driver is keeping the regulators enabled all the time except for suspend and resume anyway, if that's all that's going on I'd have thought that you wouldn't need any explicit management in the driver anyway? Just mark the regualtors as always on and set up an appropriate suspend mode configuration and everything should work without the drivers doing anything. Unless your PMIC isn't able to provide separate suspend mode configuration for the regulators? --EVh9lyqKgK19OcEf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmBiPHYACgkQJNaLcl1U h9DcTgf+OZsWq4Kiw9u8jT0Zh0uDMR6gGhzcyfOahqmUWp9hC1kN/GHXDI3w4TeJ hP0LpX8fmakwqDIpzcznWQlCXP/ugmDG4NUXvYUdZuXA2eVLtjLJBBDOLR1OLp/b qVagVEC1Mj56FjMqlM2a76+DEj9q3l0MbYPlEldMKuxv3PeAK2QswG2jfJkITImg Ab9UhzhJb7ocDfTcgxOEyYhzhFWppAJrJZ+ZprHqDktAJAz9g6SP/kzAWNM+/X33 iXmxoro4y4Ri2cRoZWLZRlFaQqSraj0ayRuTMebWd0FCUlG6eaiFGUYNc52+jHdy yaHM7wnjraDdfm4WS1wVzjHh+I0YDA== =rc28 -----END PGP SIGNATURE----- --EVh9lyqKgK19OcEf-- 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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FFD7C433C1 for ; Tue, 30 Mar 2021 00:48:00 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 D42B061987 for ; Tue, 30 Mar 2021 00:47:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D42B061987 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender: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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cUVlwvq0W9CE8B2aU0gNtKex5W41opZHGaqaVXXqJkw=; b=oWt/DZssqGsF46mRLgsyXckba BK7kHmV+1jlCBSRKYJp2MN2zlkvDnBP6qKjHZqHqOs7vCCuoSgs7tClnZuF7IBpCNJiB8Img/mIrA o0hK5UvME9/RtjuXSV9dXuxxNR7Iej3lRvCM4gFpxWT8Idfna7rj4CAo58gQ+X4DB2LT693Ydqk5z Do2+iIZTHpdrwFC0H9r/c3wr/MydyePeuEXFyV3iD123w3KveuZP+JhKRwBpeAzJn2IAqhdkxSKeJ hYZew3ywXIGBYhfIre+VNoy83rdP6WKYjztFMHUC+V46um39T7w3CHd4eFcdFhNh89XutIf34IRy/ WDOM27IsA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lR2W2-002FLe-39; Tue, 30 Mar 2021 00:45:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lQylo-001Q1n-3l; Mon, 29 Mar 2021 20:45:58 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 00E9861924; Mon, 29 Mar 2021 20:45:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617050754; bh=Tn6txlmT/d5Y6cdWpSK86evJAyAI5ibaFDr8ZhPHJ7I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ilUFPx4hc92t2Aj4EYfhXwfBLx9FIgfYhx08XN4s09fLHol3ENfrlglaL1lCfsKaE QBBft64uV6XYkBYaIVasY9QFVUV0Ysk2k/5cHBw+UuGX3E8iOTAl6TOASLulPINCNu NegRpZT1iGQaUWL6fDINp2rePSxHQeySAt6qyuOufxvqzuqTNYd64lPcqcFIKTvAhs fi+JyNlIHBXJpL+ocTnGeKCtU/4NqjHv2OrL3JhRyBLMi2GShp23yJ/5C2fo+rOcLg QkEV5uVt+e1NL3alss/vkRHLGWAmLOWZ5BwgiZ4J931YIcStCVo55Etf9VKzFkBDO0 NdTMOLu6/6l8A== Date: Mon, 29 Mar 2021 21:45:43 +0100 From: Mark Brown To: Jim Quinlan Cc: linux-pci , Nicolas Saenz Julienne , Rob Herring , bcm-kernel-feedback-list , Jim Quinlan , Lorenzo Pieralisi , Bjorn Helgaas , Florian Fainelli , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v3 2/6] PCI: brcmstb: Add control of EP voltage regulators Message-ID: <20210329204543.GJ5166@sirena.org.uk> References: <20210326191906.43567-1-jim2101024@gmail.com> <20210326191906.43567-3-jim2101024@gmail.com> <20210329162539.GG5166@sirena.org.uk> <20210329171613.GI5166@sirena.org.uk> MIME-Version: 1.0 In-Reply-To: X-Cookie: Never give an inch! User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210329_214556_969157_A2CFF491 X-CRM114-Status: GOOD ( 23.17 ) 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: multipart/mixed; boundary="===============3554053049655248355==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3554053049655248355== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EVh9lyqKgK19OcEf" Content-Disposition: inline --EVh9lyqKgK19OcEf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 29, 2021 at 03:48:46PM -0400, Jim Quinlan wrote: > I'm not concerned about a namespace collision and I don't think you > should be concerned either. First, this driver is for Broadcom STB > PCIe chips and boards, and we also deliver the DT to the customers. > We typically do not have any other regulators in the DT besides the > ones I am proposing. For example, the 7216 SOC DT has 0 other You may not describe these regulators in the DT but you must have other regulators in your system, most devices need power to operate. In any case "this works for me with my DT on my system and nobody will ever change our reference design" isn't really a great approach, frankly it's not a claim I entirely believe and even if it turns out to be true for your systems if we establish this as being how regulators work for soldered down PCI devices everyone else is going to want to do the same thing, most likely making the same claims for how much control they have over the systems things will run on. > regulators -- no namespace collision possible. Our DT-generating > scripts also flag namespace issues. I admit that this driver is also > used by RPi chips, but I can easily exclude this feature from the RPI > if Nicolas has any objection. That's certainly an issue, obviously the RPI is the sort of system where I'd imagine this would be particularly useful. > Further, if you want, I can restrict the search to the two regulators > I am proposing to add to pci-bus.yaml: "vpcie12v-supply" and > "vpcie3v3-supply". No, that doesn't help - what happens if someone uses separate regulators for different PCI devices? The reason the supplies are device namespaced is that each device can look up it's own supplies and label them how it wants without reference to anything else on the board. Alternatively what happens if some device has another supply it needs to power on (eg, something that wants a clean LDO output for analogue use)? > Is the above enough to alleviate your concerns about global namespace collision? Not really. TBH it looks like this driver is keeping the regulators enabled all the time except for suspend and resume anyway, if that's all that's going on I'd have thought that you wouldn't need any explicit management in the driver anyway? Just mark the regualtors as always on and set up an appropriate suspend mode configuration and everything should work without the drivers doing anything. Unless your PMIC isn't able to provide separate suspend mode configuration for the regulators? --EVh9lyqKgK19OcEf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmBiPHYACgkQJNaLcl1U h9DcTgf+OZsWq4Kiw9u8jT0Zh0uDMR6gGhzcyfOahqmUWp9hC1kN/GHXDI3w4TeJ hP0LpX8fmakwqDIpzcznWQlCXP/ugmDG4NUXvYUdZuXA2eVLtjLJBBDOLR1OLp/b qVagVEC1Mj56FjMqlM2a76+DEj9q3l0MbYPlEldMKuxv3PeAK2QswG2jfJkITImg Ab9UhzhJb7ocDfTcgxOEyYhzhFWppAJrJZ+ZprHqDktAJAz9g6SP/kzAWNM+/X33 iXmxoro4y4Ri2cRoZWLZRlFaQqSraj0ayRuTMebWd0FCUlG6eaiFGUYNc52+jHdy yaHM7wnjraDdfm4WS1wVzjHh+I0YDA== =rc28 -----END PGP SIGNATURE----- --EVh9lyqKgK19OcEf-- --===============3554053049655248355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============3554053049655248355==--