Krzysztof Kozlowski
Posts
353Following
45Followers
329#standwithukraine 🇵🇱 🇪🇺 🇺🇦 🇨🇭
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social
GitHub: https://github.com/krzk/
Traveling Instagram / Wanderquak: https://www.instagram.com/wanderquak/
Home brewery: https://brewalot.ch
Our gardening (and worm farm!): https://growalot.ch
Krzysztof Kozlowski
krzk
@fabrice Lack of public hardware access changes nothing in the review - you can still review everything the same way. And testing honestly also does not change much, since even after public announcement not many upstream developers have access to hardware to provide tests. IOW, testing would not differ if patch is released post announcement. Unless of course you mean years post, but that defeats any purpose of upstream (like is for 90% of other SoC vendors...).
0
0
1
I missed actually important milestone in July 2025 - first Linux kernel patches for Snapdragon X2 Elite SoC (next compute flagship model) were posted 2 months before public announcement:
https://lore.kernel.org/all/20250716151535.4054172-1-pankaj.patil@oss.qualcomm.com/
https://lore.kernel.org/all/20250716151535.4054172-1-pankaj.patil@oss.qualcomm.com/
1
1
6
Krzysztof Kozlowski
krzk
Edited yesterday
If someone asked me 5 years ago, I would not believe that I could produce such a statement about major SoC vendor:
https://lore.kernel.org/all/2509536d-cdec-448d-bf20-80d2b3d6728a@kernel.org/
Qualcomm and Linaro were upstreaming before significant amount of code to the Linux kernel for supporting their SoCs , but around 2021-2022 things changed significantly. Just to recap major milestones of:
2022 November: One day after public announcement of new Snapdragon 8 Gen 2 flagship SoC (SM8550), Qualcomm Landing Team in Linaro posted basic support for it:
https://lore.kernel.org/all/20221116103146.2556846-1-abel.vesa@linaro.org/
2023 October: One day after public announcement of next flagship Snapdragon 8 Gen 3 (SM8650), same team posts almost full (not basic!) support for it:
https://lore.kernel.org/all/20231025-topic-sm8650-upstream-dt-v1-0-a821712af62f@linaro.org/
2024 October: One day after public announcement of next flagship Snapdragon 8 Elite (SM8750), Linaro and Qualcomm team posts comprehensive support for it:
https://lore.kernel.org/all/20241021232114.2636083-1-quic_molvera@quicinc.com/
2025 September: Same day of public announcement of Snapdragon 8 Elite Gen 5 (Kaanapali), Qualcomm posts comprehensive support for it:
https://lore.kernel.org/all/20250924-knp-dts-v1-0-3fdbc4b9e1b1@oss.qualcomm.com/
Now things changed:
2026 March and from now on: Qualcomm posts patches for unannounced SoC yet, getting way ahead, for example:
Hawi: https://lore.kernel.org/all/20260330-clk-hawi-v1-0-c2a663e1d35b@oss.qualcomm.com/
Maili: https://lore.kernel.org/all/20260522-maili-pinctrl-v1-0-0a6636f5c277@oss.qualcomm.com/
(I don't know which models are these, what I know is they are not yet announced)
And this list above does not include upstreaming of many other models from different segments.
People really missed how big transformation Qualcomm did in upstream Linux kernel involvement.
https://lore.kernel.org/all/2509536d-cdec-448d-bf20-80d2b3d6728a@kernel.org/
Qualcomm and Linaro were upstreaming before significant amount of code to the Linux kernel for supporting their SoCs , but around 2021-2022 things changed significantly. Just to recap major milestones of:
2022 November: One day after public announcement of new Snapdragon 8 Gen 2 flagship SoC (SM8550), Qualcomm Landing Team in Linaro posted basic support for it:
https://lore.kernel.org/all/20221116103146.2556846-1-abel.vesa@linaro.org/
2023 October: One day after public announcement of next flagship Snapdragon 8 Gen 3 (SM8650), same team posts almost full (not basic!) support for it:
https://lore.kernel.org/all/20231025-topic-sm8650-upstream-dt-v1-0-a821712af62f@linaro.org/
2024 October: One day after public announcement of next flagship Snapdragon 8 Elite (SM8750), Linaro and Qualcomm team posts comprehensive support for it:
https://lore.kernel.org/all/20241021232114.2636083-1-quic_molvera@quicinc.com/
2025 September: Same day of public announcement of Snapdragon 8 Elite Gen 5 (Kaanapali), Qualcomm posts comprehensive support for it:
https://lore.kernel.org/all/20250924-knp-dts-v1-0-3fdbc4b9e1b1@oss.qualcomm.com/
Now things changed:
2026 March and from now on: Qualcomm posts patches for unannounced SoC yet, getting way ahead, for example:
Hawi: https://lore.kernel.org/all/20260330-clk-hawi-v1-0-c2a663e1d35b@oss.qualcomm.com/
Maili: https://lore.kernel.org/all/20260522-maili-pinctrl-v1-0-0a6636f5c277@oss.qualcomm.com/
(I don't know which models are these, what I know is they are not yet announced)
And this list above does not include upstreaming of many other models from different segments.
People really missed how big transformation Qualcomm did in upstream Linux kernel involvement.
6
28
46
Krzysztof Kozlowski
repeated
repeated
Oleksandr Natalenko, MSE 
oleksandr@natalenko.name
their real worry is that the Ukrainians will find a way to improve the Patriot and then produce them at scale faster and for much less money than what the existing production lines in the U.S. could do
Yes, read this again.
2
5
2
Krzysztof Kozlowski
krzk
Edited 18 days ago
Linux kernel Devicetree sources:
With my recent patches entire ARM, arm64 (except Broadcom Stingray and Apple) and RISC-V DTS files pass the dt-check-style linter, in default relaxed mode, so any new DTS is expected to not introduce new warnings.
IOW, in your contributions be sure that new DTS is dt-check-style warning-free.
I am working on fixing false positives for the strict mode and have some successes, but that is not yet ready.
With my recent patches entire ARM, arm64 (except Broadcom Stingray and Apple) and RISC-V DTS files pass the dt-check-style linter, in default relaxed mode, so any new DTS is expected to not introduce new warnings.
IOW, in your contributions be sure that new DTS is dt-check-style warning-free.
I am working on fixing false positives for the strict mode and have some successes, but that is not yet ready.
0
12
20
Krzysztof Kozlowski
repeated
repeated
Geert Uytterhoeven
geert@society.oftrolls.comLinux needs more maintainers. Myself must be overloaded, and heading for a burn-out:
$ git log --oneline MAINTAINERS | grep -i myself | head -3
51f449308506269e MAINTAINERS: make myself the maintainer of the Qualcomm QCE driver
12933e2bc5e07e15 MAINTAINERS: dmaengine/ti: Remove myself and add Vignesh as maintainer
4452b868d669fbf6 MAINTAINERS: Add myself as SCD30 maintainer
$ git log --oneline MAINTAINERS | grep -i myself | wc -l
348
2
2
2
Krzysztof Kozlowski
krzk
@pinchartl I did not plan to attend OSSE this year, but FWIW, the topic feels worth discussing, so I would go to your session if I were there :)
0
0
0
Krzysztof Kozlowski
repeated
repeated
LWN.net
lwn@lwn.net[$] Development statistics for the 7.1 kernel
Linus Torvalds released the 7.1 kernel as expected on June 14. This development cycle brought in a lot of new features — and a lot of new developers as well. The time has come for [...]
https://lwn.net/Articles/1077425/ #LWN #Linux #kernel #SUSE #RedHat #ArchLinux #Rust #Git #io_uring
0
1
1
Krzysztof Kozlowski
repeated
repeated
Bartosz Golaszewski
brgl
Edited 2 months ago
This is the first time I'm posting anything here but I figured this may be the right audience.
I've never run into something like this and I don't quite know what to make of it. I'm the author and maintainer of libgpiod. The official git repository is the one at kernel.org[1]. There's also a github mirror[2] as well as a documentation page[3] at readthedocs that I maintain.
I noticed (purely by chance) that there's a new website at libgpiod.com that's been created recently. I have nothing to do with it. It's clearly AI-generated but it redirects to my github. It's a 2 month old domain, anonymized registrar, protected by Cloudflare and NeoProtect and a Swedish host behind that.
Clearly someone went to great lengths to stay anonymous. I'm afraid of falling victim to some new elaborate supply chain attack. What should I do about it (if anything)? Has anyone else experienced something similar?
[1] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
[2] https://github.com/brgl/libgpiod
[3] https://libgpiod.readthedocs.io/
I've never run into something like this and I don't quite know what to make of it. I'm the author and maintainer of libgpiod. The official git repository is the one at kernel.org[1]. There's also a github mirror[2] as well as a documentation page[3] at readthedocs that I maintain.
I noticed (purely by chance) that there's a new website at libgpiod.com that's been created recently. I have nothing to do with it. It's clearly AI-generated but it redirects to my github. It's a 2 month old domain, anonymized registrar, protected by Cloudflare and NeoProtect and a Swedish host behind that.
Clearly someone went to great lengths to stay anonymous. I'm afraid of falling victim to some new elaborate supply chain attack. What should I do about it (if anything)? Has anyone else experienced something similar?
[1] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
[2] https://github.com/brgl/libgpiod
[3] https://libgpiod.readthedocs.io/
31
395
223
Krzysztof Kozlowski
krzk
In a week, I will be presenting on the Open Source Summit India 2026 in Mumbai. I have two talks:
1. Semi-BoF titled "Guide to Becoming a Linux Kernel Maintainer" (https://sched.co/2KNFb) where I would be happy to have bigger discussion. I don't have many slides on that, so please come to the session and participate in the talk.
2. My standard Devicetree speech for beginners (DTS101, https://sched.co/2KNF4).
If you are going to attend OSS India, please come say hi. If you are already a Linux kernel maintainer, I can also sign GPG keys (I need printed `gpg --fingerprint` though!).
1. Semi-BoF titled "Guide to Becoming a Linux Kernel Maintainer" (https://sched.co/2KNFb) where I would be happy to have bigger discussion. I don't have many slides on that, so please come to the session and participate in the talk.
2. My standard Devicetree speech for beginners (DTS101, https://sched.co/2KNF4).
If you are going to attend OSS India, please come say hi. If you are already a Linux kernel maintainer, I can also sign GPG keys (I need printed `gpg --fingerprint` though!).
0
0
3
@monsieuricon I knew making "Reply All" the default button was the right choice! :)
0
0
3
Krzysztof Kozlowski
repeated
repeated
K. Ryabitsev-Prime 🍁
monsieuricon
This one shows just people responding, deliberately not patch submissions (because Greg's and Sasha's stable patchbombs just dwarf everyone).
So, these are the people who are hitting "Reply All", and it's not even the full picture, because it only includes the LKML.
So, these are the people who are hitting "Reply All", and it's not even the full picture, because it only includes the LKML.
1
7
23
Krzysztof Kozlowski
repeated
repeated
Embedded Recipes
embeddedrecipes@fosstodon.orgEmbedded Recipes 2026 has officially kicked off!
It's fantastic to see so many talented engineers and developers gathered in one place to share knowledge, exchange ideas, and push the boundaries of embedded systems. Looking forward to two days of insightful talks and meaningful connections.
0
9
1
Krzysztof Kozlowski
krzk
@jann @kernellogger @ffmancera @vbabka Considering how poor developers are at expressing WHY they are doing that change/commit, I don't have big hopes on them being able to express that something is a fix.
0
0
2
Krzysztof Kozlowski
krzk
@jann There are maintainers who don't fully get Git basics, e.g. rebasing effects or branches (that merging a branch does not rebase anything), so if I was Linus T., I would not give them access to my tree...
Proficiency in Git is as needed as proficiency in English and programming language. And many of us are not proficient in these... which is fine, btw.
Proficiency in Git is as needed as proficiency in English and programming language. And many of us are not proficient in these... which is fine, btw.
0
0
4
@trini Being always suspicious is not necessarily good, don't take grumpy me as an example :), but in principle I agree that AI slop world is difficult for open source maintainers.
And in that particular case, sending a patch with a bunch of AI-generated assembly is moderately easy, but reviewing it by a human is consuming much more effort. That disproportion sucks.
And in that particular case, sending a patch with a bunch of AI-generated assembly is moderately easy, but reviewing it by a human is consuming much more effort. That disproportion sucks.
0
1
3