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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 F258CC433EF for ; Tue, 7 Sep 2021 21:06:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D5DB160F45 for ; Tue, 7 Sep 2021 21:06:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346852AbhIGVID (ORCPT ); Tue, 7 Sep 2021 17:08:03 -0400 Received: from rosenzweig.io ([138.197.143.207]:46226 "EHLO rosenzweig.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232045AbhIGVIB (ORCPT ); Tue, 7 Sep 2021 17:08:01 -0400 Date: Tue, 7 Sep 2021 16:48:26 -0400 From: Alyssa Rosenzweig To: Sven Peter Cc: Jassi Brar , Rob Herring , Mark Kettenis , Hector Martin , Mohamed Mediouni , Stan Skowronek , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] dt-bindings: mailbox: Add Apple mailbox bindings Message-ID: References: <20210907145501.69161-1-sven@svenpeter.dev> <20210907145501.69161-3-sven@svenpeter.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > + - description: > > > + M3 mailboxes are an older variant with a slightly different MMIO > > > + interface still found on the M1. > > > + items: > > > + - const: apple,t8103-m3-mailbox > > > > Would be nice to document an example of where an M3 mailbox is found. > > Sure, I can add a comment that this is used for the coprocessor controlling Thunderbolt. That raises another issue ... how do we know the M3 code works at all without TB support yet? It "looks" correct but some of the IRQ handling stuff is nontrivial. > > > + interrupts: > > > + minItems: 4 > > > + items: > > > + - description: send fifo is empty interrupt > > > + - description: send fifo is not empty interrupt > > > + - description: receive fifo is empty interrupt > > > + - description: receive fifo is not empty interrupt > > > + > > > + interrupt-names: > > > + minItems: 4 > > > + items: > > > + - const: send-empty > > > + - const: send-not-empty > > > + - const: recv-empty > > > + - const: recv-not-empty > > > > If the names became not-constant the asprintf thing goes away, not sure > > that's better or worse. > > I'm not sure I understand your comment here. This property just gives a name > to the interrupts so that they can be referenced by that instead of a magic > number between 0 and 4 in the driver. D'oh, right, retracted. (Both this comment and the corresponding comment on the driver itself). Sorry about that. > > > + clocks: > > > + description: > > > + Reference to the clock gate phandle(s) if required for this mailbox. > > > + Optional since not all mailboxes are attached to a clock gate. > > > > Do we do anything with the clocks at this point? > > > > The device tree bindings describe the hardware (as best as we can without proper > documentation) and some of these mailboxes have clock gates which need to be turned > on before accessing their MMIO. This driver already tries to do that and works fine > with the downstream clock driver(s) we have. Good enough for me, thanks for clarifying 👍 Commit r-b, though Rob will surely point out problems and I'll need to rereview 😉