Zack's Kernel News
Struggling To Support USB Type-C
Heikki Krogerus posted a patch to add support for USB's Type-C connector class. As he put it, "The purpose of the USB Type-C connector class is to provide a unified interface for the user space to get the status and basic information about USB Type-C connectors on a system, take control over data role swapping, and, when the port supports USB Power Delivery, also control power role swapping and Alternate Modes."
Heikki's interface went into the sysfs
directory and exported a lot of data about current operational role, current power role, the port VCONN Source, and many other data items. Ports would be named usbc0
, usbc1
, and so on.
Greg Kroah-Hartman offered some comments. After a cursory glance, he liked the patch, but there were a few things that needed to change. They went over some of those technical details together. Other people joined in, and Heikki spun out a few more versions of the patch. Among the issues under discussion were temporary problems like memory leaks. In terms of the overall feature, everyone seemed to be basically in support of it.
The thing about USB Type-C is that it's the new hotness in terms of data exchange and power delivery. Support for it is not optional if Linux wants to retain world domination status. For example, the MacBook Pro relies on USB-C. Among everything else, you can plug the connector in either right side up or upside down, a feature other USB connectors don't have.
At the same time, even though it's indispensable, the developers still have to figure out whether various behaviors should be set as module parameters, boot options, sysfs
files, IOCTLs, system calls, or any number of other possibilities.
It's also necessary, as was pointed out in the discussion, to compensate for deficiencies in manufacturer's firmware. As Heikki put it at one point, "Unfortunately, we cannot assume the firmware to be always correct. Companies love to recycle the firmware. We are going to see products from a company X that should prefer source role, a desktop for example, but still give the OS a device property that says otherwise. The reason for that is most likely because the previous product from that company was some kind of mobile device."
While Greg at one point said, "firmware is 'hard', but it gets really really tiring constantly having to paper over firmware and hardware bugs in the kernel just because we seem to be the ones that are willing to actually fix problems that others cause."
Ultimately, Greg took a closer look at Heikki's patch and discovered some eyebrow-raising constructions, and the deeper he looked, the worse the code appeared to him. Eventually, he told Heikki that the patch needed a lot more work, and that "I'm now going to require that you get other internal Intel developers to sign off on this code before I review it again. You have resources at your disposal that others do not with your internal mailing lists containing senior kernel developers. Use it and don't waste the community's time to do basic code review that they should be doing instead."
So Greg chucked the code back to the mother ship, Intel, for a thorough going-over before it could even enter the sphere of kernel developers again.
Guenter Roeck, who had previously given his "tested-by" thumbs up for this patch, now said to Heikki, "This hurts both your and my reputation, and obviously will make me quite hesitant to add a 'Reviewed-by:' to the next version of the series." But Greg tried to tone things down, saying, "it doesn't bother me at all. I want and need your reviews of those portions that I don't know as well (i.e., the userspace api and functionality.) So don't take it personally; the driver model isn't that easy of a topic to mess with in places. Loads of people get it wrong." And he said he just really wanted those internal Intel reviews. But Heikki still apologized for the quality of the code.
Overall, a harsh debate. But not very far out of step with the sort of criticism that might normally be leveled against a patch submission. However, it's fairly rare for someone like Greg to decide to halt all reviews of a given patch until the corporation of origin does more work on it.
Blocking Hardware Input Events
Pali Rohár posted a patch to support disabling events from any input device connected to the system. Once disabled, a piece of hardware would no longer deliver any events to userspace. Some common hardware that might use this feature would be keyboards, touchpads, and touchscreens.
Nikita Yushchenko liked the patch, but Bastien Nocera thought it might need more thought. He had implemented something similar in userspace to disable touch devices when the screen has been suspended. Among other questions, he asked if Pali's patch might just be better in userspace and not be a kernel feature at all.
David Herrmann also pointed out that if you didn't want events from a device, you should simply not open that device.
Pali replied that doing this in userspace might require making changes to every piece of user software that took input, but Bastien replied that, "There's usually a display manager in between the application and the input device. Whether it's X.org, or a Wayland compositor." And so the input could be trapped at that level, instead of in the kernel.
There was a bit more discussion before the conversation petered out. In general, though, to paraphrase Murphy's Law: Anything that can be done outside the kernel, will be done outside the kernel. There are very few exceptions, especially when there are already existing userspace implementations that are very similar to the proposed kernel feature.
Zack Brown
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.