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

Edited 1 year ago
@T_X Not everyone has some spare money for engineers full time salary in non-profit way... They already have such updated kernels, just on their website, not on kernel.org. Your suggestion would benefit community, but what would be the benefit of this to Canonical?

RE: https://chaos.social/users/T_X/statuses/110847464823963952
2
0
4

Krzysztof Kozlowski

Edited 1 year ago
First Linux Kernel beer in Zurich organized with @Andi was a success - many beers were drunk. :) Stay in touch for more events!
0
0
8

Krzysztof Kozlowski

Edited 1 year ago
@yha sure, we'll make some announcement here for the next meeting and of course we'll send an email. Just your profile looks empty which does not help me to identify your email address or your kernel identity, so drop me a note (my kernel org email is obvious :) )
1
0
0
@Andi Human creativity is endless.
0
0
0

Krzysztof Kozlowski

Edited 1 year ago

Once you see it, you cannot unsee:

+#ifndef MSM_VIDC_EMPTY_BRACE
+#define MSM_VIDC_EMPTY_BRACE {},
+#endif
...
+static const struct of_device_id msm_vidc_dt_match[] = {
+	{.compatible = "..."},
...
+	MSM_VIDC_EMPTY_BRACE
+};

We are back to the past! To year 2000-something to be precise. This reminds me ARM Mali Linux kernel drivers which were using MALI_SUCCESS instead of return 0.

1
0
5

Krzysztof Kozlowski

Anyone around Zurich up for a beer on 3rd of August with me and @andi?

RE: https://social.kernel.org/objects/ddc0aef7-fe3b-493a-8523-af4ad17ee4e0
0
0
1

Krzysztof Kozlowski

Edited 1 year ago
Anyone from Samsung has some inputs on Qualcomm minidump solution? Without any feedback we'll assume Samsung is fine with Qualcomm's choices. Thread:
https://lore.kernel.org/all/0199db00-1b1d-0c63-58ff-03efae02cb21@quicinc.com/

#samsung #samsunglsi #exynos
0
0
2
Just a regular reminder that the war isn't over, civilians are still murdered in their homes by cruise missiles, and war crimes are committed daily by the invasion force occupying the sovereign territory of Ukraine.

Until the 1991 borders are restored, all war criminals are in jail, and reparations are paid off, I will continue to #StandWithUkraine, and so should you.
1
8
28

Krzysztof Kozlowski

Edited 1 year ago
It actually damages the company's public image, because for the Open Source community there are no separate Business Units. We all look at them as one entity.
1
0
1

Krzysztof Kozlowski

Edited 1 year ago
I am getting more and more picky on this... Why? Because it is waste of our resources. Resources of both community and company. If one team learnt the hard way how to format patches and send them to LKML, why the heck other team has to go through the same learning process? Why reviewer has to explain again and again - `git format-patch -v3 -10 && scripts/get_maintainer.pl v3-00* && git send-email v3-00*`?
1
0
1
One could imagine that the team doing contribution, maybe for the first time for them, will ask for review the older, experienced team from other Business Unit. You know, not to make the same mistakes. But no! It cannot! BUs are separate. However Open Source reviewers are not "separate" and unfortunately receive that stuff to review, with the same mistakes as the company did before.
1
0
0

Krzysztof Kozlowski

Oh, the amazing construction of silosed Business Units of big corporations. When interacting with Open Source communities, one team in some Business Unit of that company cannot learn from the past experience of some other team, because they are silosed. Separate. Thus this team makes the same mistakes other teams already did. However Open Source community sees it differently - one company sending contributions with the same mistakes. It is always okay to make a mistake, but making the same mistake again and again, is a bit waste of our time.
1
0
1

Krzysztof Kozlowski

Edited 1 year ago
Trying to sell something on Facebook marketplace: 99% of interested people are scammers. I found a pervert joy in playing with them, requiring rather small effort from my side and ending in some amusement. This one gave up just after two days off wasting his time.
0
0
1

Krzysztof Kozlowski

Edited 1 year ago

Cleanup of inactive maintainer entries is coming :) - docs: maintainer: document expectations of small time maintainers

0
3
8

Krzysztof Kozlowski

Edited 1 year ago
@kernellogger I can add here more - why does the standard workflow (git format-patch && git send-email, or b4) work for all subsystems, but does not for net and requires changing the [PATCH] into [PATCH net-next]? What if every subsystem maintainer asks the same? [PATCH mm], [PATCH samsung-soc], [PATCH iio]! Such pattern in subject is not even visible in `git log --oneline -- PATH`. Checkpatch does not complain, either. What should poor little fellow contributing to Linux kernel do? Learn the tips and tricks for all the maintainers, so 30-50 different rules?
1
1
5

Krzysztof Kozlowski

Edited 1 year ago
@conor Yes, this too. Several cases can be explained with non-obvious requests from the reviewer or just misunderstanding. Therefore I prepared few longer, detailed template answers with comments and instructions. The insult is when such long and explanatory reviewing comment is being ignored...
BTW, I find templates (Quicktext for Thunderbird, macros for mutt) or AI as the only way to stay sane. :)
0
0
3

@kernellogger @gregkh But you know, adding proper sysfs interface takes few more lines of code… and one has to write documentation… and then sysfs is counted as ABI, so one cannot freely change it… and long command lines look so readable, just consider this Android-related stuff added by bootloader for one SoC:

androidboot.verifiedbootstate=orange androidboot.keymaster=1 androidboot.vbmeta.device=PARTUUID=815a78c5-ebb4-48ec-2912-90eeb3f71c48 androidboot.vbmeta.avb_version=1.2 androidboot.vbmeta.device_state=unlocked androidboot.vbmeta.hash_alg=sha256 androidboot.vbmeta.size=12800 androidboot.vbmeta.digest=815a78c5fb66af47291265ab90eeb3f71c48c9af6ad65044a08a5d81e77299a1 androidboot.veritymode=enforcing androidboot.veritymode.managed=yes androidboot.bootdevice=1184000.ufs androidboot.fstab_suffix=default androidboot.boot_devices=soc/1184000.ufs androidboot.serialno=19111140 androidboot.mode=ffbm-00 quite androidboot.baseband=msm msm_drm.dsi_display0=qcom,mdss_dsi_vtdr6130_fhd_plus_cmd:config0:timing0: androidboot.force_normal_boot=1 silent_boot.mode=nonsilent

Isn’t it beautiful?

2
2
3

Krzysztof Kozlowski

Go Beavers! I mean, the true beavers, the greatest ecosystem engineers, which are vital in bringing diversity, richness, and healing degraded landscapes. “Beaver settlements triple in 15 years in Switzerland” https://www.swissinfo.ch/eng/beavers-increase-threefold-in-15-years-in-switzerland/48657934

If you want to learn more, why beavers are important, I recommend Andrew Millison’s: https://youtu.be/43bmtqKDhBE

0
1
3

Krzysztof Kozlowski

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.
0
5
14

Krzysztof Kozlowski

Edited 1 year ago
Is fixing the same issue over and over again, and expecting it to be fixed, also definition of insanity? Or just Groundhog Day? Or Whack-A-Mole game?
https://lore.kernel.org/linux-devicetree/20230711063011.16222-1-krzysztof.kozlowski@linaro.org/T/#u
https://lore.kernel.org/all/20230410175232.22317-1-krzysztof.kozlowski@linaro.org/
1
0
3
Show older