From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Yury Norov <yury.norov@gmail.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: manual merge of the bitmap tree with the devfreq tree
Date: Mon, 08 Sep 2025 13:26:18 +0200 [thread overview]
Message-ID: <5937399.DvuYhMxLoT@workhorse> (raw)
In-Reply-To: <20250908175135.4215c780@canb.auug.org.au>
On Monday, 8 September 2025 09:51:35 Central European Summer Time Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the bitmap tree got a conflict in:
>
> drivers/devfreq/event/rockchip-dfi.c
>
> between commit:
>
> 7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")
>
> from the devfreq tree and commit:
>
> 414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")
>
> from the bitmap tree.
Yeah, basically both of these were by me and landed at the same time
through different trees; they were developed at different times and
the reviews just happened to conclude at the same moment. The reason
why they go through different trees is that the bitmap changes are
part of a large refactor across several drivers to make them use a
shared macro instead of reinventing their own, whereas the devfreq
side of the changes is functional changes to add LPDDR5 support and
also fix the cycle count on RK3588.
>
> I have no idea how to fix this up, so I dropped the changes from the
> bitmap tree for today. Someone should supply me with the appropriate
> resolution.
>
Dropping the bitmap tree changes of this driver is fine by me. I can
send a rebased patch of that for the next merge window to do the move
from the driver's own macro to the shared macro. The functional
change in the devfreq tree is more important to get in.
Kind regards,
Nicolas Frattaroli
next prev parent reply other threads:[~2025-09-08 11:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 7:51 linux-next: manual merge of the bitmap tree with the devfreq tree Stephen Rothwell
2025-09-08 11:26 ` Nicolas Frattaroli [this message]
2025-09-08 14:22 ` Chanwoo Choi
2025-09-09 16:46 ` Yury Norov
2025-09-09 17:42 ` Nicolas Frattaroli
2025-09-09 22:09 ` Chanwoo Choi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5937399.DvuYhMxLoT@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=cw00.choi@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox