Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp5304765rwn; Mon, 12 Sep 2022 07:14:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR5wT9VBhMkxz0i+2B7bGdXacNkR2iZtFvgInWwh0pTA9HDdpHMuAWw32zTL7XyU+s2Bt58C X-Received: by 2002:a17:907:a0c7:b0:77c:d4ac:e8f1 with SMTP id hw7-20020a170907a0c700b0077cd4ace8f1mr4448997ejc.354.1662992080653; Mon, 12 Sep 2022 07:14:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662992080; cv=none; d=google.com; s=arc-20160816; b=jWnaPjPxbwJ6i6/sp/dKfYZRxNDNxvVbW+ywCs0t1iaPlDmQHAPxn0+Q8iass9pWUd 5+ih59+kHp/ceJaM+HwOamCJQr8PxZFvsONmD/MfKiwYZ4sIVF+D+I9aO7K7G6+1ZK3M hoJ7QMUeCLYS6oGUpwQNghiptkxXSWlrGMNIdQZMkdmFglWR5j/fCyN9/+BpE8FzIEXE jJt07O0j7lql4kiPwrmJqySvJ1G4b1Gadorh0L3sZw0x0MglVSGjLxRT7HE7+V1rgmR3 VyqWKCjngLRnGmUBd1c4Rs+9I1Z0Fw29SSfzegoG/VFQh+a7F1Mq9ZV9Jrl5Z+dJW6pt KRnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:content-transfer-encoding :mime-version:references:subject:in-reply-to:cc:to:from:date; bh=nJbXejtZrfKI6mi0mDmHrGuLlvye8pC9v7p7KHBlE0k=; b=fRLIxEnHH7gs8+pnOyFkn28VNVu5Ocoz8nm/CMUWLdjzRR3O1wxdtwFiOGgRL4hD9C u23HDoxUtNvYfQEqypUk10mwwiDtTvy6DPLgvUMBg46LCeSvpcgSkF+EqSMZHGU1ehsC hDvBF8omlpDyF5YU14NIpVPkzf80kuYvU1riYneMyXce+u94DD6I/kDEJYMZvtZHf6K5 hv/UEdEQsk3suPKJB+XtchIqTELSWLZihaHsIuK1LuLA2ZckGuMEZkoJCEAZrnp4hyuQ X+APEtSA8wtlrrgBM5OIin+aUo5dkgS9wXPIQaDRRvhKn20cJAwWsPk9y0jIoOQZGG5o E5bA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk37-20020a1709077fa500b007790ac5679csi7305042ejc.204.2022.09.12.07.14.18; Mon, 12 Sep 2022 07:14:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230089AbiILONR (ORCPT + 64 others); Mon, 12 Sep 2022 10:13:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230000AbiILONP (ORCPT ); Mon, 12 Sep 2022 10:13:15 -0400 Received: from sibelius.xs4all.nl (80-61-163-207.fixed.kpn.net [80.61.163.207]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E7A7DF82; Mon, 12 Sep 2022 07:13:12 -0700 (PDT) Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id a816cab0; Mon, 12 Sep 2022 16:13:08 +0200 (CEST) Date: Mon, 12 Sep 2022 16:13:08 +0200 (CEST) From: Mark Kettenis To: "Russell King (Oracle)" Cc: ALSI@bang-olufsen.dk, aspriel@gmail.com, franky.lin@broadcom.com, hante.meuleman@broadcom.com, alyssa@rosenzweig.io, asahi@lists.linux.dev, brcm80211-dev-list.pdl@broadcom.com, davem@davemloft.net, devicetree@vger.kernel.org, edumazet@google.com, marcan@marcan.st, kuba@kernel.org, kvalo@kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, zajec5@gmail.com, robh+dt@kernel.org, SHA-cyfmac-dev-list@infineon.com, sven@svenpeter.dev, arend@broadcom.com In-Reply-To: Subject: Re: [PATCH wireless-next v2 01/12] dt-bindings: net: bcm4329-fmac: Add Apple properties & chips References: <20220912115911.e7dlm2xugfq57mei@bang-olufsen.dk> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-ID: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org > Date: Mon, 12 Sep 2022 15:01:06 +0100 > From: "Russell King (Oracle)" > > On Mon, Sep 12, 2022 at 01:04:58PM +0100, Russell King (Oracle) wrote: > > On Mon, Sep 12, 2022 at 11:59:17AM +0000, Alvin Šipraga wrote: > > > On Mon, Sep 12, 2022 at 10:52:41AM +0100, Russell King wrote: > > > > From: Hector Martin > > > > > > > > This binding is currently used for SDIO devices, but these chips are > > > > also used as PCIe devices on DT platforms and may be represented in the > > > > DT. Re-use the existing binding and add chip compatibles used by Apple > > > > T2 and M1 platforms (the T2 ones are not known to be used in DT > > > > platforms, but we might as well document them). > > > > > > > > Then, add properties required for firmware selection and calibration on > > > > M1 machines. > > > > > > > > Reviewed-by: Linus Walleij > > > > Signed-off-by: Hector Martin > > > > Reviewed-by: Mark Kettenis > > > > Reviewed-by: Rob Herring > > > > Signed-off-by: Russell King (Oracle) > > > > --- > > > > .../net/wireless/brcm,bcm4329-fmac.yaml | 39 +++++++++++++++++-- > > > > 1 file changed, 35 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > index 53b4153d9bfc..fec1cc9b9a08 100644 > > > > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml > > > > @@ -4,7 +4,7 @@ > > > > $id: http://devicetree.org/schemas/net/wireless/brcm,bcm4329-fmac.yaml# > > > > $schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > > > -title: Broadcom BCM4329 family fullmac wireless SDIO devices > > > > +title: Broadcom BCM4329 family fullmac wireless SDIO/PCIE devices > > > > > > > > maintainers: > > > > - Arend van Spriel > > > > @@ -41,11 +41,17 @@ title: Broadcom BCM4329 family fullmac wireless SDIO devices > > > > - cypress,cyw4373-fmac > > > > - cypress,cyw43012-fmac > > > > - const: brcm,bcm4329-fmac > > > > - - const: brcm,bcm4329-fmac > > > > + - enum: > > > > + - brcm,bcm4329-fmac > > > > + - pci14e4,43dc # BCM4355 > > > > + - pci14e4,4464 # BCM4364 > > > > + - pci14e4,4488 # BCM4377 > > > > + - pci14e4,4425 # BCM4378 > > > > + - pci14e4,4433 # BCM4387 > > > > > > > > reg: > > > > - description: SDIO function number for the device, for most cases > > > > - this will be 1. > > > > + description: SDIO function number for the device (for most cases > > > > + this will be 1) or PCI device identifier. > > > > > > > > interrupts: > > > > maxItems: 1 > > > > @@ -85,6 +91,31 @@ title: Broadcom BCM4329 family fullmac wireless SDIO devices > > > > takes precedence. > > > > type: boolean > > > > > > > > + brcm,cal-blob: > > > > + $ref: /schemas/types.yaml#/definitions/uint8-array > > > > + description: A per-device calibration blob for the Wi-Fi radio. This > > > > + should be filled in by the bootloader from platform configuration > > > > + data, if necessary, and will be uploaded to the device if present. > > > > > > Is this a leftover from a previous revision of the patchset? Because as > > > far as I can tell, the CLM blob is (still) being loaded via firmware, > > > and no additional parsing has been added for this particular OF > > > property. Should it be dropped? > > > > It does appear to be unparsed, but I don't know whether it's needed for > > the binding or not. I'll wait for the Asahi folk to review your comment > > before possibly removing it. > > Okay, the answer is, it is still very much part of the binding, and > the m1n1 boot loader populates it. > > This series is a subset of a larger series (remember the previous 34 > or 35 patch series?), so there are things in the binding document > which are not included in this series. > > I don't think it makes sense to break up the binding document given > that it has already been reviewed several times in its current state, > should we really remove this one property and throw away all that > review effort. The OpenBSD driver already uses these properties. So even if the Linux driver doesn't use this yet, there is an existing implementation that does. That should be good enough for it to be included in the binding isn't it?