Krzysztof Kozlowski

@uecker @kernellogger @klausman There was no such question when concerns of removal of the drivers were raised. Complains about dropped drivers did not come with "I wanted to devote my time, but I was rejected". No one was rejected, because no one volunteered to handle all this.

@uecker @kernellogger @klausman Each of these people having "genuine" needs of removed drivers could step up and help. Still can, like it happened with NFC which I left and was about to be removed, if I did not poke David. If these users do not step up, they have no rights to complain, because one cannot expect someone else doing work for free.

@kernellogger @klausman @uecker And the license governing Linux kernel kind of emphasizes this: “This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.” Which also means without warranty of support. We only HOPE it will be useful.

@klausman @kernellogger There is no free lunch, so people who have "genuine need" of particular drivers need to pay with their testing of new kernel releases (LKML does not matter here - no one needs to read it). This applies to individual users or companies using some very old LTS. If they ever tested only their old LTS (imagine v4.4 with stunning 300 stable releases for 6 years of official support!), never moved their kernel for their products to any newer LTS, not even imagining testing newer standard release, what do they expect? That some maintainers will do the work for them for free? Free Software is free as in freedom of usage, not free of the effort. I think many forgot that and assume Linux comes for them for free as in free beer, thus they have no obligations and can be just consumers of it.

@lwn@fedi.lwn.net I love the timeline of initial disclosure to Cline: https://adnanthekhan.com/posts/clinejection/#timeline "January 1st, 2026: GHSA submitted via private vulnerability reporting on github.com/cline/cline. Same day, email sent to security@cline.bot ..." January 8th, 2026: Follow-up email sent ... No response received to my email. January 18th, 2026: Attempted direct message to Cline’s CEO on X with request to review the GHSA containing technical details. No response. February 7th, 2026: Final attempt — new email to security@cline.bot, no response... February 9th, 2026: Public disclosure via blog post." Can we agree that Cline screwed so badly they should never be trusted again as software vendor? Ah, who am I kiddin, that's probably SW workflows managed by AI, so no one cares...

@jann If only there was one tree for entire kernel, where everyone would be merging and managing simultaneously... if only ever someone invented a non-distributed revision control system which would help in achieving that. That distributed thing is also so annoying!

@luis_in_brief@social.coop Aaah, so now I know what was missing in my maintainer's life: "Maintainers will get hands-on learning of security principles, tools like GitHub Copilot and Copilot Autofix" Github Copilot! Microsoft jokes from open-source...

@ASI@fosstodon.org No cóż, ciągle nie wiem gdzie te slajdy wrzucić, więc udostępniam tutaj: https://github.com/krzk/docs/blob/main/speeches-and-conferences/2026/Peculiarities%20of%20Linux%20Kernel%20Development%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20Sesja%20Linuksowa%202026.pdf

Since a year we got some contributions for converting Devicetree bindings from TXT to DT schema as part of some sort mentorship programs (e.g. GSoC). This is great although leads to some misunderstandings in that work, considering mentorships did not ask DT maintainers about some sort of guidance. To clarify:

1. Please convert bindings which have active DTS users. First choose bindings with DTS built by arm64 defconfig, then next choice by arm multi_v7 defconfig. Then any other ARM or different architecture DTS.

2. Be sure dt_binding_check (including yamllint) and checkpatch pass without any warnings. See writing-schema.rst document.

3. Be sure that all DTS files using this binding pass dtbs_check validation. If this means binding needs to be adapted during conversion, mention briefly in commit message changes done comparing to pure TXT->DT schema conversion. Sometimes DTS has to be fixed. Sometimes both - DTS and binding - must be changed, because actual ABI (Linux drivers) is different.

4. Do not send conversions of TXT bindings in staging, because these need to follow standard review process. Bindings in staging are not considered accepted/reviewed DT ABI.

5. Don't ever send output of LLM microslop tools. It's pointless and brings no benefits to the community. Rob already converted all TXT bindings with LLM, so why you doing this again would be beneficial to anyone?

6. Read also Rob's expectations and hints:
https://lore.kernel.org/linux-devicetree/CAL_JsqJp133hGSkja9tabtsE9D7MSA9JErVkmkcy91piHMgfwg@mail.gmail.com/

This is an updated guideline from 2025 https://social.kernel.org/notice/Ai9hYRUKo8suzX3zNY .

New release: neard v0.20, the user-space counterpart of Linux NFC stack

The release includes a few minor fixes.

Source code release:
https://web.git.kernel.org/pub/scm/network/nfc/neard.git/tag/?h=v0.20
https://web.git.kernel.org/pub/scm/network/nfc/neard.git/snapshot/neard-0.20.tar.gz

I should have released it much earlier, though. I think this release thanks to Mark Greer finally dumps Python 2 dependency - last blocker of packaging for Debian. Anyone would like to revive the Debian package?

With v6.5-rc1 merge window, my remaining few fixes for Samsung Exynos SoC dtbs_check compliance were merged. This means that with v6.5-rc1 all ARM and ARM64 Samsung Exynos SoC Devicetree sources (DTS) pass in-kernel Devicetree bindings compliance tests. I can finally enable a builder testing mainline DTS for this:
https://krzk.eu/#/builders/92
https://krzk.eu/#/builders/91
https://github.com/krzk/tools/commit/743f694cfe4d18dd5f92728967aa762edd59c84e

P.S. The ARM64 Exynos DTS was actually compliant since v6.3-rc1, so that part I could have enabled earlier.

Continuing PyTorch / Linux Foundation database of harvested emails and sending advertisements to them - https://social.kernel.org/notice/B3bhz39OUEdNndylVI

Linux Foundation apologized for "internal marketing operations error" and that "Your email address, along with those of other kernel maintainers, was included in a dataset from a third-party data provider that was improperly imported into our marketing systems without consent verification."

No name for 3rd party provider was given, so GDPR cannot follow to that provider, though...

Linux Foundation also stated they were executing a "permanent deletion". That was 5th of March.

However today I got message from other kernel maintainer, who just got spam/advertisement from the PyTorch Foundation. So saga keeps going.

Maybe they removed only my address from the harvested list. :)

@gregkh Not that odd... I imagine random dudes talking:

• I used microslop to find bug in Linux kernel and I will have CVE/security vulnerability credits for my CV!
• oh, amazing, was it difficult?
• I just found them easily in usbip, it looks like easy pick.
• I will do the same!

I, for example, noticed that when Google Summer of Code starts, e.g. application process, there is increased amount of contributions doing the same as GSoC applicants but not being part of GSoC. It's like someone found GSoC page with "easy picks" and then hops on the same bus.

Maybe usbip is the same here.

@uecker @kernellogger @klausman There are no barriers to contribute, no payments needed, except one's time. Plenty of guides, plenty of resources, one just have to devote their time. The entire and only point is here that simple: no one wanted to pay to maintain these drivers and no one wanted to devote enough of their own time to do that (except of course of netdev maintainers who have enough on their plate).

@uecker so we made circle... You repeated earlier thought. There's no shaping by American tech interests in this matter. Just American tech does not pay for these drivers and no one else paid, either. Paid as with money or their time. It's not the American interests who decided to drop these drivers. And it's really not that difficult to maintain all of removed stuff. One doesn't have to be even skilled... I was doing it, e.g. NFC. It requires only one, the most scarce resource: time.

October is coming which means Linux Plumbers Conference 2026 in Prague, where I am running Devicetree Microconference track (6th of Oct). There will be talks about:

- Current progress with OF_UPSTREAM (@superna9999@social.linux.pizza),
- Status of getting DT bindings compliance (me),
- Combining ACPI with Devicetree because the more firmware the merrier (Srinivas Kandagatla),
- Upstreaming your DTS faster than maintainers can review (Amit Kucheria),
- The never-ending saga of hot-pluggable extension boards (Hervé Codina),
- Another never-ending sagas of managing multiple boards with overlays (Doug Anderson, Hans de Goede and Agathe Porte).


Full schedule:
https://lpc.events/event/20/sessions/252/#20261006

Don't hesitate to grab me in the hallway track if you have some questions, e.g. why I still did not review your patch :), or just want to get a selfie with me (yes, it does happen, I am not making it up!). This year I am not attending the co-located ELCE, so only chance to catch up is LPC. See you in Prague!

Some moron is running out of water bodies to rename after his ego. There was a gulf, now a lake. So I guess there is gonna be a river, sea and ocean soon? I'm happily avoiding all technical conferences as a speaker in a country ruled by said moron.

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.

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.

@ASI@fosstodon.org Czy jest gdzieś możliwość wrzucenia slajdów ze swojej prelekcji (PDF)? Zdałem sobie sprawę, że miałem trochę linków i referencji, których uczestnicy nie mają jak wyklikać/odnaleźć.

@uecker@mastodon.social It's easy to make statements, when you do not want to back them with any sort of argument. Just make a statement and put final stop. Product Foo is insecure. Some car manufactured by Baz is not reliable. This argument is unconvincing. I can express that as well...

@gregkh@social.kernel.org @uecker@mastodon.social @Viss@mastodon.social @icing@chaos.social @joshbressers@infosec.exchange @wdormann@infosec.exchange Heh, that's @uecker@mastodon.social style of raising FUD, without actual arguments why it supposed to be unconvincing. Here https://social.kernel.org/notice/B5gj02TzcQaDMcTpc8 supposedly individual (hobbyist) contributors have somehow obstacles from contributing just because some big companies are implementing changes matching their needs. No facts or arguments why it would be more difficult for the hobbyist just statement "makes it more costly for others to contribute". No facts why inability to create such list is unconvincing. It is just "unconvincing". It's easy to discuss like that - object to anything, even to actual arguments, but without providing anything backing up one's statement.

@brgl@social.kernel.org I don't think advertisements on a website for such specific purpose SW would pay the cost of domain, so more likely this prepares for spreading malware and future supply chain attack. Unless I underestimated popularity of libgpiod :)