@thibaultmol @kernellogger @tuxedocomputers " this license allows them to prevent from someone else" - this is exactly something they should not do. We all know open-source compliance releases have poor quality and we do not have problems with that. That's life. But what they did is:
1. Release poor quality code.
2. Restrict community rights of improving it and bringing upstream.
That's a big no-go, big NAK for Tuxedo. Interesting twist, how one can release something open-source but not in open-source spirit.

@kernellogger @tuxedocomputers I wonder what is actually worse for customers: crappy driver release from vendors just for open-source compliance or this pseudo-open-source-move from Tuxedo which effectively blocks any community from upstreaming this code.

Let's recap what Tuxedo said:
> We do not plan to relicense the tuxedo-drivers project directly as we want to keep control of the upstream pacing,

This is absolutely terrible move, restricting community and customers from working upstream. Kind of what proprietary company would like to do... Bleh, just choose other laptops.

TIL: @tuxedocomputers released #Linux #kernel drivers for their machines under the #GPLv3, which makes it impossible for competitors and distros to ship them pre-compiled, as that license is incompatible with the #LinuxKernel's #GPLv2 only license.

They did this purposely, allegedly to "keep control of the upstream pacing" – and want to re-license the code while upstreaming.

https://github.com/tuxedocomputers/tuxedo-keyboard/issues/61

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/137

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers#regarding-upstreaming-of-tuxedo-drivers

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers#regarding-upstreaming-of-tuxedo-drivers

@tusooa Heh, you're trying to convince a "Russian identified person" in one of the senior positions in the Linux Foundation that the Linux Foundation is being unfair towards "Russian identified people." It's pretty hilarious.

I'm not a lawyer and I don't speak for the LF, so I won't give you any kind of "official comment." But here's my view of it.

The people removed from maintainer positions were identified as employed by companies on the US and EU sanctions list. These companies are directly involved in the Russian military complex and therefore are directly complicit in war crimes being committed daily in Ukraine. If these maintainers want to think that they are "just techies helping improve the Linux kernel," or that "they are outside of politics," then they are fucking wrong. If they work for companies that develop weaponry or logistics used by the Russian military, they are complicit in Russia's war crimes, and I hold them responsible at a very personal level -- and that's my official comment on the situation.

@as400 It's protected very well. Just fork it. Or review commits. Or revert them. It's all open. There is no owner (except copyright owners but that does not matter here). You can do with it whatever you wish, as long as you keep it still open (and few other things enforced by GPL v2).

@pdp7 @ptesarik Yeah, I like that idea and for many it would be considered neutral or more neutral place. It won't silence all "neutrality" voices, though. No matter how much you wish, you cannot escape politics when dealing with known, big organization.

@ptesarik Countries are political concepts, so every country where you move the organization will impose some sort of politics on that organization. Unless you propose moving to Principality of Sealand? :)
Joking aside, Linux Foundation is nowadays business with very big business behind, so change of residency might not change much.

RE: https://fosstodon.org/@ptesarik/113355467229724671

I guess many are watching interesting email thread now. :)
One-time posters, language typo fixers and devs of architecture from a country far away from GMT. And even certain compression library is brought as an argument, while disclosing private emails and using quite aggressive tone.

Heh. The lady doth protest too much, methinks.

I know now which emails will trigger careful patch review, suspecting foreign country involvement. :)

Above of course does not cover known individuals from that thread. I feel sympathetic with Nikita, whose patches I was reviewing over last years, and who should not be put in the same basket with some companies.

3rd Zurich Linux'n'Beer CH meetup will take place on 16th of October, 6:30 PM in Rheinfelder Bierhalle in Zurich. You are welcome to come!
Thanks @Andi for putting this together and booking up the place for us.

@ljs @kdave @axboe @kernellogger @vbabka @vmiheer

Oh the irony on poor Kent:
"Really, as long as you think it's ok to commit patches without CCing the mailing
list _or_ the maintainer, then fuck you."
https://lore.kernel.org/all/20150831195305.GA2822@kmo-pixel/

Damn archives, they should be wiped after 2 years max. :)

Russia kidnaps Ukrainian children, changes their identities and their names. The Polish foreign minister asks: How does that differ from the Nazis who kidnapped Russian and Polish children for the same purpose?

