@marcan If the maintainers are AWOL, they should be removed from MAINTAINERS , as they're not exactly maintaining anything /shrug

@bagder Simon Stalenhag is fantastic!

https://noc.social/@phoronix/109927186270858469

hah, love the unmatched photo! Better off with a picture of the VisionFive 2 that actually supports the extension ;)

My venerable VG248QE had its display port die this week, so not the best of fortunes for my hardware lately!

Think I fell victim to a dead Samsung 980 overnight:/

Didn't have the firmware version that's supposedly bad, but system died overnight. Boot was getting stuck decrypting LUKS & now can't even reinstall from a livecd :)

With v6.2 being released the other day, I did a bit of a recap to remind myself of what actually
landed this time around for RISC-V. Figured I may as well share it /shrug

With the V2 on the horizon, Cristian Ciocaltea added the VisionFive v1 DT, which has been a long
time coming! Unfortunately, that platform is still not really supported in mainline and may never
get there given it's reliance on non-coherent DMA that is yet to be supported.
He did post some of the out of tree non-coherent dma patches on the list the other day though, and
while that's unlikely to land anytime soon, I hope it gets there eventually :)

Renesas finally joined the RISC-V party for v6.2, with Geert's PR adding the base DT for the
RZ/Five. This platform *also* relies on non-coherent DMA to be fully supported, but that is
currently a work in progress! That work was done by Lab Prabhakar from Renesas.


Palmer's PR is where the actually interesting stuff happens though...
Binglei Wang added support for rethooks, after a rough start with mailer issues!
Drew Jones, while not reviewing, worked on some nice cleanups to alternatives and extension
handling.
Anup got one of his many new-feature support series over the line for PMEM support.
The T-Head c9xx series cores got support for their non-standard PMU variant upstream thanks to
Heiko who has been somewhat of a champion for that platform.
RV32, not to be left out, landed support for dynamic ftrace. That work was carried out by Jamie
Iles, who, as the 32-bit bpf maintainer, clearly has an interest in that part of the arch.
Support for zstd compressed images gained support also, thanks to the work of Jisheng Zhang.
Tong Tiangen extended support for hugepages, Xianting Tian got the remainder of their
VMCOREINFO series over the line & Lui Shixin got HUGE\_VMA{P,LLOC} support enabled.
Jinyu Tang brought in support for updating the tlb & Hal Feng put the finishing touch on the base
support for the VisionFive v1 by added the serial driver for it.
Notable also is a patch from Cleo John, tidying up some styling, as it was their first :)

A whole bunch of others contributed various bits of cleanup and fixes that landed in the v6.2, PR
and for more on those check out the changelog in Palmer's PR:
https://lore.kernel.org/linux-riscv/mhng-f76eb33c-7cc1-426f-8f29-37f6bb78baec@palmer-ri-x1c9/

There were also 4 fixes PRs sent out over the course of the merge window, however none of these
really contained anything particularly significant. A lot of attention recently has been centred
around text patching, so it is no surprise that a number of the fixes are there too, with, out of
the 16 total patches in -fixes, 5 were in this area. Other than that, we had a good few general
correctness bits, for sparse warnings etc

@ecurtin @llvm @marcan I played around with it some more & it keeps "doing the wrong thing" to the point that I didn't feel I could commit it.
I *think* I'll align the files that I'm responsible for to .clang-format & just run it myself as cleanup in merge commits.

@monsieuricon Enjoy the camping!

@monsieuricon hey Konstantin, b4 question for you: Is there some special case that causes a `b4 shazam -s -t https://lore.kernel.org/all/Y+v%2FYu%2FELfzx954s@spud/` to apply my R-b here without complaining about the email mismatch?

@marcan @llvm yah I prefer it without but not to the point that I'd not change. Thanks!

@llvm @marcan Hmm, been playing with it a bit but have got stuck trying to figure out which option controls the following:

@axboe @ljs @marcan woops, hit send too soon! Was going to point out that calling out shite has to come from prolific people down.
And to behavior from maintainers/reviewers and cantankerous contributors alike!

@axboe @ljs @marcan to be honest, it'd be great if people with your profile *did* get involved more.

In today's one, I agree with stuff on both sides. Especially as a relative newcomer on the experience on that end I quite like a lot of the suggestions!
I intend going out and getting the clang-format stuff working, for instance :)

Agreeing with the message but not the delivery I feel is true for many aspects of discussion about the kernel 🙃

@llvm @marcan Right, but my perspective is a bit warped due to the "flaws" with the kernel's clangd integration.

@marcan that seems very close to sane! The corner that I am directly responsible for is small too, but I'll give it a try there (albeit with UT_Always). Thanks!

@marcan if it means fewer respins for checkpatch reporting minor stuff, or less time spent fixing it on behalf of people that's a win in my book. Curious how you get on!

@marcan does the in-kernel .clang-format do the right thing*?

@palmer hmph, not exactly glowing - but I shouldn't throw stones in a glasshouse...