[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <abcd6ce1-546a-4d49-abac-0f9b22b38ead@app.fastmail.com>
Date: Wed, 15 Jan 2025 15:27:00 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Gabriel L. Somlo" <gsomlo@...il.com>, soc@...nel.org
Cc: LKML <linux-kernel@...r.kernel.org>,
"Karol Gugala" <kgugala@...micro.com>,
"Mateusz Holenko" <mholenko@...micro.com>, "Joel Stanley" <joel@....id.au>,
"Andrew Davis" <afd@...com>
Subject: Re: [GIT PULL] litex changes for 2025-01-01
On Thu, Jan 2, 2025, at 18:06, Gabriel L. Somlo wrote:
> Hi Arnd,
>
> Thanks for applying LiteX specific patches through `soc` in the past!
> There's one patch from 2024 that seems to have fallen through the
> cracks, and part of my 2025 new year's resolution is to figure out
> how to properly act as LiteX maintainer and send proper pull requests
> up the chain, so please excuse any mistakes in the PR below :)
Hi Gabriel,
The pull request looks mostly fine, but I'd like you to resend this
one in order to improve it a little more:
- You have based on commit 56e6a3499e14 ("Merge tag 'trace-v6.13-rc5'
of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace"),
which is not an -rc release. Please rebase this on 6.13-rc1
instead (the earliest -rc release for the current merge cycle
that works as a base) in order to get a better git history
- in the subject line, drop the date and instead add the kernel
release you want this to be merged into. In particular the
information I want is whether the contents are meant as bugfixes
for the current release (and possible backports) or as
improvements that are only needed in a future release.
> ----------------------------------------------------------------
> litex patch(es) left over from 2024
>
> This is the one remaining for-upstream LiteX update from 2024 that
> has been reviewed and successfully tested against the latest Linus
> tree:
> - drivers/soc/litex: Use devm_register_restart_handler()
The tag description ends up in the commit log above a list
of the commits in it, so don't repeat that list here. A summary
of the branch contents is always welcome, especially if it
contains some background details, but it should not
duplicate the things that are easy to see otherwise.
Arnd
Powered by blists - more mailing lists