Posts
268
Following
39
Followers
287
Linux Kernel developer and maintainer
#standwithukraine πŸ‡΅πŸ‡± πŸ‡ͺπŸ‡Ί πŸ‡ΊπŸ‡¦ πŸ‡¨πŸ‡­
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social

Krzysztof Kozlowski

Hey @linuxfoundation
Do you plan to upload more photos of EOSS 2023? I see pictures from only the first two days of EOSS, not even complete two days... Other days are not uploaded at all. As you can see in the link below, count stays at 150 pictures is since last Thursday:
https://www.flickr.com/photos/linuxfoundation/albums/72177720308904909/page2
#eoss2023 #elce2023 #EmbeddedOSSummit
0
0
2
@shanmukhateja I think the post under link listed what was present in initial submission. The Adreno GPU patches were recently posted here: https://lore.kernel.org/all/20230628-topic-a7xx_drmmsm-v1-0-a7f4496e0c12@linaro.org/
0
0
1

Krzysztof Kozlowski

Edited 2 years ago
10% of commits in Linux kernel v6.4 came from Linaro engineers. It is a nice result for such a small group of kernel engineers.
https://www.linaro.org/blog/linaro-contributions-to-the-6-4-linux-kernel-release/
0
1
8

Krzysztof Kozlowski

Edited 2 years ago
It was great to see at the EOSS 2023 commitments from some ARM64 SoC manufacturers to upstreaming their SoCs. It was visible in the conference talks but also I got such clear vibes during the talks behind the scenes.
What was a bit missing is a story of Qualcomm which recently is heavily visible upstream - both directly and through the Qualcomm Landing Team in Linaro. November last year Qualcomm released its newest, shiniest mobile SoC: the Snapdragon 8 Gen 2 (SM8550).
And guess what happened? The next day you could find all the Linux kernel support for this new SoC on the mailing list. The newest SoC was released with upstream support at the same time. There is also story from @superna9999: https://www.linaro.org/blog/upstream-linux-support-now-available-for-the-the-qualcomm-snapdragon-8-gen-2-mobile-platform/
#eoss2023 #elce2023 #EmbeddedOSSummit
1
15
39
@minipli @gregkh @kernellogger Timelines indeed sometimes do not align. Consider Ubuntu 18.04 (Bionic) which was using v4.15 kernel because of the timeline and Canonical was basically doing LTS on their own for four years. But timing cannot justify distro/vendor staying on chosen kernel for 4 years, instead of going to next LTS. It's distro's or vendor's deliberate choice - they don't want to update the kernel in released distro version even once per few years. And that choice is here being challenged.
1
0
1

Krzysztof Kozlowski

Edited 2 years ago
@kernellogger Been there. Request to backport few KVM patches for new AMD processors to distro v4.15 kernel resulted in 500-big patch bomb... and I was only half way. Then we gave up and managed to convince customer that it's not a feasible solution.
1
0
6

Krzysztof Kozlowski

Edited 2 years ago
Room full of people - I certainly didn't expect such big audience. #eoss2023 #elce2023 #EmbeddedOSSummit
1
0
7

Krzysztof Kozlowski

Edited 2 years ago
@kernellogger @mupuf the forges are not the answer. We already have tools which report such failures (LKP/kernel test robot), so either the tree was not on kernel.org (thus not covered by LKP by default) or reported warning was ignored.
What we maybe miss is a tool or part of workflow, which will check for how long patch was in next, before sending to Linus. And loudly complaining if it's less than two weeks.
1
0
0

Krzysztof Kozlowski

Edited 2 years ago
@pdp7 not bad shot. Looks like I'm swallowing something, maybe a comment about non-tested bindings :)
1
0
3
@monsieuricon xkcd nicely pointed out silliness of usual password approaches - difficult for us to remember, easy for machines to break: https://xkcd.com/936
0
0
0

Krzysztof Kozlowski

Updating my CV, collecting references, debt register extract, salary details and writing motivation letter. People do crazy stuff to get a nice apartment in Switzerland.
1
0
1
I would also dare to add β‚Ώ (BTC) to above equations for greater impact. Let's think big! :)
0
0
2

Krzysztof Kozlowski

I love it. And think how many other equations and laws of physics can be improved with adding AI. Ohm's law? Dude, please, I = (V + AI) / R. Newton's second law? Easy peasy, F = m * a * AI. Maxwell equations - don't get me even started...
2
0
3

Krzysztof Kozlowski

Edited 2 years ago
@conor no, it was sent only to me, not to public lists, for some reason. And I don't know the license now. Is it GPL?
The code looks like a very good template, with comments what has to be added and checked to match real DTS.
0
0
0

Krzysztof Kozlowski

> [2]: Snippet created with the assisstance of GPT-4

So it began...

That was quite nice Devicetree source snippet. Can be entirely incorrect though, just looks good.
1
0
2

Krzysztof Kozlowski

Some useful commands for daily usage of DT schema helpful in efficient checking of the DTS files:
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
0
4
5
@sj Unfortunately people in general: don't run checkpatch, don't read Submitting Patches doc, don't read other relevant docs, don't build test on many setups, don't test patches (in case of DT bindings). Sure, I can add one more doc for them to ignore :)
0
0
2
@ljs @conor That's a good habit, I have the same, but we still can forget it from time to time. The point is not to be offended when someone tells me to compile the code or to run checkpatch.pl.
1
0
1
@conor Indeed. I refurbished a bit my templates and added more personal-like-phrases. Maybe I need to work on them a bit more... But I am also not a native English speaker, so I don't know how to exactly write a really nice message which will be kind but not exaggerated, so silly. I bet if I write "Please be so kind and use scripts/checkpatch.pl." there will be a person who will feel mocked by this.
1
0
1
Show older