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;
Date:   Wed, 17 May 2023 13:37:35 +0100
From:   Conor Dooley <conor.dooley@microchip.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
CC:     Steen Hegelund <steen.hegelund@microchip.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Lars Povlsen <lars.povlsen@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>, <nicolas.ferre@microchip.com>
Subject: Re: [PATCH] arm64: dts: microchip: add missing cache properties
Message-ID: <20230517-crop-limeade-73369ac8594d@wendy>
References: <20230421223155.115339-1-krzysztof.kozlowski@linaro.org>
 <151169f7-dcdb-47f1-9616-67c3c388a233@linaro.org>
 <7772a5981d9a3d46056a53997162d1d75d22a701.camel@microchip.com>
 <41c72642-7d46-d7d1-d49a-6bef685f934c@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="yBk2dQgk9ssUKrBX"
Content-Disposition: inline
In-Reply-To: <41c72642-7d46-d7d1-d49a-6bef685f934c@linaro.org>
Precedence: bulk

--yBk2dQgk9ssUKrBX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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,
> >=20
> > I would love to do that, but I am not familiar with the procedure, so m=
aybe you
> > could help me out?
>=20
> Hm, there is no dedicated maintainer for Microchip ARM64 platforms? I
> mean one which actually handles the patches?
>=20
> 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:
> >=20
> > Clone the upstream repo listed in MAINTAINERS:
> >=20
> > git clone git@github.com:microchip-ung/linux-upstream.git
> > cd linux-upstream
> > git checkout sparx5-next
> >=20
> > Fetch the latest mainline tag from upstream:
> >=20
> > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.=
git tag\
> >  v6.4-rc2 --no-tags
> >=20
> > Rebase the current branch on top of that tag:
> >=20
> > git rebase v6.4-rc2
> >=20
> > Use b4 to fetch and apply the mail thread patch series:
> >=20
> > b4 shazam -tsl 20230421223155.115339-1-krzysztof.kozlowski@linaro.org
>=20
> You should collect some more patches... For one patch it is probably too
> much effort. I can take it instead.
>=20
> > Tag the current work for inclusion in the next kernel version with a de=
cription:
> >=20
> > git tag -s sparx5-dt-6.5
>=20
> git tag -a -s sparx5-dt-6.5
>=20
> Because you need to provide some explanation. Take a look at examples
> from other sub-arch maintainers what to write in the tag:
>=20
> https://lore.kernel.org/soc/20230410170233.5931-1-andersson@kernel.org/T/=
#u
>=20
> https://lore.kernel.org/soc/20230405080438.156805-1-krzysztof.kozlowski@l=
inaro.org/T/
>=20
> >=20
> > Push work that to the public repo:
> >=20
> > git push origin sparx5-dt-6.5
> >=20
> > Create a pull request (to stdout) to be included in an email to the mai=
ntainers:
> >=20
> > git request-pull v6.4-rc2 origin sparx5-dt-6.5
> >=20
> > Send this PR to the maintainers and CC co-maintainers.
> >=20
> > Is this the correct procedure?
> > Who should I send the PR email to (is there a list somewhere)?
>=20
> Yes, it's correct with few nits I mentioned.
>=20
> You send it to arm@, soc@, Olof and Arnd. Addresses are in examples above.
>=20
> I will be preparing today the pull with various cleanups for arm-soc, so
> I will take the patch if you do not mind.
>=20
> For future (and all previous patches), please think what do you
> (you=3DMicrochip) 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.

--yBk2dQgk9ssUKrBX
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZGTKjwAKCRB4tDGHoIJi
0glaAP9M7mSaNPH6qr9la4GASX5843bN0fsPKI1f0pTJ0ooFJwEAvb6ooXiRt0wm
1XLSJqo9Rnzbhbl1v/n9h13p6FuWtgk=
=ypew
-----END PGP SIGNATURE-----

--yBk2dQgk9ssUKrBX--