This series should immediately follow v8 of lib and lib/cmdline enhancements,
see https://patchew.org/linux/20260212164413.889625-1-dmantipov@yandex.ru.
Started from riscv32 build quirk, now it aims to provide platform-specific
double-word shifts and corresponding KUnit test (tested on ARM as well).

Dmitry Antipov (3):
  riscv: add platform-specific double word shifts for riscv32
  lib: kunit: add tests for __ashldi3(), __ashrdi3(), and __lshrdi3()
  riscv: fix building compressed EFI image

 arch/riscv/Kconfig                    |   3 -
 arch/riscv/kernel/image-vars.h        |   7 ++
 arch/riscv/lib/Makefile               |   1 +
 arch/riscv/lib/ashldi3.S              |  36 ++++++
 arch/riscv/lib/ashrdi3.S              |  37 ++++++
 arch/riscv/lib/lshrdi3.S              |  36 ++++++
 drivers/firmware/efi/libstub/Makefile |   4 +-
 lib/Kconfig.debug                     |  10 ++
 lib/tests/Makefile                    |   1 +
 lib/tests/shdi3_kunit.c               | 175 ++++++++++++++++++++++++++
 10 files changed, 306 insertions(+), 4 deletions(-)
 create mode 100644 arch/riscv/lib/ashldi3.S
 create mode 100644 arch/riscv/lib/ashrdi3.S
 create mode 100644 arch/riscv/lib/lshrdi3.S
 create mode 100644 lib/tests/shdi3_kunit.c

-- 
2.53.0

On Sat, 25 Apr 2026 21:51:47 +0300 Dmitry Antipov <dmantipov@yandex.ru> wrote:

> This series should immediately follow v8 of lib and lib/cmdline enhancements,
> see https://patchew.org/linux/20260212164413.889625-1-dmantipov@yandex.ru.
> Started from riscv32 build quirk, now it aims to provide platform-specific
> double-word shifts and corresponding KUnit test (tested on ARM as well).

I didn't upstream "lib and lib/cmdline enhancements v9" this cycle. 

Partly because the followup to the Sashiko review was
unclear/inconclusive.

Partly because I had a note that you'd indicated that a new version was
to be sent.

So can we please sort through these things (and the AI review) before
adding more?

On Sat, 2026-04-25 at 14:36 -0700, Andrew Morton wrote:

> I didn't upstream "lib and lib/cmdline enhancements v9" this cycle.

You don't have to upstream v9. Because v9 is v8 + initial RISC-V build
fix, which is a part of another series (this one) now. The proper sequence
is v8 + this series.

> So can we please sort through these things (and the AI review) before
> adding more?

Not sure about AI but hopefully human should realize that I'm not an
expert in m68k/sparc32/xtensa/csky/[your favorite arch here]. Enabling
and running the test on _all_ architectures where it is expected to 
work requires obtaining (or even building by myself) a cross-compiler,
setting up the kernel and QEMU, etc. I've spent a reasonable time with
RISC-V and ARM and hopefully set up a good starting point for 
m68k/sparc32/xtensa/csky/[your favorite arch here] maintainers, who are
free to incorporate the test into their target architecture.

I'm going to fix everything I consider reasonable, submit v7 and give up -
because without even a single reply from core RISC-V maintainers, this
just turns into an endless brain masturbation.

Dmitry

On Mon, Apr 27, 2026 at 11:13:20AM +0300, Dmitry Antipov wrote:
> On Sat, 2026-04-25 at 14:36 -0700, Andrew Morton wrote:
> 
> > I didn't upstream "lib and lib/cmdline enhancements v9" this cycle.
> 
> You don't have to upstream v9. Because v9 is v8 + initial RISC-V build
> fix, which is a part of another series (this one) now. The proper sequence
> is v8 + this series.
> 
> > So can we please sort through these things (and the AI review) before
> > adding more?
> 
> Not sure about AI but hopefully human should realize that I'm not an
> expert in m68k/sparc32/xtensa/csky/[your favorite arch here]. Enabling
> and running the test on _all_ architectures where it is expected to 
> work requires obtaining (or even building by myself) a cross-compiler,
> setting up the kernel and QEMU, etc. I've spent a reasonable time with
> RISC-V and ARM and hopefully set up a good starting point for 
> m68k/sparc32/xtensa/csky/[your favorite arch here] maintainers, who are
> free to incorporate the test into their target architecture.
> 
> I'm going to fix everything I consider reasonable, submit v7 and give up -
> because without even a single reply from core RISC-V maintainers, this
> just turns into an endless brain masturbation.

