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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89522C47089 for ; Tue, 29 Nov 2022 09:19:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230137AbiK2JTq (ORCPT ); Tue, 29 Nov 2022 04:19:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229631AbiK2JTo (ORCPT ); Tue, 29 Nov 2022 04:19:44 -0500 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E7003E085 for ; Tue, 29 Nov 2022 01:19:43 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id d3so16113154ljl.1 for ; Tue, 29 Nov 2022 01:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=sg3QtzQpHzzTX1eXKZgkNmLpSXL6VNlIdOuizJonHpU=; b=Cmkt77kYzu0zzeTsUBSsKkObosk1j28KU1I5QCjKJBdQdEIf5nDh2ZlCuWESVYD4ox 7u+DwtiqzpDRKqxxozeN7c/TAWS8RTkfj+7FfP1otA+zoNg5+QVN1wfgVYy0NyTSsDvX qtUldOJwcZAUxuFoCUB/z7HOihJsk+L1orPOKiin9LQCeJ2f3T6ylMo8Picdil+Rats9 PxdllGY2z9L8R8q86g5y4KTnoI5KsVkr0gM45tZ7sIL+/pQViAQQbIch/SH0kxnH5e0A hMH/CvoSpKPxrMvNwq2G18fGzUpDc4ewP/fxvzecHgUJ9QJOv17wgjjAehmU6SSSVJLa 5w3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sg3QtzQpHzzTX1eXKZgkNmLpSXL6VNlIdOuizJonHpU=; b=N58JCNjeO/sDkEH1gXEc/sT/cDoX0kLzhyl+th+BUvw3Td5Tf/kvvPrfHTjPa12XHX pkxZZPawLQICiwn6FUvx12i2wdm4ZvKkj0JloclP6uo71XUTRP99/zmQGvOHmtZaoxOO aUWHQCaqopjoY5Q4TtolHfEWBjlATae9TybA9Unrf+vIfpWhHaUE70AGF2MNTRRy5mAV M6p55lZzAb9PMdD/wBPsAp/N91MqOHnvGtWELtt+2r6wNhrkARoRwwzHqJYjfhDpn0Hw vGvzxBKqEVvo6IAlwGchGoD7pKo/KgRRsY36Bv1PQf5qIp2e4HbDhOlPRQbvPfiEa/HS bTyA== X-Gm-Message-State: ANoB5pkl/P0L0YyTtpUhId+PZAcn99igPCvsozVNUvx+jZScpUP4tmyX zjzmbtzNARIABXcoLGjYTBANqQ== X-Google-Smtp-Source: AA0mqf5/jT9FnSy57Ipjz48YGhmhY5lSdTAI5VgVIguoY252oCOou9rswszb/1auQGX1dRKN4yjy1g== X-Received: by 2002:a05:651c:c89:b0:26f:bd61:ac4f with SMTP id bz9-20020a05651c0c8900b0026fbd61ac4fmr13311910ljb.396.1669713581897; Tue, 29 Nov 2022 01:19:41 -0800 (PST) Received: from [192.168.0.20] (088156142067.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.67]) by smtp.gmail.com with ESMTPSA id be13-20020a056512250d00b004947a12232bsm2095956lfb.275.2022.11.29.01.19.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 01:19:41 -0800 (PST) Message-ID: <79c1c64b-7072-3e30-78a7-5e3379d3d65f@linaro.org> Date: Tue, 29 Nov 2022 10:19:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 From: Krzysztof Kozlowski Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi To: Konrad Dybcio , Linus Walleij , Kalle Valo Cc: =?UTF-8?Q?Alvin_=c5=a0ipraga?= , Hector Martin , "~postmarketos/upstreaming@lists.sr.ht" <~postmarketos/upstreaming@lists.sr.ht>, "martin.botka@somainline.org" , "angelogioacchino.delregno@somainline.org" , "marijn.suijten@somainline.org" , "jamipkettunen@somainline.org" , Arend van Spriel , Franky Lin , Hante Meuleman , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Marek Vasut , "Zhao, Jiaqing" , "Russell King (Oracle)" , Soon Tak Lee , "linux-wireless@vger.kernel.org" , "brcm80211-dev-list.pdl@broadcom.com" , "SHA-cyfmac-dev-list@infineon.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Rob Herring References: <20220921001630.56765-1-konrad.dybcio@somainline.org> <83b90478-3974-28e6-cf13-35fc4f62e0db@marcan.st> <13b8c67c-399c-d1a6-4929-61aea27aa57d@somainline.org> <0e65a8b2-0827-af1e-602c-76d9450e3d11@marcan.st> <7fd077c5-83f8-02e2-03c1-900a47f05dc1@somainline.org> <20220922133056.eo26da4npkg6bpf2@bang-olufsen.dk> <87sfke32pc.fsf@kernel.org> <4592f87a-bb61-1c28-13f0-d041a6e7d3bf@linaro.org> <87fse76yig.fsf@kernel.org> <87bkov6x1q.fsf@kernel.org> <28991d2d-d917-af47-4f5f-4e8183569bb1@linaro.org> Content-Language: en-US In-Reply-To: <28991d2d-d917-af47-4f5f-4e8183569bb1@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28/11/2022 15:40, Konrad Dybcio wrote: > > > On 26.11.2022 22:45, Linus Walleij wrote: >> On Fri, Nov 25, 2022 at 1:25 PM Kalle Valo wrote: >>> Konrad Dybcio writes: >>> >>>> On 25.11.2022 12:53, Kalle Valo wrote: >>>>> Konrad Dybcio writes: >>>>> >>>>>> On 21.11.2022 14:56, Linus Walleij wrote: >>>>>>> On Fri, Nov 18, 2022 at 5:47 PM Konrad Dybcio wrote: >>>>>>> >>>>>>>> I can think of a couple of hacky ways to force use of 43596 fw, but I >>>>>>>> don't think any would be really upstreamable.. >>>>>>> >>>>>>> If it is only known to affect the Sony Xperias mentioned then >>>>>>> a thing such as: >>>>>>> >>>>>>> if (of_machine_is_compatible("sony,xyz") || >>>>>>> of_machine_is_compatible("sony,zzz")... ) { >>>>>>> // Enforce FW version >>>>>>> } >>>>>>> >>>>>>> would be completely acceptable in my book. It hammers the >>>>>>> problem from the top instead of trying to figure out itsy witsy >>>>>>> details about firmware revisions. >>>>>>> >>>>>>> Yours, >>>>>>> Linus Walleij >>>>>> >>>>>> Actually, I think I came up with a better approach by pulling a page >>>>>> out of Asahi folks' book - please take a look and tell me what you >>>>>> think about this: >>>>>> >>>>>> [1] >>>>>> https://github.com/SoMainline/linux/commit/4b6fccc995cd79109b0dae4e4ab2e48db97695e7 >>>>>> [2] >>>>>> https://github.com/SoMainline/linux/commit/e3ea1dc739634f734104f37fdbed046873921af7 >> >> Something in this direction works too. >> >> The upside is that it tells all operating systems how to deal >> with the firmware for this hardware. >> >>>>> Instead of a directory path ("brcm/brcmfmac43596-pcie") why not provide >>>>> just the chipset name ("brcmfmac43596-pcie")? IMHO it's unnecessary to >>>>> have directory names in Device Tree. >>>> >>>> I think it's common practice to include a full $FIRMWARE_DIR-relative >>>> path when specifying firmware in DT, though here I left out the board >>>> name bit as that's assigned dynamically anyway. That said, if you don't >>>> like it, I can change it. >>> >>> It's just that I have understood that Device Tree is supposed to >>> describe hardware and to me a firmware directory "brcm/" is a software >>> property, not a hardware property. But this is really for the Device >>> Tree maintainers to decide, they know this best :) >> >> I would personally just minimize the amount of information >> put into the device tree to be exactly what is needed to find >> the right firmware. >> >> brcm,firmware-compatible = "43596"; >> >> since the code already knows how to conjure the rest of the string. >> >> But check with Rob/Krzysztof. >> >> Yours, >> Linus Walleij > > Krzysztof, Rob [added to CC] - can I have your opinions? I just got here bunch of quotes and no original message, so my response probably won't be complete. Devicetree also describes the system integration properties because we need to know how the things are glued together. We have firmware-name property which is a form of path. The "directories" in the firmware-name are actually good because they allow to create a hierarchy based on a vendor/SoC/model/board. I don't think it is worth adding new properties replacing firmware-name. Best regards, Krzysztof