On Fri, Mar 13, 2026 at 11:47:14AM +0200, Andy Shevchenko wrote: > On Thu, Mar 12, 2026 at 07:08:16PM -0400, Yury Norov wrote: > > Based on 'sizeof(x) == 4' condition, in 32-bit case the function is wired > > to ffs(), while in 64-bit case to __ffs(). The difference is substantial: > > ffs(x) == __ffs(x) + 1. Also, ffs(0) == 0, while __ffs(0) is undefined. > > > > The 32-bit behaviour is inconsistent with the function description, so it > > needs to get fixed. > > > > There are 9 individual users for the function in 6 different subsystems. > > Some arches and drivers are 64-bit only: > > - arch/loongarch/kvm/intc/eiointc.c; > > - drivers/hv/mshv_vtl_main.c; > > - kernel/liveupdate/kexec_handover.c; > > > > The others are: > > - ib_umem_find_best_pgsz(): as per comment, __ffs() should be correct; > > - rzv2m_csi_reg_write_bit(): ARCH_RENESAS only, unclear; > > - lz77_match_len(): CIFS_COMPRESSION only, unclear, experimental; > > > > None of them explicitly tweak their code for a word length, or x == 0. > > > > Requesting comments from the corresponding maintainers on how to proceed > > with this. > > > > The attached patch gets rid of 32-bit explicit support, so that both > > 32- and 64-bit versions rely on __ffs(). > > > CC: "K. Y. Srinivasan" <[email protected]> (hyperv) > > CC: Haiyang Zhang <[email protected]> (hyperv) > > CC: Jason Gunthorpe <[email protected]> (infiniband) > > CC: Leon Romanovsky <[email protected]> (infiniband) > > CC: Mark Brown <[email protected]> (spi) > > CC: Steve French <[email protected]> (smb) > > CC: Alexander Graf <[email protected]> (kexec) > > CC: Mike Rapoport <[email protected]> (kexec) > > CC: Pasha Tatashin <[email protected]> (kexec) > > Please, move the Cc: list to the... > > > Signed-off-by: Yury Norov <[email protected]> > > --- > > ...comments block. It will have the same effect on emails, but drastically > reduces unneeded noise in the commit message in the Git history.
In general case, I agree. In this particular case, I want CCs to be in the main block, and eventually got replaced with the ACKs from the proper maintainers. > You may also read this subthread (patch 18) on how to handle it locally: > https://lore.kernel.org/linux-iio/[email protected]/ + Konstantin Ryabitsev <[email protected]> (Thanks for b4!) Interesting thread. So, my workflow is: 1. git format-patch --cover-letter 2. # Edit cover letter, add To and CC section 3. git send-email 000* --to-cover --cc-cover 4. b4 am 5. # Address nits/typos in the mbox 6. git am 7. # Address substantial comments in git 8. git format-patch -v2 --cover-letter 9. # Edit cover letter again to restore body, To and CC sections 10. git send-email v2-000* --to-cover --cc-cover So, yes I loose recipients on every iteration, together with the whole cover letter. But to me it's not a big deal because I can just pull them from my mailbox. In the better world, I'd like to have: git send-email -v2 000* --to-the-same-people-as-in-v1 In the perfect world, I'd prefer to keep the cover letter under the git control, once it created, together with the recipients, once they are added, and be able to edit them just like regular commits. There's a 'git am -k', which is seemingly related to the matter, and it keeps the [PATCH] prefix. But it's not what can preserve recipients for me. I'll try b4 prep and trailers as suggested. Thanks, Yury > > include/linux/count_zeros.h | 9 +++------ > > ... > > > +#define COUNT_TRAILING_ZEROS_0 (-1) > > Shouldn't we also saturate this to BITS_PER_LONG? > > -- > With Best Regards, > Andy Shevchenko >
