Posts
229
Following
38
Followers
266
Linux Kernel developer and maintainer
#standwithukraine πŸ‡΅πŸ‡± πŸ‡ͺπŸ‡Ί πŸ‡ΊπŸ‡¦ πŸ‡¨πŸ‡­
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social
@kernellogger Yep, I am all in for the bots.
Checkpatch is garbage, but it is the only garbage we have, so till someone writes something better, please use it.
1
0
2
@vbabka Different audience :)
0
0
0

Krzysztof Kozlowski

Edited 1 year ago
Just reviewed a patch with... four comments coming entirely from my templates. No need to write anything, just hit some templates. Two out of these four comments were for not using in-kernel tools for patch submission/testing (checkpatch.pl and get_maintainer.pl). Eh. :(
2
0
1
@marcan tbh I find this and related posts quite toxic. The IOMMU maintainers are nice guys (one of them is my team colleague) and they don't deserve to have people reading your posts getting the impression that their subsystem is crap.

In the thread you mention doing some unusual (or maybe first time) scenario with it. It's completely normal to encounter bugs in such situations and simply fix them along the way, no need to gloat about it.
2
4
25

Krzysztof Kozlowski

I announced it before on social.kernel.org, mailing lists and finally in the Linux kernel (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25223cba5aa9a536392933782d4a7df71d9093b). So one more time, same announcement:
None of the Samsung and Samsung Foundry platforms can bring any new `dtbs_check W=1` warning.

Contributor can easily test it, so sending code which introduces such warnings is considered close to sending code which does not compile. Fast step to get your maintainer grumpy.
0
1
6

Krzysztof Kozlowski

Nice follow-up of Monday's Plumber's talk - Powering up β€œdiscoverable bus-attached” devices on DT-based platforms - BoF session with the same title:
https://lpc.events/event/17/contributions/1654/
It seems @abelvesa and Bartosz have now a acceptable solution to implement.
0
0
2

@linuxplumbersconf Youtube Live Stream URLs are now available on the Schedule Overview page (https://lpc.events/event/17/timetable/#all).

Find the track you want and click the paperclip on the upper right corner to bring up the Live Stream Link

2
14
2
To clarify: most likely the property is innocent here. Its account got either hacked or booking.com systems allow such hacking and fradulent sending messages to customers.

Booking.com doesn't see any problem...
0
0
1

Krzysztof Kozlowski

Edited 1 year ago
Some weeks ago people got scammed on Booking.com with "confirmation of payment method" or whatever they called it. Booking.com systems allowed scammers to send to customers messages about need to pay again. Second time. Booking.com denies.

So here it is: Booking.com still is not secure and scammers are active. Message I just got:
1
0
2
Edited 1 year ago

A talk for fresh Kernel Maintainers and anyone looking to optimize their workflow @linuxplumbersconf with @krzk
1. Get improvements to email workflow: b4, useful simple hooks for verifying commits (because checkpatch is not enough).
2. Get yourself in linux-next and get tested by community Continuous Integration/Testing.
3. Add yourself to kernel.org keyring, sign your tags and pushes (for transparency log).
4. Dump the mailing lists: use lei and lore
https://lpc.events/event/17/contributions/1498/

0
7
2
@geert @kernellogger @corbet @monsieuricon I believe choosing manually which list to CC (e.g. to CC LKML or not) is not the way the community should work. It might work for you, but such choice should not be in general task for a human. Scripts should make this decision for you.

This means that, if anyone has to or wants to trim or extend the output of scripts/get_maintainers.pl more than once per month, then the script is doing poor or insufficient job.

P.S. Occasional adjustment of get_maintainers.pl is reasonable, but not on regular basis.
0
0
0
Lads and gals,

Linux'n'Beer CH is back for version 2. We're meeting in Zurich on Wednesday, the 8th of November. If you're in Switzerland, come by, or pass this on to someone who might be interested.

We're set to meet at 6:30 PM at the Burgermeister Kaserne[*].

@krzk and I will be there!

Cheers!

[*] https://maps.app.goo.gl/VsZ4wRjzvewpowK19
0
2
2

Linaro successfully enables upstream Linux support for the Qualcomm Snapdragon 8 Gen 3 Mobile Platform - the latest addition to the Snapdragon family.
Learn more about:
- Effortless upstream Linux integration
- Powerful performance optimization
- Running AOSP with Mainline
- Continued collaboration
Read the Blog Post Here https://www.linaro.org/blog/upstream-linux-support-now-available-for-the-the-qualcomm-snapdragon-8-gen-3-mobile-platform/
"

0
8
2

Krzysztof Kozlowski

If Samsung Foundry designed a SoC for customer, re-using most of components/IP blocks from Samsung SoCs, is it still a Samsung SoC or not? Which one is the main, common part?
1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial, and many IP blocks, which constitute 95% of Devicetree bindings and drivers. IOW, all these common Samsung SoCs parts.
2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.

https://lore.kernel.org/all/48e1c0bd-9518-4927-b490-f3206256bbd4@lpnu.ua/
0
1
4

Krzysztof Kozlowski

Finally, after moving to new home, I have time to reorganize my board farm. I was thinking about big rack cabinet, but changed my mind. I want art. Art on the wall.
1
0
7
@monsieuricon @Di4na @adamw @bars @corbet @marcan hmm, @monsieuricon, no need to be sorry. For receiving such toxic answer? The toxic complaining about toxic? Awesome.
0
0
1
@marcan @bars One of the worst things about working in the kernel β€” one of the most toxic parts β€” is the constant stream of nastiness toward our community that comes from outside.

The kernel community is far from perfect; we have a lot of problems and we have been actively working for years (decades) to improve on them.

We are, nonetheless, a project that manages to incorporate nearly 100,000 commits per year, from over 5,000 developers, into a single code base while maintaining a level of quality that β€” while also certainly in need of improvement β€” is good enough for deployment into billions of devices.

As for the use of email...email is painful and broken, but we have found nothing better that will work at the scale we need. See https://lwn.net/Articles/702177/ from a few years back. For all its faults, email is distributed, non-proprietary, scriptable, and gives everybody the freedom to choose their tools; it is a highly inclusive solution in a way that proprietary web forges (for example) are not. Someday we'll find something better and move on with a cry of joy, but that day has not come.

Rather than crapping on the kernel community from afar, why not work with us to try to make things better?
7
18
54

K. Ryabitsev 🍁

I put together a mailing list etiquette page, in case it's useful for newbie posters.

https://subspace.kernel.org/etiquette.html
5
32
34
@marcan @broonie @janne That's a way to solve your use case. Might not get pass upstream review, though. DTS should represent real hardware and you created there a virtual regulator. What's more, do your devices have a SDZ supply? Probably not, so also not a true hardware representation. IOW, this is a work-around for the limitations of current OS implementation, so wearing DT maintainer hat: does not looks upstreamable.
1
0
0
@janne @broonie @marcan As Janne points, reset controller framework solves this problem ("Shared resets behave similarly to clocks in the kernel clock framework. They provide reference counted deassertion..."), but, now wearing DT maintainer hat, "resets" property points to a reset controller not to a GPIO. It is something else than a reset-gpio. Representing reset-gpio as a reset controller would be an overkill and a workaround for limitations of a specific OS implementation. Thus it would not make me happy as a DT maintainer...

As far as Linux kernel is concerned, I was thinking of stuffing this feature into the GPIO lib: https://lore.kernel.org/alsa-devel/84f9f1c4-0627-4986-8160-b4ab99469b81@linaro.org/
1
0
1
Show older