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.

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.

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*`?

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.

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.

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.

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

@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?

@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. :)

@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?

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

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.

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/

@cas @samueldr Patch based workflow is not necessarily easy, although there are tools making it easier (like b4 mentioned by @cas), but it is the one which is the easiest for us. Now, I have been sending patches with git send-email for some years and I have sent quite a few (if you read LWN then you know :) ), and I never had single problem with git send-email. Neither with git format-patch. I find them trivial. Now and long time ago.
I have been also working with people complaining a lot about Git, that it is too complicated and too difficult. I would say all of these - Git is too difficult, git send-email is too complicated - is the same complaining as "C is too difficult" or "using shell is too complicated": valid statements for a regular user, but not really for software developer in this domain. When learning something new, it is pretty often difficult and complicated. This is why it is called learning...

@Kirabug But website does not give such awesome abilities to track users, spam with notifications and invade their privacy. This is why it is better in the app. To track you. :)

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

@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/

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/

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

@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.