[GIT PULL] bitmap for 6.18

[GIT PULL] bitmap for 6.18

[Yury Norov]

Hi Linus,

Please pull bitmap patches for 6.18:
 - almost complete consolidation for HIWORD_UPDATE()-like macros from Nicolas;
 - bitmaps wrapper for Rust from Burak together with dynamic ID pool based on
   it and  tests;
 - __fls() fix for arc from Kees.

The patches spent for over 2 weeks in -next with no issues.

Thanks,
Yury

The following changes since commit e6b9dce0aeeb91dfc0974ab87f02454e24566182:

  Merge tag 'sound-6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2025-09-02 13:38:07 -0700)

are available in the Git repository at:

  https://github.com/norov/linux.git tags/bitmap-for-6.18

for you to fetch changes up to 2cdae413cd3ee6aad782cf4bce8c10fdb0f0657c:

  rust: add dynamic ID pool abstraction for bitmap (2025-09-22 15:52:44 -0400)

----------------------------------------------------------------
bitmap-for-6.18

Bits-related paches for 6.17:
 - FIELD_PREP_WM16() consolidation (Nicolas);
 - bitmaps for Rust (Burak);
 - __fls() fix for arc (Kees).

----------------------------------------------------------------
Burak Emir (5):
      rust: add bindings for bitmap.h
      rust: add bindings for bitops.h
      rust: add bitmap API.
      rust: add find_bit_benchmark_rust module.
      rust: add dynamic ID pool abstraction for bitmap

Kees Cook (1):
      arc: Fix __fls() const-foldability via __builtin_clzl()

Nicolas Frattaroli (19):
      bitmap: introduce hardware-specific bitfield operations
      mmc: dw_mmc-rockchip: switch to FIELD_PREP_WM16 macro
      soc: rockchip: grf: switch to FIELD_PREP_WM16_CONST macro
      media: synopsys: hdmirx: replace macros with bitfield variants
      drm/rockchip: lvds: switch to FIELD_PREP_WM16 macro
      phy: rockchip-emmc: switch to FIELD_PREP_WM16 macro
      drm/rockchip: dsi: switch to FIELD_PREP_WM16* macros
      drm/rockchip: vop2: switch to FIELD_PREP_WM16 macro
      phy: rockchip-samsung-dcphy: switch to FIELD_PREP_WM16 macro
      drm/rockchip: dw_hdmi_qp: switch to FIELD_PREP_WM16 macro
      drm/rockchip: inno-hdmi: switch to FIELD_PREP_WM16 macro
      phy: rockchip-usb: switch to FIELD_PREP_WM16 macro
      drm/rockchip: dw_hdmi: switch to FIELD_PREP_WM16* macros
      ASoC: rockchip: i2s-tdm: switch to FIELD_PREP_WM16_CONST macro
      net: stmmac: dwmac-rk: switch to FIELD_PREP_WM16 macro
      PCI: rockchip: Switch to FIELD_PREP_WM16* macros
      PCI: dw-rockchip: Switch to FIELD_PREP_WM16 macro
      clk: sp7021: switch to FIELD_PREP_WM16 macro
      phy: rockchip-pcie: switch to FIELD_PREP_WM16 macro

 MAINTAINERS                                        |  16 +
 arch/arc/include/asm/bitops.h                      |   2 +
 drivers/clk/clk-sp7021.c                           |  22 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c    | 142 +++--
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        |  80 ++-
 drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c     |  68 ++-
 drivers/gpu/drm/rockchip/inno_hdmi.c               |  11 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h       |   1 -
 drivers/gpu/drm/rockchip/rockchip_lvds.h           |  21 +-
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c       |  15 +-
 .../media/platform/synopsys/hdmirx/snps_hdmirx.h   |   6 +-
 drivers/mmc/host/dw_mmc-rockchip.c                 |   9 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c     |   3 +-
 drivers/pci/controller/dwc/pcie-dw-rockchip.c      |  42 +-
 drivers/pci/controller/pcie-rockchip.h             |  35 +-
 drivers/phy/rockchip/phy-rockchip-emmc.c           |   3 +-
 drivers/phy/rockchip/phy-rockchip-pcie.c           |  70 +--
 drivers/phy/rockchip/phy-rockchip-samsung-dcphy.c  |  11 +-
 drivers/phy/rockchip/phy-rockchip-usb.c            |  51 +-
 drivers/soc/rockchip/grf.c                         |  35 +-
 include/linux/hw_bitfield.h                        |  62 +++
 lib/Kconfig.debug                                  |  13 +
 lib/Makefile                                       |   1 +
 lib/find_bit_benchmark_rust.rs                     | 104 ++++
 rust/bindings/bindings_helper.h                    |   2 +
 rust/helpers/bitmap.c                              |   9 +
 rust/helpers/bitops.c                              |  23 +
 rust/helpers/helpers.c                             |   2 +
 rust/kernel/bitmap.rs                              | 600 +++++++++++++++++++++
 rust/kernel/id_pool.rs                             | 226 ++++++++
 rust/kernel/lib.rs                                 |   2 +
 security/Kconfig.hardening                         |  10 +
 sound/soc/rockchip/rockchip_i2s_tdm.h              |   4 +-
 33 files changed, 1362 insertions(+), 339 deletions(-)
 create mode 100644 include/linux/hw_bitfield.h
 create mode 100644 lib/find_bit_benchmark_rust.rs
 create mode 100644 rust/helpers/bitmap.c
 create mode 100644 rust/helpers/bitops.c
 create mode 100644 rust/kernel/bitmap.rs
 create mode 100644 rust/kernel/id_pool.rs

Re: [GIT PULL] bitmap for 6.18

[Linus Torvalds]

On Mon, 29 Sept 2025 at 13:07, Yury Norov <yury.norov@gmail.com> wrote:
>
>  - almost complete consolidation for HIWORD_UPDATE()-like macros from Nicolas;

Argh. I don't love this, but I've pulled it.

That new interface is a bit odd, and I had to wrap my head around it a
bit, but it actually looks fine when it's a single bit or it already
has a mask defined for it, and the end result is something like

        FIELD_PREP_WM16(BIT(1), val)

Yes, this is often longer than what it replaces, but quite readable,
and I think it's a good thing.

But then we have GENMASK.

The macro from hell, that was a mistake from day 0, but then took over
despite always being illogical.

It was so illogical that it had to have lots of error checking,
because it always had the wrong interface and as a result lots of
people got it wrong.

So now it has compile-time checking of the bits to make sure people
get notified when they invariably get things wrong.

The only saving grace of that thing is that checking. I feel that
often the *only* reason to use GENMASK() over any other alternative is
literally that it checks the arguments so much because the interface
is so horrific.

It does "high, low", which is often very unintuitive, and in fact the
very commit that introduced this thing from hell had to convert the
sane "low,high" cases to the other way around.

See commit 10ef6b0dffe4 ("bitops: Introduce a more generic BITMASK
macro"), and notice how ALMOST ALL use cases were switched around to
the illogical "high,low" format by that introductory phase.

And yes, I understand why that person did it: many datasheets show
bits in a register graphically, and then you see that "high .. low"
thing in a rectangle that describes the register, and that ordering
them makes 100% sense IN THAT CONTEXT.

But it damn well does not make sense in most other contexts.

In fact, even in the context of generating mask #defines, it actually
reads oddly, because you end up having things like

  /* Status register (SR) */
  #define I2C_SR_OP               GENMASK(1, 0)   /* Operation */
  #define I2C_SR_STATUS           GENMASK(3, 2)   /* controller status */
  #define I2C_SR_CAUSE            GENMASK(6, 4)   /* Abort cause */
  #define I2C_SR_TYPE             GENMASK(8, 7)   /* Receive type */
  #define I2C_SR_LENGTH           GENMASK(19, 9)  /* Transfer length */

(Yes, that's a real example from the kernel), and notice how *oddly*
the numbers flow in that series: instead of being a logical
progression of 0 .. 1 .. 2 .. 3 etc, you have 1 .. 0 .. 3 .. 2 .. 6 ..
4 etc)

I really have an almost irrational hatred of GENMASK (note "almost". I
think it's rational). I hate it so much that this almost made me not
pull the end result just because a few conversions were just
horrendous.

The very first conversion in that series does this:

-               mci_writel(host, TIMING_CON1, HIWORD_UPDATE(raw_value,
0x07ff, 1));
+               mci_writel(host, TIMING_CON1,
+                          FIELD_PREP_WM16(GENMASK(11, 1), raw_value));

and no, that new version is *NOT* more readable than the old code. I
had to really read it several times just to understand what was going
on, admittedly because the old HIWORD_UPDATE() macro was also odd.

But at least that old HIWORD_UPDATE() was odd in a "natural" way.

And it's all because GENMASK() is a horrible horrible interface, and
should only be used for generating other #defines for actual masks
when you read the datasheet.

Anyway. I just wanted to state how much I hate GENMASK(). It's almost
fine for when it is appropriate, but this is an example of where it's
very much not appropriate.

I wish we had a saner form for generating bitmasks with a better
interface. The "high,low" thing is horrendous when what you want is "I
want X bits starting at X":

Maybe we could introduce a new macro to go with BIT(x), and call it
"BITS(low,high)". Yes, we'd have to replace a few existing driver uses
of BITS(), but not very many.

Am I the only person who would find "BITS(1,11)" to be much easier to
understand than "GENMASK(11,1)"?

Random "Linus rants" email over.

             Linus

Re: [GIT PULL] bitmap for 6.18

[Nicolas Frattaroli]

On Thursday, 2 October 2025 18:46:01 Central European Summer Time Linus Torvalds wrote:
> On Mon, 29 Sept 2025 at 13:07, Yury Norov <yury.norov@gmail.com> wrote:
> >
> >  - almost complete consolidation for HIWORD_UPDATE()-like macros from Nicolas;
> 
> Argh. I don't love this, but I've pulled it.
> 
> That new interface is a bit odd, and I had to wrap my head around it a
> bit, but it actually looks fine when it's a single bit or it already
> has a mask defined for it, and the end result is something like
> 
>         FIELD_PREP_WM16(BIT(1), val)
> 
> Yes, this is often longer than what it replaces, but quite readable,
> and I think it's a good thing.
> 
> But then we have GENMASK.
> 
> The macro from hell, that was a mistake from day 0, but then took over
> despite always being illogical.
> 
> It was so illogical that it had to have lots of error checking,
> because it always had the wrong interface and as a result lots of
> people got it wrong.
> 
> So now it has compile-time checking of the bits to make sure people
> get notified when they invariably get things wrong.
> 
> The only saving grace of that thing is that checking. I feel that
> often the *only* reason to use GENMASK() over any other alternative is
> literally that it checks the arguments so much because the interface
> is so horrific.
> 
> It does "high, low", which is often very unintuitive, and in fact the
> very commit that introduced this thing from hell had to convert the
> sane "low,high" cases to the other way around.
> 
> See commit 10ef6b0dffe4 ("bitops: Introduce a more generic BITMASK
> macro"), and notice how ALMOST ALL use cases were switched around to
> the illogical "high,low" format by that introductory phase.
> 
> And yes, I understand why that person did it: many datasheets show
> bits in a register graphically, and then you see that "high .. low"
> thing in a rectangle that describes the register, and that ordering
> them makes 100% sense IN THAT CONTEXT.

Hi, that person here.

My datasheets indeed show registers in the probably verilog-derived
high:low notation. An example of what that looks like is publicly
available[1]. The PWM hardware there is the same as the one I'm
working on for the RK3576, where I was motivated to finally address
the HIWORD_UPDATE copypaste throughout drivers. During this work I
discovered, and was told by others, that this is in fact more than
just a Rockchip-specific convention.

The HIWORD_UPDATE macros specifically had the issue that they liked
to deviate from each other, e.g. in argument order. This made jumping
between drivers awkward, because the same symbol could mean two different
things.

FWIW, I am also not a fan of GENMASK's high-to-low order. I do
however prefer it over bare hex values, but that's likely because I
can't really do hex math in my head. I don't know what 0x7ff << 1
is by heart, and I wouldn't know what bit would end up being the
first set bit there.

Since this new macro is decoupled from GENMASK however, I think
people other than me will find it to be useful. Macros that make you
think about whether your mask can be statically checked at compile
time will probably result in fewer people shifting a sign bit into an
awkward place without knowing. It already stopped me from doing
precisely that.

> 
> But it damn well does not make sense in most other contexts.
> 
> In fact, even in the context of generating mask #defines, it actually
> reads oddly, because you end up having things like
> 
>   /* Status register (SR) */
>   #define I2C_SR_OP               GENMASK(1, 0)   /* Operation */
>   #define I2C_SR_STATUS           GENMASK(3, 2)   /* controller status */
>   #define I2C_SR_CAUSE            GENMASK(6, 4)   /* Abort cause */
>   #define I2C_SR_TYPE             GENMASK(8, 7)   /* Receive type */
>   #define I2C_SR_LENGTH           GENMASK(19, 9)  /* Transfer length */
> 
> (Yes, that's a real example from the kernel), and notice how *oddly*
> the numbers flow in that series: instead of being a logical
> progression of 0 .. 1 .. 2 .. 3 etc, you have 1 .. 0 .. 3 .. 2 .. 6 ..
> 4 etc)
> 
> I really have an almost irrational hatred of GENMASK (note "almost". I
> think it's rational). I hate it so much that this almost made me not
> pull the end result just because a few conversions were just
> horrendous.
> 
> The very first conversion in that series does this:
> 
> -               mci_writel(host, TIMING_CON1, HIWORD_UPDATE(raw_value,
> 0x07ff, 1));
> +               mci_writel(host, TIMING_CON1,
> +                          FIELD_PREP_WM16(GENMASK(11, 1), raw_value));
> 
> and no, that new version is *NOT* more readable than the old code. I
> had to really read it several times just to understand what was going
> on, admittedly because the old HIWORD_UPDATE() macro was also odd.
> 
> But at least that old HIWORD_UPDATE() was odd in a "natural" way.
> 
> And it's all because GENMASK() is a horrible horrible interface, and
> should only be used for generating other #defines for actual masks
> when you read the datasheet.
> 
> Anyway. I just wanted to state how much I hate GENMASK(). It's almost
> fine for when it is appropriate, but this is an example of where it's
> very much not appropriate.
> 
> I wish we had a saner form for generating bitmasks with a better
> interface. The "high,low" thing is horrendous when what you want is "I
> want X bits starting at X":
> 
> Maybe we could introduce a new macro to go with BIT(x), and call it
> "BITS(low,high)". Yes, we'd have to replace a few existing driver uses
> of BITS(), but not very many.
> 
> Am I the only person who would find "BITS(1,11)" to be much easier to
> understand than "GENMASK(11,1)"?

I'm with you on that, but others may disagree. This is may be an
artefact of Latin writing going left to right while our Arabic
numerals go right to left, I think. Different people will have
different cutoffs for where numerals conceptually start for them
and where text ends.

But then again I also think the writel(var, addr) order is unexpected,
and `ln -s target link_name` is off, and if find(1) tells me paths must
precede expression one more time I'm gonna lose it. So maybe taste in
matters like this isn't tied to numerals at all.

> 
> Random "Linus rants" email over.
> 
>              Linus
> 

Kind regards,
Nicolas Frattaroli

Link: https://opensource.rock-chips.com/images/3/36/Rockchip_RK3506_TRM_Part_1_V1.2-20250811.pdf [1]

Re: [GIT PULL] bitmap for 6.18

[Linus Torvalds]

On Thu, 2 Oct 2025 at 13:32, Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Thursday, 2 October 2025 18:46:01 Central European Summer Time Linus Torvalds wrote:
> > See commit 10ef6b0dffe4 ("bitops: Introduce a more generic BITMASK
> > macro"), and notice how ALMOST ALL use cases were switched around to
> > the illogical "high,low" format by that introductory phase.
> >
> > And yes, I understand why that person did it: many datasheets show
> > bits in a register graphically, and then you see that "high .. low"
> > thing in a rectangle that describes the register, and that ordering
> > them makes 100% sense IN THAT CONTEXT.
>
> Hi, that person here.

With "that person" I was actually thinking of Gong Chen and that
original commit 10ef6b0dffe4 from 2013.

That's the one that introduced the high,low ordering - the code it
replaced actually used low-high in the EDAC driver (and high-low in
the SIS driver).

So that's the commit that started using high/low "officially".

> My datasheets indeed show registers in the probably verilog-derived
> high:low notation.

Yeah, very traditional. I suspect it predates verilog, and yes, it's
because numbers read right-to-left/

(Unless you work for IBM, in which case you start numbering bits from
the high bit)

> FWIW, I am also not a fan of GENMASK's high-to-low order. I do
> however prefer it over bare hex values

Yeah, it's not like hex values are great either, although I do end up
often reading them just about as well as bit numbering.

> > Am I the only person who would find "BITS(1,11)" to be much easier to
> > understand than "GENMASK(11,1)"?
>
> I'm with you on that, but others may disagree.

I wouldn't necessarily mind having two different ways to express bit masks.

And sometimes you don't want "beginning and end" (never mind the order
of those two) but "beginning and size".

The HI:LO format is very common in hardware documentation, but a lot
of our _software_ conventions are typically driven by packing bits
into words, and then we typically deal in "I need X bits for this".

I'm thinking things like the page flags, which are also fixed bits,
but they are fixed at compile-time depending on various
configurations, so you have things like this

   /* Page flags: | [SECTION] | [NODE] | ZONE | [LAST_CPUPID] | ... | FLAGS | */

with the different widths specified in

    include/linux/page-flags-layout.h

with fairly complicated rules. And then we shift things explicitly
with things like

   #define LRU_GEN_MASK            ((BIT(LRU_GEN_WIDTH) - 1) << LRU_GEN_PGOFF)

and we do use BIT(), but it really ends up fundamentally being "X bits
starting at Y"

           Linus

Re: [GIT PULL] bitmap for 6.18

[Linus Walleij]

On Thu, Oct 2, 2025 at 6:46 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> Am I the only person who would find "BITS(1,11)" to be much easier to
> understand than "GENMASK(11,1)"?

You're not alone. It's obviously more intuitive in many cases,
let's add a generic BITS(lo,hi).

Linus Walleij

Re: [GIT PULL] bitmap for 6.18

[pr-tracker-bot]

The pull request you sent on Mon, 29 Sep 2025 16:07:27 -0400:

> https://github.com/norov/linux.git tags/bitmap-for-6.18

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/77633c77eee37ddc160493a4cf6070c166f47dc0

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html