https://www.threads.net/@polandmfa/post/DAVqCpRug4B?xmt=AQGzYBrGsY48nUagk_qkrZv0VT6GBuaYrDDX9FnO5XKjhA

Bartosz Golaszewski from Linaro describing new Power Sequencing subsystem in Linux kernel.
Linux Plumbers Conference 2024 #LinuxPlumbers2024 #lpc2024 #linux
https://lpc.events/event/18/contributions/1908/

@geert try to enter to neighboring VIC (the same underground station). Serious guy with a machine gun welcomes you on the entrance.

Manivannan Sadhasivam leading discussion on PCI Endpoint open items: virtio, QEMU and more. Linux Plumbers Conference 2024 #LinuxPlumbers2024 #lpc2024 #linux
https://lpc.events/event/18/contributions/1683/

@ljs Let's start with grabbing beers and we figure out paying later.
P.S. Is that an invitation for a date?

The Linux Plumbers Conference is just in three days and I am looking forward to it. I see plenty of interesting topics, so the conference looks promising. If Devicetree is something of interest for you, please come visit "Devicetree Birds of Feather" session on Friday morning:
https://lpc.events/event/18/contributions/1783/

P.S. If you want to grab a beer or chat, find me in the halls or get in touch via email/fedi. I won't be attending OSSE, though. Only Plumbers.

I’m happy to announce the Amlogic ARM64 Device Tree is now fully documented in linux-next, ready for v6.12!

Since the beginning of Device Tree on Linux, we documented how it should be written so drivers could know what to expect, it’s called “bindings”, it’s a sort of “contract” between Device Tree and drivers.

But those were written in human readable open text format, without any automated way to verify Device Tree files. There were numerous attempts, but ultimately Rob Herring leveraged JSON Schema [1] into “dtschema” [2] leading to this patch serie https://lore.kernel.org/all/20181005165848.3474-1-robh@kernel.org/.

Thus “dtschema” made it possible to write bindings in YAML and the developed scripts would convert Device Tree in YAML and run a validation with JSON Schema validation. This was merged in end of 2018 then conversion of the text files in YAML files started.

For reference, there were 3278 text bindings in Linux 4.20 git tree, in today’s Linux next for v6.12 only 1250 text files remains but there’s 4345 yaml files now! In addition to the transition to yaml bindings, new platforms were introduced using the new format.

Around one year ago, I upstreamed support for the Snapdragon 8 Gen 3, and it was fully documented from day 1, and most of the changes was yaml bindings change since the SoC was mainly an upgrade from the Snapdragon 8 Gen 2 I helped upstream 2 years ago.

Let’s go back to Amlogic, were I started converting the text file to yaml bindings in August 2019 (see [3]), and finally ended the transition early this month with the patch [4]. This makes the Amlogic ARM64 Device Trees join fully documented along other platforms like Samsung Exynos

If you want to know more about Device Tree validation, you can look at my @LinaroLtd colleague @krzk talk he did in this year's #EOSS in Seattle https://sched.co/1aBEf!

Now the links:
[1] https://json-schema.org/
[2] https://github.com/devicetree-org/dt-schema
[3] https://lore.kernel.org/all/20190801135644.12843-1-narmstrong@baylibre.com/
[4] https://lore.kernel.org/all/20240905-topic-amlogic-upstream-gxlx-drop-iio-compat-v2-1-7a690eb95bc2@linaro.org/
Thanks for reading !

U-Boot on Qualcomm Snapdragon platforms - great work, @calebccff !
https://www.linaro.org/blog/initial-u-boot-release-for-qualcomm-platforms/

@calebccff, Are these releases already using upstream/Linux kernel DTS? Looking at your qcom_defconfig, it seems answer is yes (OF_UPSTREAM)?

@kernellogger The problem is that Qualcomm ships devices with some weird ACPI tables which Linux simply cannot use. I don't know the details good enough to explain more. Maybe it would require rewriting several drivers to work with such Qcom-ACPI-variant.

RE: https://fosstodon.org/@kernellogger/112874114752280325

@mripard Nothing, but the topic shifted towards why usage of such laptops is non-trivial in the beginning.

RE: https://fosstodon.org/@mripard/112874339733019220