Been playing through Dragon Age Inquisition, and while it feels a little clunky, it's very much in the same camp as CDPR games where finishing in less than 50 hours feels like doing the game an injustice!

Reading <https://www.rte.ie/brainstorm/2023/0322/1364404-culture-shock-ireland-language/> made me think about my desire to use distinctly Irish turn of phrase while writing emails etc to a distinctly international audience.
Part of me feels I shouldn't as it is less accessible, but at the same time I live in fear of people thinking I am English or American!

Bugbot status update: it's now able to monitor lore lists and start tracking threads as bugs based on an arbitrary query. E.g. you can mention "bugbot engage" in a thread and the entire thread will be converted to a bugzilla bug (if the email of the person issuing this command matches a bugzilla account with "editbugs" group membership). Any subsequent messages in the thread will be automatically added to the bug as new comments. Any comments posted on the bug via bugzilla interface will be sent to original recipients.

Now working on the other direction -- bugs added in bugzilla will be converted to mailing list threads and sent to proper maintainers (based on certain conditions, e.g. a "bugbot" flag needs to be set to "on" and the cf_subsystem custom field needs to match the corresponding MAINTAINERS entry). Should be done tomorrow, at which point I'll be looking for early testers. :)

Yet another evening staring at alternatives.
What an endless fountain of fun.

Good ole DJ Church killing it at hooker today :)

Sending out patches with internal reviewed by tags seems so meaningless to me.
I've never seen these people before, what do their tags mean?

What that treesitter doin'?

https://www.jeffgeerling.com/blog/2023/risc-v-business-testing-starfives-visionfive-2-sbc

Interesting post from @geerlingguy about the visionfive2, but also a bit of a reflection on the RISC-V software ecosystem in general.

Huh, probably wouldn't have known about this had it not appeared here:
https://social.treehouse.systems/@fox/109938758111808053

Certainly nice for the Lina's of the world, but I wonder how far "known identity" goes. "If I google it, I'll find them"?

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

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

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

@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?

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

Clarkson's farm is such a great belly-laugh inducing show :)

Asking a contributor to resubmit a patchset because they have a v4: above information that totally belongs in the commit history is utterly fucking ridiculous IMO.
The maintainer of a driver/subsystem is not the only person whose time is valuable. /shrug

This phone autocompletes riscv to roadblock

Shame that the RISC-V and Kernel devrooms at FOSDEM tomorrow clash time wise.
I suppose it's convenient that most of the kernel room is about BPF/fs & meeting people is more beneficial than attending talks.
PWM talk and then try to get into the RISC-V room I guess...

I like the healthy dose of scepticism about marketing claims that meeting people in person at conferences provides :)

re: https://social.kernel.org/notice/AS3DZjXqKnHXtM8ZEG

Problem 1:
Nick fixed about a year ago, and to quote his commit message
```
In case the DTB provided by the bootloader/BootROM is before the kernel
image or outside /memory, we won't be able to access it through the
linear mapping, and get a segfault on setup_arch(). Currently OpenSBI
relocates DTB but that's not always the case (e.g. if FW_JUMP_FDT_ADDR
is not specified), and it's also not the most portable approach since
the default FW_JUMP_FDT_ADDR of the generic platform relocates the DTB
at a specific offset that may not be available. To avoid this situation
copy DTB so that it's visible through the linear mapping.
```

Problem 2:
I fixed a few months ago. The reserved memory scanning takes place too early
during init, before paging has been enabled. As a result, once paging *is*
enabled & the tlb flushed, trying to read the label names of reserved memory
regions causes a kernel panic. Apparently we were just the first ones to try
to write a remoteproc driver for RISC-V!
The solution was moving the call to early_init_fdt_scan_reserved_mem() after
the dtb was properly mapped.

Problem 3:
If the dtb is located outside of memory regions that the kernel is aware of, it
gets remapped into a region that the kernel *is* aware of.
However, this is done before we check for any reserved memories etc. If there
happened to be a section of unusable memory in the DT, that was then carved
out using a reserved memory region with a "no-map" property, it is entirely
possible that the DT would end up there.
This was introduced by Nick's fix for problem 1 & I've been avoiding it by just
putting the dtb somewhere that I know will be accessible to the kernel, and thus
avoiding the remapping.

Problem 4:
Introduced by my fix for problem 2. RISC-V uses the top-down method for looking
up memblocks for reserved memory regions. In a sparse configuration, if there
was to be an upper-most range, all of which was intended to be used as a DMA
region, memory allocated at some point in paging_init() would consume very small
sections of this upper DMA region. This can be observed on some configurations
on PolarFire SoC, and was easy to spot with memblock debug enabled.
These small allocations mean that when, in early_init_fdt_scan_reserved_mem(),
we look up the reserved memory node that is intended to consume the whole memory
region there is no longer enough space for this mapping.
This is worse if the memory region is non-coherent as the system will then
immediately crash.

Problem 4 can be fixed by using bottom-up searching for memblocks. This may also
fix problem 3 too, I just haven't tested it.
I'm super unsure as to whether switching the search order has some consequences
that I am just not aware of, but I probably won't be any the wiser until I send
a patch!