In D57177#1314391, @bnovkov wrote:

Unfortunately no, I'm running the vendor's build (uboot 2022.10) since upstream support is not quite there yet.
I think that's going to change soon though, several K1-related patch series have been created in the last couple of months (e.g., CCU driver).
I have a set of scripts that I use to build the final image from the vendor's artifacts until mainline uboot is ready, I plan on converting those into a wiki page soon.

Can you please confirm the author field for the commit:

LGTM. Indeed, D57239 was the key difference.

LGTM, and it works! Thanks for chasing it down.

Seems good to bring these in.

In D56918#1309427, @obiwac wrote:

In D56918#1309166, @mhorne wrote:

I tried it out. The machine didn't suspend, instead it just froze :/

I haven't looked at the pathways for this new power device yet, but I will try to familiarize myself with it. That's all I can report today.

aie, can you confirm this works with acpiconf -s 3? Is this what you were using previously? Also, could you show me your kern.power sysctl tree?

thanks for trying this out and reviewing!

I tried it out. The machine didn't suspend, instead it just froze :/

I think my laptop works with ACPI S3; I will try this out!

Hi, thanks for your patience. I have not forgotten about this series.

I did not look in detail at all of the code, but here is some initial comments.

Thanks @vladlen, @ziaee. I just pushed the fix in commit 3f018dc958.

In D56971#1305906, @kevans wrote:

Only tangentially related, have you hit this one with your GPU?

panic: set_pages_wb: numpages 2
cpuid = 6
time = 1778680160
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00fe91a8f0
vpanic() at vpanic+0x149/frame 0xfffffe00fe91aa20
panic() at panic+0x43/frame 0xfffffe00fe91aa80
ttm_pool_shrink() at ttm_pool_shrink+0x12f/frame 0xfffffe00fe91aab0
ttm_pool_shrinker_scan() at ttm_pool_shrinker_scan+0x18/frame 0xfffffe00fe91aae0
linuxkpi_vm_lowmem() at linuxkpi_vm_lowmem+0x7d/frame 0xfffffe00fe91ab30
vm_pageout_worker() at vm_pageout_worker+0x396/frame 0xfffffe00fe91aeb0
vm_pageout() at vm_pageout+0x1d7/frame 0xfffffe00fe91aef0
fork_exit() at fork_exit+0x82/frame 0xfffffe00fe91af30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00fe91af30

The ttm_pool bits seem to setup pools at every pagesize on the system and we very periodically have to actually purge something from them. That seems to be the *only* place we use set_pages_wb (at least in drm-kmod) and I'm not sure I see anything obvious that would prevent the use of the psind > 0 pools.

check the entire range

I tried to capture the sense of the specification, rather than specific (Linux/systemd) usage. Please double check it.

LGTM

Update article tags.

Shall I move ahead with this set of changes? If anyone wants me to wait on their review, please say so.

In D56430#1292513, @carlavilla wrote:

In D56430#1292349, @ziaee wrote:

I don't really understand how the .po files work, @ebrandi usually regenerates them all at once every few months.

The .po files are generated using po4a (https://www.po4a.org/), and then they load all of them to the weblate instance.
And when the translation is finished, they convert the .po files into .adoc using also po4a

Thanks again. When I have the chance I will test this and merge the change (likely early next week).

Thanks for digging into this.

Looks good, with one required change.

VERY GOOD!

I know the "Copyright before SPDX" issue was discussed and decided (maybe ad nauseam). I admit I still have little understanding of why, but I note that much more will need to be done to make it known. New code being committed to the src tree still has the SPDX first, as this is the nearly universal precedent.
So, just saying, you who are interested will need to advertise this decision more widely.

Please also add an entry to the share/man/man9/cdefs.9 man page.

Based on the original submission it is not a typo (D48877). It took one year for the merge to happen. I suggest just to leave it as is.

Cool! A couple initial things.

In D45961#1292026, @carlavilla wrote:

If you move this to an article.
Please after putting it in production, remember to ask clusteradm@ to create a redirect in nginx

Rebase on top of content changes: D45962 and D45963.

Rebase.

Rebase.

Rebase. Handle moving the new Russian translation.

In D56429#1291890, @adrian wrote:

Looks good; do we have a manpage with the other OF_ methods?