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=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 11C0BC433E5 for ; Tue, 14 Jul 2020 21:08:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 D2F4F20658 for ; Tue, 14 Jul 2020 21:08:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Lcgdca8w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D2F4F20658 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=lgyjj3wstBpQQ7qpCMbEM73yy7ue6RJlIIWNPrurOxY=; b=Lcgdca8wOEWFgyxXoGq2K7UGc e/zyzvUKr/43m0uznbh5Djp2L6HpnV/hDl/wLbEYgHVXHMK+A2nU1rWvX2C4qY9olPpVEkRwPAdZx cZ2Decx0EUYKOmVRT7dSeiiNRYzFOJzcR9P3gE5DpaEnNczqf5sEHGlBqfjTV/EDo2cuiC+1nJrMJ uNh194xnalk8jVLLBGsezRKFn2KNo48h+NBhwKcqkLMP2wXTRNyshoVewvVff/IOLoItPjdt2SHvO vTrr8tvATTX+DJxnS+wxg/R0JYGgXPbQt+7timQei/z56fAIpz3R+r2QS6IVZDKCJYwuhUAKPGgon dBB3eqbEg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvS92-0003hh-09; Tue, 14 Jul 2020 21:07:20 +0000 Received: from mail-il1-f194.google.com ([209.85.166.194]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvS8y-0003fv-Cb; Tue, 14 Jul 2020 21:07:17 +0000 Received: by mail-il1-f194.google.com with SMTP id t27so41815ill.9; Tue, 14 Jul 2020 14:07:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=44rgaqhFkzmsZwbVO86LUWD8tYa+oZDKAUnPu8DtF0A=; b=hPzfqWk8ai8GnudmqYLLfUP42Hd+eYMQdONV3AXUouCRCAw4SYE8cq4/QE2Q/BNpKU MijCWyDFD6WlaBEtAexUqpSW1yUJPLz3WQn2Lyf558Z9hwG4NDxCDvRvJWeUR8TzZRWi 9jpLTRIeFqfFIn3ny4khlk9qF/5gKUNdMQfyQ+jOIL+dowUpR/q9Sht/52imG8zg/L7H FXNGkfWgesmhvRXXFTNzLmaHBochTEVKxBcrkubaPEspNMhliyMg1gT4NJjgluBaHNgf h1zsLTsyrU3ITQ40lYAbhsHDg7ttgSZK1IF77qaxldiAKUuxzYK4MuEcWHvfE2CKxgv5 yi7Q== X-Gm-Message-State: AOAM531oemqb6fW5opcqbaMrVMyxmqaNs22e351WIE/W2FYLcbwbKxDb DZDd8BnFBab37Si8JLTD1g== X-Google-Smtp-Source: ABdhPJwRUCmm6JdxtWi64zjLurr/8NPWpWA7Tt02AKgPi/2ixQ9QM1CkDUriigx8+xKYEukMuEniJQ== X-Received: by 2002:a92:c530:: with SMTP id m16mr6856827ili.300.1594760830527; Tue, 14 Jul 2020 14:07:10 -0700 (PDT) Received: from xps15 ([64.188.179.252]) by smtp.gmail.com with ESMTPSA id w82sm52739ili.42.2020.07.14.14.07.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2020 14:07:09 -0700 (PDT) Received: (nullmailer pid 2917820 invoked by uid 1000); Tue, 14 Jul 2020 21:07:08 -0000 Date: Tue, 14 Jul 2020 15:07:08 -0600 From: Rob Herring To: Nicolas Saenz Julienne Subject: Re: [PATCH v3 1/9] dt-bindings: reset: Add a binding for the RPi Firmware reset controller Message-ID: <20200714210708.GA2897216@bogus> References: <20200612171334.26385-1-nsaenzjulienne@suse.de> <20200612171334.26385-2-nsaenzjulienne@suse.de> <20200713182356.GA413630@bogus> 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-20200714_170716_457812_2661225B X-CRM114-Status: GOOD ( 31.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, f.fainelli@gmail.com, mathias.nyman@linux.intel.com, Scott Branden , gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Anholt , andy.shevchenko@gmail.com, tim.gover@raspberrypi.org, bcm-kernel-feedback-list@broadcom.com, wahrenst@gmx.net, p.zabel@pengutronix.de, Ray Jui , helgaas@kernel.org, lorenzo.pieralisi@arm.com, linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org 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 Tue, Jul 14, 2020 at 01:59:21PM +0200, Nicolas Saenz Julienne wrote: > On Mon, 2020-07-13 at 12:23 -0600, Rob Herring wrote: > > On Fri, Jun 12, 2020 at 07:13:25PM +0200, Nicolas Saenz Julienne wrote: > > > The firmware running on the RPi VideoCore can be used to reset and > > > initialize HW controlled by the firmware. > > > > > > Signed-off-by: Nicolas Saenz Julienne > > > Reviewed-by: Florian Fainelli > > > > > > --- > > > Changes since v2: > > > - Add include file for reset IDs > > > > > > Changes since v1: > > > - Correct cells binding as per Florian's comment > > > - Change compatible string to be more generic > > > > > > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++++++++++++++++++ > > > .../reset/raspberrypi,firmware-reset.h | 13 ++++++++++++ > > > 2 files changed, 34 insertions(+) > > > create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h > > > > > > diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835- > > > firmware.yaml > > > b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835- > > > firmware.yaml > > > index b48ed875eb8e..23a885af3a28 100644 > > > --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835- > > > firmware.yaml > > > +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835- > > > firmware.yaml > > > @@ -39,6 +39,22 @@ properties: > > > - compatible > > > - "#clock-cells" > > > > > > + reset: > > > > I'm not really thrilled how this is evolving with a node per provider. > > There's no reason you can't just add #clock-cells and #reset-cells to > > the parent firmware node. > > What are the downsides? The way I see it there is not much difference. And this > way of handling things is feels more intuitive and flexible (overlays can > control what to enable easily, we can take advantage of the platform device > core). What the OS wants can evolve, so designing around the current needs of the OS is not how bindings should be done. Using overlays to add clocks or resets wouldn't really work given they are spread out over the tree. And with clocks in particular, you'd have to replace dummy fixed clocks with actual firmware clocks. Sounds fragile and messy... > > I probably should have complained with the clocks node, but that's only > > pending for 5.9. > > Note that there are more users for this pattern: "raspberrypi,firmware-ts" and > "raspberrypi,firmware-gpio". Actually you were the one to originally propose > this it[1]. :P Sigh, this is why I dislike incomplete examples... Based on that, Acked-by: Rob Herring And please get gpio and ts converted to schema and referenced here before the next time I look at this. > There already is a fair amount of churn in these drivers because of all the DT > changes we did in the past, and if we need to change how we integrate these > again, I'd really like it to be for good. > > > The bigger issue is this stuff is just trickling in one bit at a time > > which gives no context for review. What's next? Is it really a mystery > > as to what functions the firmware provides? > > We have no control over it, RPi engineers integrate new designs and new > firmware interfaces show up. This is a good example of it. > > I proposed them to use SCMI as it covers most of what they are already > providing here. But no luck so far. Once we get tired of supporting all the different firmware interfaces and the mess they become, we'll just have to start refusing custom ones. Worked for PSCI. > > You don't have to have a driver in place for every function. > > I see your point, it could be more monolithic, that said, having a driver is > essential. See the reverts I managed to pull off at the end of the series. > > [1] https://patchwork.kernel.org/patch/10166783/#21421571 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel