cpumap_print_to_pagebuf() is the equivalent for the "&*pb[l]" notation
in printk-like functions. In some cases, it makes people to create
temporary buffers for the printed cpumasks, where it can be avoided.

Get rid of it in a favor of more standard printing API.

Each patch, except for the last one, is independent and may be moved with
the corresponding subsystem. Or I can take it in bitmap-for-next, at
maintainers' discretion.

On top of bitmap-for-next.

(Apologize for the bulky CC list. Feel free to review only relevant
patches.)

Yury Norov (16):
  psci: simplify hotplug_tests()
  arm: Use sysfs_emit() for cpumask show callbacks
  powerpc: Use sysfs_emit() for cpumask show callbacks
  x86/events: Use sysfs_emit() for cpumask show callbacks
  ACPI: pad: Use sysfs_emit() for idlecpus show
  cpu: Use sysfs_emit() for cpumask show callback
  devfreq: Use sysfs_emit() for cpumask show callbacks
  fpga: dfl-fme-perf: Use sysfs_emit() for cpumask show
  hwtracing: hisi_ptt: Use sysfs_emit() for cpumask show
  RDMA/hfi1: Use sysfs_emit() for cpumask show helper
  nvdimm: Use sysfs_emit() for cpumask show callback
  PCI/sysfs: Use sysfs_emit() for cpumask show callbacks
  perf: Use sysfs_emit() for cpumask show callbacks
  powercap: intel_rapl: Use sysfs_emit() for cpumask show
  thermal: intel: Use sysfs_emit() for powerclamp cpumask
  lib/bitmap-str: get rid of cpumap_print_to_pagebuf()

 arch/arm/mach-imx/mmdc.c                    |  2 +-
 arch/arm/mm/cache-l2x0-pmu.c                |  2 +-
 arch/powerpc/kernel/cacheinfo.c             |  3 ++-
 arch/powerpc/perf/hv-24x7.c                 |  2 +-
 arch/powerpc/perf/hv-gpci.c                 |  2 +-
 arch/powerpc/perf/imc-pmu.c                 |  2 +-
 arch/x86/events/amd/iommu.c                 |  2 +-
 arch/x86/events/amd/power.c                 |  2 +-
 arch/x86/events/amd/uncore.c                |  2 +-
 arch/x86/events/intel/core.c                |  2 +-
 arch/x86/events/intel/uncore.c              |  2 +-
 drivers/acpi/acpi_pad.c                     |  4 ++--
 drivers/base/cpu.c                          |  2 +-
 drivers/devfreq/event/rockchip-dfi.c        |  2 +-
 drivers/devfreq/hisi_uncore_freq.c          |  2 +-
 drivers/firmware/psci/psci_checker.c        | 14 ++------------
 drivers/fpga/dfl-fme-perf.c                 |  2 +-
 drivers/hwtracing/ptt/hisi_ptt.c            |  2 +-
 drivers/infiniband/hw/hfi1/sdma.c           |  3 ++-
 drivers/nvdimm/nd_perf.c                    |  2 +-
 drivers/pci/pci-sysfs.c                     |  7 ++++---
 drivers/perf/alibaba_uncore_drw_pmu.c       |  2 +-
 drivers/perf/amlogic/meson_ddr_pmu_core.c   |  2 +-
 drivers/perf/arm-cci.c                      |  2 +-
 drivers/perf/arm-ccn.c                      |  2 +-
 drivers/perf/arm-cmn.c                      |  2 +-
 drivers/perf/arm-ni.c                       |  2 +-
 drivers/perf/arm_cspmu/arm_cspmu.c          |  2 +-
 drivers/perf/arm_dmc620_pmu.c               |  4 ++--
 drivers/perf/arm_dsu_pmu.c                  |  2 +-
 drivers/perf/arm_pmu.c                      |  2 +-
 drivers/perf/arm_smmuv3_pmu.c               |  2 +-
 drivers/perf/arm_spe_pmu.c                  |  2 +-
 drivers/perf/cxl_pmu.c                      |  2 +-
 drivers/perf/dwc_pcie_pmu.c                 |  2 +-
 drivers/perf/fsl_imx8_ddr_perf.c            |  2 +-
 drivers/perf/fsl_imx9_ddr_perf.c            |  2 +-
 drivers/perf/fujitsu_uncore_pmu.c           |  2 +-
 drivers/perf/hisilicon/hisi_pcie_pmu.c      |  2 +-
 drivers/perf/hisilicon/hisi_uncore_pmu.c    |  2 +-
 drivers/perf/marvell_cn10k_ddr_pmu.c        |  2 +-
 drivers/perf/marvell_cn10k_tad_pmu.c        |  2 +-
 drivers/perf/marvell_pem_pmu.c              |  2 +-
 drivers/perf/nvidia_t410_c2c_pmu.c          |  2 +-
 drivers/perf/nvidia_t410_cmem_latency_pmu.c |  2 +-
 drivers/perf/qcom_l2_pmu.c                  |  2 +-
 drivers/perf/qcom_l3_pmu.c                  |  2 +-
 drivers/perf/starfive_starlink_pmu.c        |  2 +-
 drivers/perf/thunderx2_pmu.c                |  2 +-
 drivers/perf/xgene_pmu.c                    |  2 +-
 drivers/powercap/intel_rapl_common.c        |  2 +-
 drivers/thermal/intel/intel_powerclamp.c    |  2 +-
 include/linux/cpumask.h                     | 19 -------------------
 kernel/events/core.c                        |  2 +-
 lib/bitmap-str.c                            |  9 ++++-----
 55 files changed, 65 insertions(+), 92 deletions(-)

-- 
2.51.0

On Thu, 28 May 2026 14:36:07 -0400 Yury Norov <ynorov@nvidia.com> wrote:

> cpumap_print_to_pagebuf() is the equivalent for the "&*pb[l]" notation
> in printk-like functions. In some cases, it makes people to create
> temporary buffers for the printed cpumasks, where it can be avoided.
> 
> Get rid of it in a favor of more standard printing API.
> 
> Each patch, except for the last one, is independent and may be moved with
> the corresponding subsystem. Or I can take it in bitmap-for-next, at
> maintainers' discretion.
> 
> On top of bitmap-for-next.

Sashiko doesn't attempt bitmap-for-next, so it couldn't apply this series.
	https://sashiko.dev/#/patchset/20260528183625.870813-1-ynorov@nvidia.com

On Thu, May 28, 2026 at 12:18:06PM -0700, Andrew Morton wrote:
> On Thu, 28 May 2026 14:36:07 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> 
> > cpumap_print_to_pagebuf() is the equivalent for the "&*pb[l]" notation
> > in printk-like functions. In some cases, it makes people to create
> > temporary buffers for the printed cpumasks, where it can be avoided.
> > 
> > Get rid of it in a favor of more standard printing API.
> > 
> > Each patch, except for the last one, is independent and may be moved with
> > the corresponding subsystem. Or I can take it in bitmap-for-next, at
> > maintainers' discretion.
> > 
> > On top of bitmap-for-next.
> 
> Sashiko doesn't attempt bitmap-for-next, so it couldn't apply this series.
> 	https://sashiko.dev/#/patchset/20260528183625.870813-1-ynorov@nvidia.com

OK... What should I do about that?

On Thu, 28 May 2026 15:26:28 -0400 Yury Norov <ynorov@nvidia.com> wrote:

> On Thu, May 28, 2026 at 12:18:06PM -0700, Andrew Morton wrote:
> > On Thu, 28 May 2026 14:36:07 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> > 
> > > cpumap_print_to_pagebuf() is the equivalent for the "&*pb[l]" notation
> > > in printk-like functions. In some cases, it makes people to create
> > > temporary buffers for the printed cpumasks, where it can be avoided.
> > > 
> > > Get rid of it in a favor of more standard printing API.
> > > 
> > > Each patch, except for the last one, is independent and may be moved with
> > > the corresponding subsystem. Or I can take it in bitmap-for-next, at
> > > maintainers' discretion.
> > > 
> > > On top of bitmap-for-next.
> > 
> > Sashiko doesn't attempt bitmap-for-next, so it couldn't apply this series.
> > 	https://sashiko.dev/#/patchset/20260528183625.870813-1-ynorov@nvidia.com
> 
> OK... What should I do about that?

Rebase onto something which Sashiko *does* attempt.  Mainline, a few
mm.git branches.  Maybe linux-next.

Roman, is there a list of trees/branches which Sashiko tries to apply
series to?

Thanks.

On Thu, May 28, 2026 at 12:29:03PM -0700, Andrew Morton wrote:
> On Thu, 28 May 2026 15:26:28 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> 
> > On Thu, May 28, 2026 at 12:18:06PM -0700, Andrew Morton wrote:
> > > On Thu, 28 May 2026 14:36:07 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> > > 
> > > > cpumap_print_to_pagebuf() is the equivalent for the "&*pb[l]" notation
> > > > in printk-like functions. In some cases, it makes people to create
> > > > temporary buffers for the printed cpumasks, where it can be avoided.
> > > > 
> > > > Get rid of it in a favor of more standard printing API.
> > > > 
> > > > Each patch, except for the last one, is independent and may be moved with
> > > > the corresponding subsystem. Or I can take it in bitmap-for-next, at
> > > > maintainers' discretion.
> > > > 
> > > > On top of bitmap-for-next.
> > > 
> > > Sashiko doesn't attempt bitmap-for-next, so it couldn't apply this series.
> > > 	https://sashiko.dev/#/patchset/20260528183625.870813-1-ynorov@nvidia.com
> > 
> > OK... What should I do about that?
> 
> Rebase onto something which Sashiko *does* attempt.  Mainline, a few
> mm.git branches.  Maybe linux-next.

Is Sashiko a new mandatory requirement now? Documentation doesn't even
mention the bot.
 
> Roman, is there a list of trees/branches which Sashiko tries to apply
> series to?

Hi Roman,

Can you add bitmap-for-next in the list?

Thanks,
Yury

On Thu, 28 May 2026 15:32:34 -0400 Yury Norov <ynorov@nvidia.com> wrote:

> > > > Sashiko doesn't attempt bitmap-for-next, so it couldn't apply this series.
> > > > 	https://sashiko.dev/#/patchset/20260528183625.870813-1-ynorov@nvidia.com
> > > 
> > > OK... What should I do about that?
> > 
> > Rebase onto something which Sashiko *does* attempt.  Mainline, a few
> > mm.git branches.  Maybe linux-next.
> 
> Is Sashiko a new mandatory requirement now? Documentation doesn't even
> mention the bot.

It's early days and things are still evolving.

No, I'm not aware of any team having made it mandatory but boy it's
helpful.  Authors appreciate it because it finds bugs, and nobody wants
to add bugs to Linux.

On Thu, May 28, 2026 at 12:32 PM Yury Norov <ynorov@nvidia.com> wrote:
>
> On Thu, May 28, 2026 at 12:29:03PM -0700, Andrew Morton wrote:
> > On Thu, 28 May 2026 15:26:28 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> >
> > > On Thu, May 28, 2026 at 12:18:06PM -0700, Andrew Morton wrote:
> > > > On Thu, 28 May 2026 14:36:07 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> > > >
> > > > > cpumap_print_to_pagebuf() is the equivalent for the "&*pb[l]" notation
> > > > > in printk-like functions. In some cases, it makes people to create
> > > > > temporary buffers for the printed cpumasks, where it can be avoided.
> > > > >
> > > > > Get rid of it in a favor of more standard printing API.
> > > > >
> > > > > Each patch, except for the last one, is independent and may be moved with
> > > > > the corresponding subsystem. Or I can take it in bitmap-for-next, at
> > > > > maintainers' discretion.
> > > > >
> > > > > On top of bitmap-for-next.
> > > >
> > > > Sashiko doesn't attempt bitmap-for-next, so it couldn't apply this series.
> > > >   https://sashiko.dev/#/patchset/20260528183625.870813-1-ynorov@nvidia.com
> > >
> > > OK... What should I do about that?
> >
> > Rebase onto something which Sashiko *does* attempt.  Mainline, a few
> > mm.git branches.  Maybe linux-next.
>
> Is Sashiko a new mandatory requirement now? Documentation doesn't even
> mention the bot.
>
> > Roman, is there a list of trees/branches which Sashiko tries to apply
> > series to?
>
> Hi Roman,
>
> Can you add bitmap-for-next in the list?

Fwiw, you can see the list of branches attempted and the SHA they are
at in the Baseline drop down:

Baseline Status Log
tip/x86/core (0f61b1860cc3f52aef9036d7235ed1f017632193) Failed View Log
powerpc/HEAD (6916d5703ddf9a38f1f6c2cc793381a24ee914c6) Failed View Log
chanwoo/HEAD (7fd2df204f342fc17d1a0bfcd474b24232fb0f32) Failed View Log
linux-arm/HEAD (dd6c438c3e64a5ff0b5d7e78f7f9be547803ef1b) Failed View Log
linux-pm/HEAD (e7ae89a0c97ce2b68b0983cd01eda67cf373517d) Failed View Log
linux-fpga/HEAD Failed View Log
pci/HEAD (254f49634ee16a731174d2ae34bc50bd5f45e731) Failed View Log
linux-pm/thermal (21c315342b81526874acfa311f11b3f72bed4e14) Failed View Log
rdma/HEAD (67464f388d52ec172be62c99fc43697437ffa384) Failed View Log
linux-next/HEAD (f7af91adc230aa99e23330ecf85bc9badd9780ad) Failed View Log
HEAD (917719c412c48687d4a176965d1fa35320ec457c) Failed View Log

Thanks,
Ian

On Thu, May 28, 2026 at 12:44:15PM -0700, Ian Rogers wrote:
> On Thu, May 28, 2026 at 12:32 PM Yury Norov <ynorov@nvidia.com> wrote:
> >
> > On Thu, May 28, 2026 at 12:29:03PM -0700, Andrew Morton wrote:
> > > On Thu, 28 May 2026 15:26:28 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> > >
> > > > On Thu, May 28, 2026 at 12:18:06PM -0700, Andrew Morton wrote:
> > > > > On Thu, 28 May 2026 14:36:07 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> > > > >
> > > > > > cpumap_print_to_pagebuf() is the equivalent for the "&*pb[l]" notation
> > > > > > in printk-like functions. In some cases, it makes people to create
> > > > > > temporary buffers for the printed cpumasks, where it can be avoided.
> > > > > >
> > > > > > Get rid of it in a favor of more standard printing API.
> > > > > >
> > > > > > Each patch, except for the last one, is independent and may be moved with
> > > > > > the corresponding subsystem. Or I can take it in bitmap-for-next, at
> > > > > > maintainers' discretion.
> > > > > >
> > > > > > On top of bitmap-for-next.
> > > > >
> > > > > Sashiko doesn't attempt bitmap-for-next, so it couldn't apply this series.
> > > > >   https://sashiko.dev/#/patchset/20260528183625.870813-1-ynorov@nvidia.com
> > > >
> > > > OK... What should I do about that?
> > >
> > > Rebase onto something which Sashiko *does* attempt.  Mainline, a few
> > > mm.git branches.  Maybe linux-next.
> >
> > Is Sashiko a new mandatory requirement now? Documentation doesn't even
> > mention the bot.
> >
> > > Roman, is there a list of trees/branches which Sashiko tries to apply
> > > series to?
> >
> > Hi Roman,
> >
> > Can you add bitmap-for-next in the list?
> 
> Fwiw, you can see the list of branches attempted and the SHA they are
> at in the Baseline drop down:
> 
> Baseline Status Log
> tip/x86/core (0f61b1860cc3f52aef9036d7235ed1f017632193) Failed View Log
> powerpc/HEAD (6916d5703ddf9a38f1f6c2cc793381a24ee914c6) Failed View Log
> chanwoo/HEAD (7fd2df204f342fc17d1a0bfcd474b24232fb0f32) Failed View Log
> linux-arm/HEAD (dd6c438c3e64a5ff0b5d7e78f7f9be547803ef1b) Failed View Log
> linux-pm/HEAD (e7ae89a0c97ce2b68b0983cd01eda67cf373517d) Failed View Log
> linux-fpga/HEAD Failed View Log
> pci/HEAD (254f49634ee16a731174d2ae34bc50bd5f45e731) Failed View Log
> linux-pm/thermal (21c315342b81526874acfa311f11b3f72bed4e14) Failed View Log
> rdma/HEAD (67464f388d52ec172be62c99fc43697437ffa384) Failed View Log
> linux-next/HEAD (f7af91adc230aa99e23330ecf85bc9badd9780ad) Failed View Log
> HEAD (917719c412c48687d4a176965d1fa35320ec457c) Failed View Log

Thanks, Ian. Bitmap-for-next is tracked with linux-next.