I believe it's better to issue v10 of that series + v7 of this in one go.

-- 
With Best Regards,
Andy Shevchenko

On Mon, 27 Apr 2026 11:23:54 +0300 Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Mon, Apr 27, 2026 at 11:13:20AM +0300, Dmitry Antipov wrote:
> > On Sat, 2026-04-25 at 14:36 -0700, Andrew Morton wrote:
> > 
> > > I didn't upstream "lib and lib/cmdline enhancements v9" this cycle.
> > 
> > You don't have to upstream v9. Because v9 is v8 + initial RISC-V build
> > fix, which is a part of another series (this one) now. The proper sequence
> > is v8 + this series.
> > 
> > > So can we please sort through these things (and the AI review) before
> > > adding more?
> > 
> > Not sure about AI but hopefully human should realize that I'm not an
> > expert in m68k/sparc32/xtensa/csky/[your favorite arch here]. Enabling
> > and running the test on _all_ architectures where it is expected to 
> > work requires obtaining (or even building by myself) a cross-compiler,
> > setting up the kernel and QEMU, etc. I've spent a reasonable time with
> > RISC-V and ARM and hopefully set up a good starting point for 
> > m68k/sparc32/xtensa/csky/[your favorite arch here] maintainers, who are
> > free to incorporate the test into their target architecture.
> > 
> > I'm going to fix everything I consider reasonable, submit v7 and give up -
> > because without even a single reply from core RISC-V maintainers, this
> > just turns into an endless brain masturbation.
> 
> I believe it's better to issue v10 of that series + v7 of this in one go.

Yes please.

It's been a while and there are so many patches and everyone's
forgotten everything.  A fresh resend of everything is a good way to
reset and restart.  It's also an opportunity to update changelogs so
they address everything which has been discussed thus far.  And an
opportunity to add cc's to everyone who has commented thus far.

On Mon, Apr 27, 2026 at 11:23:59AM +0300, Andy Shevchenko wrote:
> On Mon, Apr 27, 2026 at 11:13:20AM +0300, Dmitry Antipov wrote:
> > On Sat, 2026-04-25 at 14:36 -0700, Andrew Morton wrote:
> > 
> > > I didn't upstream "lib and lib/cmdline enhancements v9" this cycle.
> > 
> > You don't have to upstream v9. Because v9 is v8 + initial RISC-V build
> > fix, which is a part of another series (this one) now. The proper sequence
> > is v8 + this series.
> > 
> > > So can we please sort through these things (and the AI review) before
> > > adding more?
> > 
> > Not sure about AI but hopefully human should realize that I'm not an
> > expert in m68k/sparc32/xtensa/csky/[your favorite arch here]. Enabling
> > and running the test on _all_ architectures where it is expected to 
> > work requires obtaining (or even building by myself) a cross-compiler,
> > setting up the kernel and QEMU, etc. I've spent a reasonable time with
> > RISC-V and ARM and hopefully set up a good starting point for 
> > m68k/sparc32/xtensa/csky/[your favorite arch here] maintainers, who are
> > free to incorporate the test into their target architecture.
> > 
> > I'm going to fix everything I consider reasonable, submit v7 and give up -
> > because without even a single reply from core RISC-V maintainers, this
> > just turns into an endless brain masturbation.
> 
> I believe it's better to issue v10 of that series + v7 of this in one go.

(I meant v8 of that as you said + v7 of this one as v10 of that one, and sorry
 for any confusion I added in the previous reply.)

-- 
With Best Regards,
Andy Shevchenko