We're hiring!
*

Kernel 5.12: Working to close the gap

Ariel D'Alessandro avatar

Ariel D'Alessandro
May 04, 2021

Share this post:

While the kernel community has kept an always accelerating pace of development with no slowdown in sight, the release process has reached such maturity that a new release might sound a bit uneventful. But, when we are talking about one of the pieces of software used to fly that helicopter on Mars earlier this year, uneventful is exactly what you want.

In fact, as the resilience of the release process is proven over and over, more and more companies have been able to drop their vendor trees based on decade old Linux versions, and base their work on the bleeding edge technologies available in the latest versions.

At Collabora, we are more than ever dedicated to help vendors achieve this goal by closing the gap between hardware support on vendor trees and the mainline tree. In this release we have expanded that effort with our customary contributions all around the kernel, in particular we have paid attention to the Video4Linux APIs and hardware enablement.

The search for a file system error notification API

One fact of life is that file systems do fail. Detecting errors over a fleet of servers is actually a tricky effort since there is no generic way to monitor different filesystems without peeking at dmesg and filtering through thousands of messages of each machine in the fleet, a process that is both cumbersome and prone to missing messages in high traffic situations. Nevertheless, Gabriel Krisman Bertazi has been on a quest to find the right API to report file system errors in a generic way, but still providing detailed enough information that it can be used by online monitoring recovery tools.

The current approach, which is being discussed on the mailing list, is a push interface based on fanotify, in which monitoring applications register themselves as the recipient of error messages from a specific file system and get notified by the kernel when an error event occurs. Each message carries a generic header indicating that an error occurred but also optionally includes a filesystem specific message with (hopefully) enough debug data that a monitoring tool can figure out what went wrong and recover from it. In the current cycle, the interface is still under discussion to decide what information needs to be provided, but small fixes to watch_queue and fanotify already started to flow into the mainline kernel.

V4L2 Async notifier API improvements

In 2020, Collabora contributed more than 200 patches to the media subsystem. Our main areas of work have been codecs and Image Signal Processors (i.e. Cameras) which resulted in two big milestones for the previous release v5.11: the destaging of the stateless H.264 V4L2 API and the RKISP1 driver.

Big changes are being prepared for v5.13 and v5.14, some of which we've already blogged about, some of which are still under discussion.

For this v5.12 release, a relatively small changeset was merged which improved the V4L2 Async notifier API. This API needed some love, and being a hot summer in Argentina, Ezequiel had plenty API-love to give. As a result, the V4L2 Async notifier API is now consistent, easier to use and more importantly, "harder to get wrong". Hope you are proud, Rusty!

Finally, a nice side-effect of this work is the removal of a legacy V4L2-internal API for clocks. It turned out there was a small number of users, so the conversion to the Common Clock Framework API was quick and easy.

Convert DSI code to use drm_mipi_dsi and drm_panel

Open source is about community, it's about contributing and sharing code, allowing everyone to use, modify and extend the software without having to reinvent the wheel, even if it wasn't completed yet.

This is the case of Collaboran Sebastian Reichel's patchset, which started as an RFC more than a year ago and was finally merged into mainline with release v5.12.

Thanks to omapdrm maintainer Tomi Valkeinen, who brought this up again and completed the upstream, the 84 patches in this series have made omapdrm's DSI code cleaner than ever (1000+ lines of code removed) in favour of becoming a generic drm_panel. It's worth mentioning that "No features were harmed in the hacking of this driver".

CR50 I2C TPM driver

As part of Collabora's efforts to improve the mainline Linux kernel support on Chromebook devices, a new TPM 2.0 driver was added to handle communication with the Google CR50 chip firmware which uses a customized I2C-based protocol. TPM chip support is important for improving user data and device security. Having this driver upstream is a good step forward for various open-source projects besides the kernel, like ChromiumOS and the general development community, as well as end-users.

Continuous maintainership, testing and reviewing

Contributing is not only about sending patches. Reviewing and testing source code, along with discussions and reporting to the kernel community, are important tasks that Collaborans carry on every release and v5.12 is not an exception!

Collabora's Kernel team, which includes some subsystem maintainers, have been contributing to ChromeOS EC platform support, power/supply and reset/shutdown subsystems, Mediatek SoC support and much, much more.

Yet again, KernelCI is showing its benefits. Guillaume Tucker reported and tested Page Fault errors on Tegra platform thanks to a KernelCI automated bisection. Want to know more about KernelCI? Check out our recent blog post!

Below is a full list of contributions made by Collaborans for the 5.12 release, as recorded in the git commit history:

Authored (93):

Alyssa Rosenzweig (1):

André Almeida (2):

Boris Brezillon (1):

Dafna Hirschfeld (3):

Enric Balletbo i Serra (3):

Ezequiel Garcia (26):

Gabriel Krisman Bertazi (1):

Helen Koike (3):

Sebastian Reichel (53):

Maintainer Committed (58):

Enric Balletbo i Serra (7):

Sebastian Reichel (51):

Signed-off-by (31):

Adrian Ratiu (1):

Ezequiel Garcia (1):

Fabien Lahoudere (1):

Sebastian Reichel (28):

On behalf of (31):

Andreas Kemnade (1):

Arthur Demchenkov (4):

Cristian Ciocaltea (1):

Dmitry Osipenko (1):

Duncan Laurie (2):

Hermes Zhang (1):

Jian Dong (1):

Junlin Yang (1):

Laurent Pinchart (1):

Linus Walleij (2):

Pavel Machek (2):

Randy Dunlap (1):

Ricardo Rivera-Matos (2):

Timon Baetz (1):

Tony Lindgren (9):

Zheng Yongjun (1):

Reviewed-by (61):

Boris Brezillon (1):

Emil Velikov (1):

Enric Balletbo i Serra (8):

Gabriel Krisman Bertazi (1):

Helen Koike (13):

Pekka Paalanen (2):

Sebastian Reichel (35):

Acked-by (11):

Alyssa Rosenzweig (1):

Dafna Hirschfeld (1):

Daniel Stone (1):

Enric Balletbo i Serra (4):

Helen Koike (1):

Pekka Paalanen (3):

Tested-by (6):

Adrian Ratiu (1):

Enric Balletbo i Serra (1):

Ezequiel Garcia (1):

Gabriel Krisman Bertazi (1):

Guillaume Tucker (2):

Reported-by (2):

Emil Velikov (1):

Guillaume Tucker (1):

 

Comments (0)


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


 

Search the newsroom

Latest News & Events

Reverse-engineering the Mali G78

20/07/2021

Collabora reverse-engineers Mali G78 instruction set and releases documentation, disassembler, and assembler for its "Valhall" architecture.

Kernel 5.13: Growing team and KernelCI hackfest

08/07/2021

Collabora's team working directly on the Linux kernel is growing. Collaborans continue to expand on their efforts to close the gap between…

A very successful first KernelCI hackfest

21/06/2021

Earlier this month, Collabora took part in the very first KernelCI hackfest, initiated as a joint effort with the Google Chrome OS team.…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2021. All rights reserved. Privacy Notice. Sitemap.

Collabora Limited is registered in England and Wales. Company Registration number: 5513718. Registered office: The Platinum Building, St John's Innovation Park, Cambridge, CB4 0DS, United Kingdom. VAT number: 874 1630 19.