Posts
195
Following
32
Followers
215
Linux Kernel developer and maintainer
🇵🇱 🇪🇺 🇰🇷 🇮🇱 🇺🇦 🇨🇭
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social

Krzysztof Kozlowski

10 years ago I sent a patch to fix one compatible in one Marvell SoC board:
https://lore.kernel.org/linux-devicetree/1410884282-18041-1-git-send-email-k.kozlowski@samsung.com/
Obvious fix but was never picked up.

In 2021 Sebastian tried to fix it:
https://lore.kernel.org/linux-devicetree/20210412230320.382885-2-sebastian.reichel@collabora.com/

Now in 2023 and 2024, Duje tries the same:
https://lore.kernel.org/linux-devicetree/20240125-brownstone-typo-fix-v2-1-45bc48a0c81c@skole.hr/

Will it succeed?
2
1
8
@Logical_Error No, but I hope someone someday will add it to clang-format for example.
0
0
1

Krzysztof Kozlowski

Linux v6.8-rc1 comes with new document describing coding style for DTS (Devicetree sources):
https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html

This marks the end of many unwritten rules, varying between subsystems and maintainers. At least, like with every coding style document, in theory. :)
2
10
22

Krzysztof Kozlowski

Edited 11 months ago
I was always using git branch --edit-description && git format-patch && git send-email, but now I tried preparing and sending patchset with b4 (b4 prep && b4 send). It works great! It is trivial in use and really solves the workflow. I cannot understand why people still Cc wrong people or are unable to send one patchset properly threaded.

Edit: --edit-cover->--edit-description
3
1
15
@abelvesa Great news!
0
0
1
FYI, Qualcomm Snapdragon X Elite (X1E80100) now boots to shell with today's -next.

More support is already sent on the list for review:
https://lore.kernel.org/all/?q=X1E80100

And here is a public branch with all support currently available on top of -next:
https://git.codelinaro.org/abel.vesa/linux/-/tree/x1e80100-next
2
7
18

Krzysztof Kozlowski

Edited 1 year ago
Tensor is coming to the next Linux kernel: v6.8!
I just applied last patches for Linux kernel bringing support for the Google Tensor GS101 SoC (derivative of Samsung Exynos):
https://lore.kernel.org/linux-samsung-soc/170249498744.308886.17508790332822828341.b4-ty@linaro.org/T/#u

Commits will hit tomorrow's linux-next and probably next week I will send pull request with them to SoC (@arnd@society.oftrolls.com and Olof) for the next merge window. Good job Peter Griffin and @LinaroLtd :)
3
13
39
@partim It's the state of the taste of German beer. Quality is not a problem. The taste is...
0
0
1

I can finally reveal some research I've been involved with over the past year or so.

We (@redford, @mrtick and I) have reverse engineered the PLC code of NEWAG Impuls EMUs. These trains were locking up for arbitrary reasons after being serviced at third-party workshops. The manufacturer argued that this was because of malpractice by these workshops, and that they should be serviced by them instead of third parti
es.

1/4

6
57
2
@hrw It's there since six years (2017)...
1
0
1
@kernellogger What was making me sad with such bisection, that after few hours of bisecting, not fully automated so with my personal (not work!) time spent on this, I send a report or even a fix and the maintainer squashes it with original commit. No credits about my work, no Reported-by, nothing for my few hours of personal time which I could spend on eating skittles.
After few of such cases, I stopped entirely reporting linux-next issues hit on my systems, unless the issue is visible for like two weeks. After two weeks, if my CI is still finding the issue, then there is a chance I will be credited with finding it...
1
0
3
@kernellogger Bisecting should be on or start with linux-next. I don't think we should be sending fixes to Linus' somehow faster. Rather people should learn to work on linux-next.
1
0
0

A reminder about what Muscovy did to us in 1932/33: https://en.wikipedia.org/wiki/Holodomor. Today is the Remembrance Day: https://en.wikipedia.org/wiki/Holodomor_Memorial_Day

0
3
4
@vbabka LWN stats should have a separate praise category for deletions.
0
0
6

Today is the annual day of remembrance for the Holodomor, the Ukrainian famine. 90 years ago Stalin sent activists to confiscate food from Ukrainian peasants. Millions died.
To mark this day, Putin sent dozens of drones to attack Kyiv.
Like Stalin, Putin wants to erase Ukraine.

2
8
2
@cas @monsieuricon I cannot access BIOS on company laptop :) and even if I could I think it's still Lenovo's fault - you don't swap keys in a keyboard after 30 years of having the CTRL at that place :) (Y looks at Z.... anyone uses German keyboards? :) )
1
0
1
@monsieuricon There is a special place in hell for designers who swapped CTRL and Fn... I am staying away from Lenovo, but it is tricky - many companies buy these for employees. :(
1
0
0

Krzysztof Kozlowski

Edited 1 year ago
Looking at Devicetree sources changes (DTS) could give some insight into which ARM64 platforms are the most active. DTS represents the real hardware, thus any new hardware-block for an existing SoC, new SoC or new board, require new DTS changes. It's an approximation, easy to measure and still quite informative. Let's take a look - the most developed ARM64 platforms in the upstream Linux kernel since last LTS (v6.1):

$ git diff --dirstat=changes,1 v6.1..v6.6 -- arch/arm64/boot/dts/ | sort -nr
44.6% arch/arm64/boot/dts/qcom/
12.2% arch/arm64/boot/dts/ti/
10.4% arch/arm64/boot/dts/freescale/
10.1% arch/arm64/boot/dts/rockchip/
5.0% arch/arm64/boot/dts/nvidia/
4.3% arch/arm64/boot/dts/mediatek/
3.9% arch/arm64/boot/dts/renesas/
3.5% arch/arm64/boot/dts/apple/
3.4% (the rest)
2.2% arch/arm64/boot/dts/amlogic/

Almost 45% of all changes to ARM64-related hardware in the upstream kernel were for Qualcomm SoCs and boards. That's quite a stunning number.
0
1
5
When patchwork integration is configured, b4 will now retrieve the CI status of each patch as well.
5
9
34
Show older