linux-kernel - Re: linux-next: manual merge of the bitmap tree with the devfreq tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5937399.DvuYhMxLoT@workhorse>
Date: Mon, 08 Sep 2025 13:26:18 +0200
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Yury Norov <yury.norov@...il.com>, Chanwoo Choi <cw00.choi@...sung.com>,
 Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the bitmap tree with the devfreq tree

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