Message ID | 20230421223155.115339-1-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1379179vqo; Fri, 21 Apr 2023 15:38:42 -0700 (PDT) X-Google-Smtp-Source: AKy350aqj0Y4eid/q06dk2G5EwT4vRZuaJ0YgzCafnF2OZulvAbeQuCsOyBCGeua3OcL3pVlG5rJ X-Received: by 2002:a05:6a00:8013:b0:63c:56f5:5053 with SMTP id eg19-20020a056a00801300b0063c56f55053mr11769410pfb.13.1682116722257; Fri, 21 Apr 2023 15:38:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682116722; cv=none; d=google.com; s=arc-20160816; b=Yeep98kGO5EpGnrVZgQW947GdQxtgImwrJ07m+nohTgySvpb4HvifW5sLy98E5oBI3 GKJucZ0HfFMUFH3kkEISTVFSiVj5rwo4dDsB51GG4r9xBFa5apw0lL4fRljUvisjUWBf aQzu48HBEUVYA9Zef/nvseMDQ/JKlJOkf5CzAU9nKpySf3+KxFN4BWJaCn4XF7N+xGqP Awn3E143Yoammeqfm6XDlFmgMGYJY9anKh9navn08z+nPt1Vqu8h45qJ73pOfKp7WfPC JF6X8Ocy/i05DMMrSWHDIroe3kOSAr9Ka/BJyj3vYcS3TUtQJkNzlU9vbgBx52UMCCeX Eb1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=pitbg/AnYT+7wXCt2mEuce2KB1B0+ui+WWGwpaQkC98=; b=g8hDWMTY9k3GDuPsVJ3BihLoFkmJH8Nk6W2o3e1sSzLPWw6PNAAWekbXpTW7oN7xkH YYrqADWEPTNnSLMaFtpDTIn0Nck4rR26nXJ8mLhCjiYWSbZJ8uUVWJuvlLjLIOs3ZLBd fxpuD94iQhXs32V8GuEpCYU7odJqSIP+hUK256kHFwY+dlabZCl35wiHKrYJr2XF1OMD K5Gqd/sgIoasoYBVrhWhpo5yj3RjGo3mdZQxQzTTISfNIusnvJ5ElS2U6YTHrEyMqW5z 0y9+yVCz1Bjrg2lk6WBB1a/LyK6++dhcMN2icXFiUPVF7icaxOOFIrHveE+sAuKzCGo3 GgzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=obQptdKk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e3-20020aa798c3000000b00638f2eb16f9si5254996pfm.343.2023.04.21.15.38.27; Fri, 21 Apr 2023 15:38:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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; dkim=pass header.i=@linaro.org header.s=google header.b=obQptdKk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233895AbjDUWcn (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Fri, 21 Apr 2023 18:32:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233887AbjDUWcQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 21 Apr 2023 18:32:16 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6205A2711 for <linux-kernel@vger.kernel.org>; Fri, 21 Apr 2023 15:31:59 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5069097bac7so3807526a12.0 for <linux-kernel@vger.kernel.org>; Fri, 21 Apr 2023 15:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1682116317; x=1684708317; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=pitbg/AnYT+7wXCt2mEuce2KB1B0+ui+WWGwpaQkC98=; b=obQptdKkaIozOZTGXFT1iVgi7FGrMW2Lj8aeh2p+N8wIZVxxTSYwSQFbVo0wieyBz5 dupy9VN1DyQ0aXwyZuqV5tQ+2BcMN0mwDRcy/Vaowqe+qnCSZo6sqQs+xsa1DuwIpwDx KkR9b4GhsHpkW32xOTQJjzFUPUmEtO5VPD723rkdbY8KSBYRjgIzrdOzW5S+VqQq/UG5 UjaSvL6HuXEudfIItlWBTQmFpkvVXXNWaRBt4Z0erOxFDDH+GLFnAT5ZFMasSBkx5iyl e42sd0Ax3liSxphHuDrnf4mqnLPQvyMWn5JIIVmb1WAkaMOAGF5JH4TKtSzvs3JiKrlr xKdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682116317; x=1684708317; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pitbg/AnYT+7wXCt2mEuce2KB1B0+ui+WWGwpaQkC98=; b=QepGyB2v1st11DDwfqBD1rdASs8jwzN8K+ZjAX0X0WzkIXgRVIXqUm+pM1cTCzmsJG 5oatq/VPH76u/Jq3E+OsFaWi0G/xiSGfT6UMVh4gPOUv95zVKQLd1fmkUgLZxo0MkdPp 4t2+H/Qkmf8O2wB6hU2jfpMBKDU6g2m91P1KvxR5Rbo3p9pQRPSUEpQYBo/XDWU2xuXp P1OluDpN6ZeGwS1Usmuu3WP5PM+aojBo592sSRZQucFEpo58IirA5Uw0MLrtcjrh/9BB x9TlT6K8nxnYC92Ivk0GULmryRJpZ5pQeB4T+p0EcvkIYw4R4+KLqw6Lvi30VEF+NJmI YILg== X-Gm-Message-State: AAQBX9c4JQdntHx4crr4M2UGD/A2g+OOxYewI356quAg+9A+WIODCTlk PZE3mnFifS0c6aHRH6Wci/Y+vA== X-Received: by 2002:a50:fa89:0:b0:4fa:b302:84d4 with SMTP id w9-20020a50fa89000000b004fab30284d4mr6180279edr.13.1682116317328; Fri, 21 Apr 2023 15:31:57 -0700 (PDT) Received: from krzk-bin.. ([2a02:810d:15c0:828:687d:8c5:41cb:9883]) by smtp.gmail.com with ESMTPSA id p15-20020aa7cc8f000000b004aef147add6sm2223867edt.47.2023.04.21.15.31.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Apr 2023 15:31:56 -0700 (PDT) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Lars Povlsen <lars.povlsen@microchip.com>, Steen Hegelund <Steen.Hegelund@microchip.com>, Daniel Machon <daniel.machon@microchip.com>, UNGLinuxDriver@microchip.com, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Subject: [PATCH] arm64: dts: microchip: add missing cache properties Date: Sat, 22 Apr 2023 00:31:55 +0200 Message-Id: <20230421223155.115339-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763827224091210077?= X-GMAIL-MSGID: =?utf-8?q?1763827224091210077?= |
Series |
arm64: dts: microchip: add missing cache properties
|
|
Commit Message
Krzysztof Kozlowski
April 21, 2023, 10:31 p.m. UTC
As all level 2 and level 3 caches are unified, add required
cache-unified and cache-level properties to fix warnings like:
sparx5_pcb125.dtb: l2-cache0: 'cache-level' is a required property
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Please take the patch via sub-arch SoC tree.
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 ++
1 file changed, 2 insertions(+)
Comments
On 22/04/2023 00:31, Krzysztof Kozlowski wrote: > As all level 2 and level 3 caches are unified, add required > cache-unified and cache-level properties to fix warnings like: > > sparx5_pcb125.dtb: l2-cache0: 'cache-level' is a required property > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > --- Anyone from Microchip picking this up? Best regards, Krzysztof
Hi Krzysztof, I would love to do that, but I am not familiar with the procedure, so maybe you could help me out? This is my understanding of what I need to do: Clone the upstream repo listed in MAINTAINERS: git clone git@github.com:microchip-ung/linux-upstream.git cd linux-upstream git checkout sparx5-next Fetch the latest mainline tag from upstream: git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag\ v6.4-rc2 --no-tags Rebase the current branch on top of that tag: git rebase v6.4-rc2 Use b4 to fetch and apply the mail thread patch series: b4 shazam -tsl 20230421223155.115339-1-krzysztof.kozlowski@linaro.org Tag the current work for inclusion in the next kernel version with a decription: git tag -s sparx5-dt-6.5 Push work that to the public repo: git push origin sparx5-dt-6.5 Create a pull request (to stdout) to be included in an email to the maintainers: git request-pull v6.4-rc2 origin sparx5-dt-6.5 Send this PR to the maintainers and CC co-maintainers. Is this the correct procedure? Who should I send the PR email to (is there a list somewhere)? BR Steen On Tue, 2023-05-16 at 18:30 +0200, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 22/04/2023 00:31, Krzysztof Kozlowski wrote: > > As all level 2 and level 3 caches are unified, add required > > cache-unified and cache-level properties to fix warnings like: > > > > sparx5_pcb125.dtb: l2-cache0: 'cache-level' is a required property > > > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > --- > > Anyone from Microchip picking this up? > > Best regards, > Krzysztof >
On 17/05/2023 13:38, Steen Hegelund wrote: > Hi Krzysztof, > > I would love to do that, but I am not familiar with the procedure, so maybe you > could help me out? Hm, there is no dedicated maintainer for Microchip ARM64 platforms? I mean one which actually handles the patches? It looks like it, because my recent changes were going through me. This also means that maybe several other changes got ignored. For example: https://lore.kernel.org/all/20230221105039.316819-2-robert.marko@sartura.hr/ https://lore.kernel.org/all/20220420194600.3416282-1-michael@walle.cc/ and others here: https://lore.kernel.org/all/?q=dfn%3Aarch%2Farm64%2Fboot%2Fdts%2Fmicrochip%2F > > This is my understanding of what I need to do: > > Clone the upstream repo listed in MAINTAINERS: > > git clone git@github.com:microchip-ung/linux-upstream.git > cd linux-upstream > git checkout sparx5-next > > Fetch the latest mainline tag from upstream: > > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag\ > v6.4-rc2 --no-tags > > Rebase the current branch on top of that tag: > > git rebase v6.4-rc2 > > Use b4 to fetch and apply the mail thread patch series: > > b4 shazam -tsl 20230421223155.115339-1-krzysztof.kozlowski@linaro.org You should collect some more patches... For one patch it is probably too much effort. I can take it instead. > > Tag the current work for inclusion in the next kernel version with a decription: > > git tag -s sparx5-dt-6.5 git tag -a -s sparx5-dt-6.5 Because you need to provide some explanation. Take a look at examples from other sub-arch maintainers what to write in the tag: https://lore.kernel.org/soc/20230410170233.5931-1-andersson@kernel.org/T/#u https://lore.kernel.org/soc/20230405080438.156805-1-krzysztof.kozlowski@linaro.org/T/ > > Push work that to the public repo: > > git push origin sparx5-dt-6.5 > > Create a pull request (to stdout) to be included in an email to the maintainers: > > git request-pull v6.4-rc2 origin sparx5-dt-6.5 > > Send this PR to the maintainers and CC co-maintainers. > > Is this the correct procedure? > Who should I send the PR email to (is there a list somewhere)? Yes, it's correct with few nits I mentioned. You send it to arm@, soc@, Olof and Arnd. Addresses are in examples above. I will be preparing today the pull with various cleanups for arm-soc, so I will take the patch if you do not mind. For future (and all previous patches), please think what do you (you=Microchip) want to do with it. If you do not handle the patches, then someone should or the platform should be marked as "Odd fixes". Best regards, Krzysztof
On Sat, 22 Apr 2023 00:31:55 +0200, Krzysztof Kozlowski wrote: > As all level 2 and level 3 caches are unified, add required > cache-unified and cache-level properties to fix warnings like: > > sparx5_pcb125.dtb: l2-cache0: 'cache-level' is a required property > > Applied, thanks! [1/1] arm64: dts: microchip: add missing cache properties https://git.kernel.org/krzk/linux-dt/c/f217d94fc632fece2a41030c2eebc4ed34a48b2a Best regards,
Hey, On Wed, May 17, 2023 at 02:10:53PM +0200, Krzysztof Kozlowski wrote: > On 17/05/2023 13:38, Steen Hegelund wrote: > > Hi Krzysztof, > > > > I would love to do that, but I am not familiar with the procedure, so maybe you > > could help me out? > > Hm, there is no dedicated maintainer for Microchip ARM64 platforms? I > mean one which actually handles the patches? > > It looks like it, because my recent changes were going through me. This > also means that maybe several other changes got ignored. For example: Aye and the branches etc in the repo itself are all a wee bit stale. > > This is my understanding of what I need to do: > > > > Clone the upstream repo listed in MAINTAINERS: > > > > git clone git@github.com:microchip-ung/linux-upstream.git > > cd linux-upstream > > git checkout sparx5-next > > > > Fetch the latest mainline tag from upstream: > > > > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag\ > > v6.4-rc2 --no-tags > > > > Rebase the current branch on top of that tag: > > > > git rebase v6.4-rc2 > > > > Use b4 to fetch and apply the mail thread patch series: > > > > b4 shazam -tsl 20230421223155.115339-1-krzysztof.kozlowski@linaro.org > > You should collect some more patches... For one patch it is probably too > much effort. I can take it instead. > > > Tag the current work for inclusion in the next kernel version with a decription: > > > > git tag -s sparx5-dt-6.5 > > git tag -a -s sparx5-dt-6.5 > > Because you need to provide some explanation. Take a look at examples > from other sub-arch maintainers what to write in the tag: > > https://lore.kernel.org/soc/20230410170233.5931-1-andersson@kernel.org/T/#u > > https://lore.kernel.org/soc/20230405080438.156805-1-krzysztof.kozlowski@linaro.org/T/ > > > > > Push work that to the public repo: > > > > git push origin sparx5-dt-6.5 > > > > Create a pull request (to stdout) to be included in an email to the maintainers: > > > > git request-pull v6.4-rc2 origin sparx5-dt-6.5 > > > > Send this PR to the maintainers and CC co-maintainers. > > > > Is this the correct procedure? > > Who should I send the PR email to (is there a list somewhere)? > > Yes, it's correct with few nits I mentioned. > > You send it to arm@, soc@, Olof and Arnd. Addresses are in examples above. > > I will be preparing today the pull with various cleanups for arm-soc, so > I will take the patch if you do not mind. > > For future (and all previous patches), please think what do you > (you=Microchip) want to do with it. If you do not handle the patches, > then someone should or the platform should be marked as "Odd fixes". If noone is set up to actually be the maintainer of the tree, and the patch volume is low, it might be a good idea to combine its maintenance with some of the other microchip trees. I've added Nicolas to CC here, since he is the main maintainer for the 32-bit ARM Microchip stuff. For some context, I maintain the RISC-V Microchip bits and a few other things like dt-bindings and some non-microchip RISC-V platforms. If you like, I could easily pick up patches for arch/arm64/boot/dts/microchip/* as I am already sending PRs to Arnd for other trees and another branch would not be much overhead! Clearly I do not know the hardware at all, and reviewing the patches would still be up to you, but I could handle the "administrative" side of things (applying the patches & sending PRs) if that would be helpful? Otherwise, Nicolas & I could probably help you through setting things up to send PRs without taking up Krzysztof's time? Either works for me! Thanks, Conor.
Hi Conor and Krzysztof, On Wed, 2023-05-17 at 13:37 +0100, Conor Dooley wrote: > Hey, > > On Wed, May 17, 2023 at 02:10:53PM +0200, Krzysztof Kozlowski wrote: > > On 17/05/2023 13:38, Steen Hegelund wrote: > > > Hi Krzysztof, > > > > > > I would love to do that, but I am not familiar with the procedure, so > > > maybe you > > > could help me out? > > > > Hm, there is no dedicated maintainer for Microchip ARM64 platforms? I > > mean one which actually handles the patches? > > > > It looks like it, because my recent changes were going through me. This > > also means that maybe several other changes got ignored. For example: > > Aye and the branches etc in the repo itself are all a wee bit stale. > > > > This is my understanding of what I need to do: > > > > > > Clone the upstream repo listed in MAINTAINERS: > > > > > > git clone git@github.com:microchip-ung/linux-upstream.git > > > cd linux-upstream > > > git checkout sparx5-next > > > > > > Fetch the latest mainline tag from upstream: > > > > > > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > tag\ > > > v6.4-rc2 --no-tags > > > > > > Rebase the current branch on top of that tag: > > > > > > git rebase v6.4-rc2 > > > > > > Use b4 to fetch and apply the mail thread patch series: > > > > > > b4 shazam -tsl 20230421223155.115339-1-krzysztof.kozlowski@linaro.org > > > > You should collect some more patches... For one patch it is probably too > > much effort. I can take it instead. > > > > > Tag the current work for inclusion in the next kernel version with a > > > decription: > > > > > > git tag -s sparx5-dt-6.5 > > > > git tag -a -s sparx5-dt-6.5 > > > > Because you need to provide some explanation. Take a look at examples > > from other sub-arch maintainers what to write in the tag: > > > > https://lore.kernel.org/soc/20230410170233.5931-1-andersson@kernel.org/T/#u > > > > https://lore.kernel.org/soc/20230405080438.156805-1-krzysztof.kozlowski@linaro.org/T/ > > > > > > > > Push work that to the public repo: > > > > > > git push origin sparx5-dt-6.5 > > > > > > Create a pull request (to stdout) to be included in an email to the > > > maintainers: > > > > > > git request-pull v6.4-rc2 origin sparx5-dt-6.5 > > > > > > Send this PR to the maintainers and CC co-maintainers. > > > > > > Is this the correct procedure? > > > Who should I send the PR email to (is there a list somewhere)? > > > > Yes, it's correct with few nits I mentioned. > > > > You send it to arm@, soc@, Olof and Arnd. Addresses are in examples above. > > > > I will be preparing today the pull with various cleanups for arm-soc, so > > I will take the patch if you do not mind. Absolutely - and I am glad that I at least got to a point where I understand the procedure, but as changes are far between, I was not aware that I had some responsibilities here. Thanks for the clarification! > > > > For future (and all previous patches), please think what do you > > (you=Microchip) want to do with it. If you do not handle the patches, > > then someone should or the platform should be marked as "Odd fixes". > > If noone is set up to actually be the maintainer of the tree, and the > patch volume is low, it might be a good idea to combine its maintenance > with some of the other microchip trees. > > I've added Nicolas to CC here, since he is the main maintainer for the > 32-bit ARM Microchip stuff. For some context, I maintain the RISC-V > Microchip bits and a few other things like dt-bindings and some > non-microchip RISC-V platforms. > > If you like, I could easily pick up patches for > arch/arm64/boot/dts/microchip/* as I am already sending PRs to Arnd for > other trees and another branch would not be much overhead! > > Clearly I do not know the hardware at all, and reviewing the patches > would still be up to you, but I could handle the "administrative" side > of things (applying the patches & sending PRs) if that would be helpful? > > Otherwise, Nicolas & I could probably help you through setting things up > to send PRs without taking up Krzysztof's time? > > Either works for me! It would be preferable for me if you (Conor) would handle the arch/arm64/boot/dts/microchip/* tree as you suggested. It is not often we update it, so it will hopefully be low overhead for you. > > Thanks, > Conor. Thanks to both of you for the assistance. Best Regards Steen
On Wed, May 17, 2023 at 02:46:38PM +0200, Steen Hegelund wrote: > On Wed, 2023-05-17 at 13:37 +0100, Conor Dooley wrote: > > On Wed, May 17, 2023 at 02:10:53PM +0200, Krzysztof Kozlowski wrote: > > > For future (and all previous patches), please think what do you > > > (you=Microchip) want to do with it. If you do not handle the patches, > > > then someone should or the platform should be marked as "Odd fixes". > > > > If noone is set up to actually be the maintainer of the tree, and the > > patch volume is low, it might be a good idea to combine its maintenance > > with some of the other microchip trees. > > > > I've added Nicolas to CC here, since he is the main maintainer for the > > 32-bit ARM Microchip stuff. For some context, I maintain the RISC-V > > Microchip bits and a few other things like dt-bindings and some > > non-microchip RISC-V platforms. > > > > If you like, I could easily pick up patches for > > arch/arm64/boot/dts/microchip/* as I am already sending PRs to Arnd for > > other trees and another branch would not be much overhead! > > > > Clearly I do not know the hardware at all, and reviewing the patches > > would still be up to you, but I could handle the "administrative" side > > of things (applying the patches & sending PRs) if that would be helpful? > > > > Otherwise, Nicolas & I could probably help you through setting things up > > to send PRs without taking up Krzysztof's time? > > > > Either works for me! > > It would be preferable for me if you (Conor) would handle the > arch/arm64/boot/dts/microchip/* tree as you suggested. It is not often we > update it, so it will hopefully be low overhead for you. Okay. I will send a patch for MAINTAINERS then - although I'll give Nicolas a change to look at it this thread first ;) If the mpu32 guys ever decide to become mpu64 then we can perhaps re-visit things. > Thanks to both of you for the assistance. No worries chief.
On 17/05/2023 at 14:58, Conor Dooley wrote: > On Wed, May 17, 2023 at 02:46:38PM +0200, Steen Hegelund wrote: >> On Wed, 2023-05-17 at 13:37 +0100, Conor Dooley wrote: >>> On Wed, May 17, 2023 at 02:10:53PM +0200, Krzysztof Kozlowski wrote: > >>>> For future (and all previous patches), please think what do you >>>> (you=Microchip) want to do with it. If you do not handle the patches, >>>> then someone should or the platform should be marked as "Odd fixes". >>> >>> If noone is set up to actually be the maintainer of the tree, and the >>> patch volume is low, it might be a good idea to combine its maintenance >>> with some of the other microchip trees. >>> >>> I've added Nicolas to CC here, since he is the main maintainer for the >>> 32-bit ARM Microchip stuff. For some context, I maintain the RISC-V >>> Microchip bits and a few other things like dt-bindings and some >>> non-microchip RISC-V platforms. >>> >>> If you like, I could easily pick up patches for >>> arch/arm64/boot/dts/microchip/* as I am already sending PRs to Arnd for >>> other trees and another branch would not be much overhead! >>> >>> Clearly I do not know the hardware at all, and reviewing the patches >>> would still be up to you, but I could handle the "administrative" side >>> of things (applying the patches & sending PRs) if that would be helpful? >>> >>> Otherwise, Nicolas & I could probably help you through setting things up >>> to send PRs without taking up Krzysztof's time? >>> >>> Either works for me! >> >> It would be preferable for me if you (Conor) would handle the >> arch/arm64/boot/dts/microchip/* tree as you suggested. It is not often we >> update it, so it will hopefully be low overhead for you. > > Okay. I will send a patch for MAINTAINERS then - although I'll give > Nicolas a change to look at it this thread first ;) Yes, sure thing that I can be added as maintainer of the arm64 part of Microchip, you can add me to a MAINTAINERS entry taking care of this and use our group git tree for this purpose, we'll add branches for that. > If the mpu32 guys ever decide to become mpu64 then we can perhaps > re-visit things. > >> Thanks to both of you for the assistance. > > No worries chief. Thanks Conor for the heads-up. Best regards, Nicolas
diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi index 0367a00a269b..6f7651b06478 100644 --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi @@ -52,6 +52,8 @@ cpu1: cpu@1 { }; L2_0: l2-cache0 { compatible = "cache"; + cache-level = <2>; + cache-unified; }; };