Kernel development

Kernel release status

The current development kernel is 4.7-rc7, which was released by Linus Torvalds on July 10. "Anyway, there's a couple of regressions still being looked at, but unless anything odd happens, this is going to be the last rc. However, due to my travel schedule, I won't be doing the final 4.7 next weekend, and people will have two weeks to report (and fix) any remaining bugs. Yeah, that's the ticket. My travel schedule isn't screwing anything up, instead think of it as you guys getting a BONUS WEEK! Yay!"

Another edition of the 4.7 regression list was released by Thorsten Leemhuis on July 10. It has ten current regressions, two of which are new.

Stable updates: The 4.6.4 and 4.4.15 stable kernels were released on July 11.

Comments (none posted)

Kernel documentation with Sphinx, part 2: how it works

The kernel's documentation tree is going through a fundamental transition toward the use of Sphinx and reStructuredText for the production of formatted documents. The first article in this series discussed the path the development community took as it made the decision to go with Sphinx. This article, which concludes the series, covers the mechanics of the new documentation system and how to add to it.

From the casual developer's perspective, building the documentation hasn't changed much. In the 4.8 kernel and beyond, the usual "make htmldocs" and "make pdfdocs" commands will invoke both Sphinx to build the documentation written in reStructuredText and the old toolchain to build documentation still in DocBook format. One will need to have Sphinx installed, obviously. For prettier HTML, the Read the Docs Sphinx theme (sphinx_rtd_theme) will be used if available. For PDF output, the rst2pdf package is also needed. All of them are readily available in stable distributions.

The documentation build for Sphinx uses a dedicated Documentation/Makefile.sphinx, with Documentation/conf.py for configuration. The generated files are placed under Documentation/output in format-specific subdirectories. Currently, there is not much documentation that is actually built from reStructuredText, but the graphics documentation as well as documentation about the Sphinx-based system itself will be ready in time for v4.8. Over time, the plan is that all DocBook documents will be converted to reStructuredText, and we can finally say goodbye to DocBook.

From the perspective of the build system, Sphinx is pleasantly simple compared to the DocBook toolchain. It handles dependencies within documents by itself, storing intermediate data in the output directory. This allows the build system to work without knowledge of how the input and output files map to each other.

Writing documentation

Adding new documentation to the Sphinx build can be as simple as following these steps:

1. Add a new reStructuredText file somewhere under Documentation with a .rst extension.
2. Refer to it from the main index file Documentation/index.rst.

For now, converting existing plain-text and DocBook files to reStructuredText is more likely to happen than adding new files altogether. Because the current plain-text files don't follow any markup, they need to be manually converted; happily, by design, plain text is not too far from lightweight markup. We expect that some of the thousands of plain-text files will be converted to reStructuredText over time, but there is no real pressure to do so, and not everything needs to be part of the documentation build.

The DocBook conversion is more interesting. There's a "cheesy conversion script" from Jonathan Corbet in Documentation/sphinx/tmplcvt that uses pandoc with some sed pre- and post-processing. Markus Heiser has been working on some more advanced conversion scripts. The DocBook templates should be converted primarily by their authors or maintainers to ensure they remain sensible and no errors creep in while converting. The conversion is a one-time effort anyway, so after a point, polishing the scripts is wasted effort. (Here's a sample of the results of some of the DocBook files converted using the cheesy script, with no manual editing on top.)

Once converted, the DocBook templates are to be placed alongside other documentation under Documentation instead of in a silo under Documentation/DocBook. That directory, along with the entire DocBook toolchain, is slated to be removed once all the documents therein have been converted. Even developers who couldn't care less about producing pretty documents can benefit from converting the DocBook templates to reStructuredText because grepping and reading reStructuredText is much easier than the angle-bracketed mess that is DocBook.

Eventually we'll need to have more structure than just shoving everything directly in the main index. In particular, the PDF output needs to be split into several documents. This can be done using a configuration option in Documentation/conf.py as more documents are added. For starters, however, keeping things simple seems like the way to go.

Formatted kernel-doc comments

When building documentation using Sphinx, the kernel-doc comments are now treated as reStructuredText. Some hiccups will inevitably follow, as the comments were not written with reStructuredText in mind, but mostly it just works.

The kernel-doc script parses the formatted comments at the high level (function and structure names, parameter and member descriptions, and so on), generates appropriate Sphinx C Domain anchors for them, filters the comments for highlights and cross-references, and otherwise passes the rest through as-is. The filters convert function_name() and references to structure types (using the &struct struct_name convention) to proper C Domain cross-references, and there are other highlights as well.

A dedicated Sphinx directive extension incorporates kernel-doc comments from source files into the document. Internally, the extension invokes kernel-doc to do the job and informs Sphinx about the document dependencies on source files. The extension makes it possible to include kernel-doc comments with any reStructuredText file under Documentation with no special handling or dependency tracking in the makefiles.

For example, to include the documentation for all the functions exported using EXPORT_SYMBOL() from bitmap.c, you'd write the following:

    .. kernel-doc:: lib/bitmap.c
       :export:

To include an overview documentation section from intel_audio.c:

    .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
       :doc: High Definition Audio over HDMI and Display Port

The DOC: title given in the source code acts as an identifier for the section. There are also ways to include documentation for specific functions or types.

Daniel Vetter's contributions enable the kernel-doc extension to feed the source code file and line number of each documentation comment to Sphinx to enhance diagnostic messages on reStructuredText errors. This will come in handy when fixing the hiccups mentioned earlier.

Future work

There has been some talk (and even code from Markus) to convert the kernel-doc script from Perl to Python and perhaps to run it directly in the Sphinx extension. It is not clear, however, whether it's worth converting a homebrew C parser with two decades of field testing from one language to another just for the sake of it. Perhaps a compiler plugin would be a better idea.

As noted earlier, the media documentation in particular needs better syntax for tables. To this end, Markus has written a Sphinx extension to support row and column spans, among other things, in tables. This work, too, looks set to go into 4.8; it is a dependency for converting the media documents.

But, on a positive note, most of the work discussed in this article has been merged. We'll be seeing more documentation patches that convert files to reStructuredText, as well as fixing and improving kernel-doc comments in source. Hopefully the changes will improve the state of the kernel documentation as a whole, and will move us one step closer to the documentation maintainer's vision as expressed during a linux.conf.au talk, "If we do this, we end up with, some years from now, this beautiful, integrated documentation tree, that covers things in a comprehensive way, where you can find what you want, looks pretty when you look at it. It's a nice vision, I hear angels singing when I think about it and so on, it's where I want to go."

[Jani Nikula is employed by Intel to work on Linux graphics, and is also the author of most of the Sphinx work, with contributions from Daniel Vetter and Jonathan Corbet.]

Comments (1 posted)

Tracking resources and capabilities used

There are various types of limits and privileges that administrators can apply to processes or control groups (cgroups) in Linux, but it is sometimes difficult to determine what those values should be—except by trial and error. A patch set from Topi Miettinen targets making that easier by tracking resource and capability usage by processes in order to give users and administrators a starting point to use when setting those values. The idea is that the processes can be run under a normal load and the high-water values (as well as the capabilities used) will be recorded to provide a guide for future, more-restrictive deployments.

The 18-patch series is broken up into three groups: capabilities used (one patch), cgroup limits (three patches), and resource limits (14 patches). Capabilities used are reported in /proc/PID/status, while cgroup maximums are presented in files in the cgroup filesystem. Resource limits (i.e. rlimits), on the other hand, are reported in the /proc/PID/limits file. Those may change since there are programs that parse the files in /proc, so adding more information could potentially alter the user-space interface for the kernel.

As Miettinen says in the cover letter for the patches, much of the information can already be gleaned from various /proc files and using tools like ps, but those methods only give a value at one point in time. In order to be sure that transient spikes are also recorded, so they can be taken into account, the kernel needs to be involved; thus these patches.

But Konstantin Khlebnikov objected to the overall goal:

He also suggested that tracepoints could be used (perhaps in conjunction with SystemTap or other kernel tracing infrastructure), rather than adding high-water recording to the kernel.

But both Miettinen and Austin S. Hemmelgarn disagreed with that analysis. Miettinen noted that there are always risks when setting limits, but that the patches are just meant to help provide some guidance. Hemmelgarn essentially agreed:

Rlimits could be handled similarly, he said. Beyond that, though, there are different types of failure modes for processes that cannot get the resources they need (e.g. can't start a thread or process), which may not manifest as application errors or crashes. In addition, getting the information about the maximum usage from user space will be difficult or impossible, he said. In a follow-up post, he also noted that tracing can't supply any better answers for the upper bound of these values than internal kernel tracking can: "You can't get a perfectly reliable upper bound for any type of resource usage with just black box observations, period."

There were also comments on many of the individual patches. The capabilities-tracking patch simply adds a cap_used bit array to struct task_struct and sets the bit corresponding to a capability whenever that capability is checked (and passes the check). But as Andy Lutomirski pointed out, simply tracking the capabilities used by a process won't work well in the presence of ambient capabilities. If a process runs a program with ambient capabilities, which uses some capabilities beyond what the main process uses, those will be missed in the set of capabilities collected. He suggested tracking capabilities used for an entire process tree or cgroup.

The cgroup patches track values for three specific controllers: the maximum PIDs used in a PID cgroup, maximum memory used in a memory cgroup, and the devices accessed in a device cgroup. The PID cgroup patch uses an atomic variable to track the highest number of PIDs that have been active in the cgroup at any point. It makes that number available in the pids.current_max file. Cgroup maintainer Tejun Heo didn't like the name (he suggested a high_watermark field in the pids.stats file) and was concerned that some of the atomic variable handling that could lead to races.

The patch for the memory cgroup simply presents the existing watermark value in the memory.current_max file. But, as Johannes Weiner noted, that generally won't provide much useful information. The page cache is counted in that watermark and is not reduced in size unless there is memory pressure, "so in all but very few cases the high watermark you are introducing will be pegged to the configured limit".

The last of the cgroup patches keeps a list of devices that are accessed in a device cgroup. That list, which contains the device type (character or block), major and minor numbers, and access type (read, write, or mknod), can be read from the devices.accessed file.

The rlimit patches drew fewer comments in general (or, perhaps, the comments were outweighed by the sheer number of patches). There was some general confusion because Miettinen did not send a copy of the cover letter (or the first rlimit patch that added some infrastructure used by the rest) to everyone who got copies of the individual patches. In addition, the function name used to update the current maximum value, bump_rlimit(), was confusing to some, since it seems to imply that the actual rlimit is being increased (bumped).

There are individual patches to record (and sometimes report) the maximum use of different resources that are tied to rlimits. That includes the number of open files (RLIMIT_NOFILE), CPU usage (RLIMIT_CPU), file sizes created (RLIMIT_FSIZE), number of processes (RLIMIT_NPROC), and so on. There were some complaints about race conditions and using read-copy-update (RCU) incorrectly, along with some suggestions for better comments to make the intent of the code clearer. Aside from the final patch in the series, which Kees Cook pointed out was unneeded, the series as a whole got a fairly warm response.

There is clearly some work to be done, but maximum resource usage tracking seems like a feature that might make its way into the kernel in, say, 4.9 or 4.10 unless some major opposition appears. It will provide users with a way to gauge what their processes are doing so that limits and privileges can be tightened down appropriately. It certainly won't provide all the answers, but may give the starting point that Miettinen is seeking.

Comments (1 posted)

USB charging, part 2: implementation

In the first part of this series we explored the complexities of charging a battery in a portable Linux-driven device from a USB connection, and in particular looked at how the maximum allowed current can be determined. This resulted in five tasks that Linux would need to complete in order to charge batteries in a compliant manner. It is now time to look inside Linux to see how well it achieves these tasks and, as we will find, the answer is "not very well", or at least "not very uniformly". There is some reason for hope on the horizon, however, as a patch set described as providing a "usb charger framework" is under development and should close at least some of the gaps.

The five tasks we identified, and that we will address in order, are:

• find out from the USB PHY what type of cable is attached and report this to the battery charger
• advertise USB gadget configurations with appropriate power demands
• determine which gadget configuration was chosen and report the available power to the battery charger
• adjust current within the given range to maintain suitable voltage
• detect when the power supply is questionable during boot, and limit activation of components until that is resolved

The EXTernal CONnector in your USB PHYsical interface

When a cable is plugged into the B-series USB receptacle on your device, it is the task for the PHY, and the Linux driver for the PHY, to measure voltage levels and resistances to determine what sort of cable has been plugged in. The PHY driver must then tell the USB core code if it should start negotiations as a USB host or a USB gadget; it must also report the cable type to whatever driver is responsible for charging the battery. How these reports are sent could best be described as ad hoc, though a less kind commentator might say it is a total mess. There are two approaches that are fairly generic: one legacy and one newer. And then there are non-generic approaches like musb_mailbox().

The legacy approach requires that the charger call usb_register_notifier(), as eight charger drivers do. The notifier mechanism allows a pointer to an arbitrary data structure to be passed along with the notification. Some PHY drivers pass a pointer to an integer giving the available current in mA, some pass a pointer to the usb_gadget structure, which doesn't contain any information about available current, and some just pass NULL. Even without any data passed, the notification can be useful since the charger driver may be able to query the PHY directly, and can almost certainly turn the charging circuit on or off depending on whether there is any voltage. So, while this is not a coherent interface, it does provide some value.

The newer approach is to use "extcon", which is a driver class for monitoring external connectors, whether for audio jacks, video ports, USB receptacles, or anything else. An extcon device maintains a record of what type of cable (or what collection of cables) is currently plugged in and will generate a notification whenever a cable is plugged or unplugged. Other drivers can register interest in a particular cable type being attached to a particular connector or in a particular cable type being attached to any connector. Strangely, there is no way to register interest in a particular connector regardless of cable type.

Among the cable types known to extcon are:

        /* USB external connector */
        #define EXTCON_USB		1
        #define EXTCON_USB_HOST		2

        /* Charging external connector */
        #define EXTCON_CHG_USB_SDP	5	/* Standard Downstream Port */
        #define EXTCON_CHG_USB_DCP	6	/* Dedicated Charging Port */
        #define EXTCON_CHG_USB_CDP	7	/* Charging Downstream Port */
        #define EXTCON_CHG_USB_ACA	8	/* Accessory Charger Adapter */
        #define EXTCON_CHG_USB_FAST	9
        #define EXTCON_CHG_USB_SLOW	10

Unfortunately, there is no documentation beyond what is given above and the implicit documentation of how various drivers use the cable types. EXTCON_CHG_USB_SLOW seems to suggest a cable that can provide 500mA. EXTCON_CHG_USB_FAST is used by axp288_charger.c to indicate a charger capable of 2000mA. The relationship between the EXTCON_USB* and EXTCON_CHG_USB_* cable types seems confused.

A possible interpretation is that the EXTCON_USB* cable types indicate if a cable can carry data, either in gadget or host mode, independent of any charging capabilities. The EXTCON_CHG_USB_* types would then indicate the power that can be expected of the cable, independent of any data. Thus a single USB cable might be reported as both a data cable and a power cable, which certainly makes it easier for any client that is only interested in one or the other. A few drivers, such as extcon-max14577.c, report a standard downstream port as both EXTCON_USB and EXTCON_CHG_USB_SDP, which supports this hypothesis, but, since they don't report EXTCON_USB together with EXTCON_CHG_USB_CDP or EXTCON_USB_HOST together with EXTCON_CHG_USB_ACA, this is not an interpretation that can safely be relied upon.

Even though these cable definitions do not seem to be implemented consistently, there is infrastructure available that carries all the information we need. Updating some drivers to use existing infrastructure properly is a trivial task compared to trying to work out what infrastructure is needed to allow the drivers to communicate at all.

And, indeed, drivers would need to be updated. There are precisely two charger drivers that listen for extcon notifications. Quite a few USB drivers listen for EXTCON_USB or EXTCON_USB_HOST so they can configure as a gadget or a host, but the only chargers that do are axp288_charger.c and charger_manager.c.

It is from axp288_charger.c that we can discover the one interpretation of EXTCON_CHG_USB_FAST and EXTCON_CHG_USB_SLOW that was mentioned above, but otherwise it isn't particularly helpful as the code doesn't appear to work. The API for extcon was updated last year and when axp288_charger.c was adjusted to match, the only improvement provided was the removal of compiler errors.

charger_manager.c is a software battery-charge monitor that checks the temperature and voltage on a battery and decides when to try to charge it. It can be configured to expect a list of different cable types along with the current to try to use from each cable. This seems to be the closest thing to a working charger manager that uses an extcon device to be notified of cables.

This poor state of the code doesn't necessarily mean that no Linux device charges properly over USB. The USB PHY and the charging controller in a particular device are often from the same manufacturer and even in the same integrated circuit. In these cases, a driver for one half can have intimate knowledge of the other half and thus achieve reasonable results. An example of such a driver is isp1704_charger.c. This driver is ostensibly a driver for battery charging, but it reaches over into the territory of the PHY driver to directly access "ULPI" registers, which is the USB Low Pin Interface. It uses usb_register_notifier() to find out when something changes, then pokes around on its own to see the specifics of the change.

Where I have mentioned "charger drivers" above I have been a little loose with terminology. Linux doesn't have a "battery charger" class for drivers, it only has a "power_supply" class. The unifying feature of this class is that it allows drivers to report various details of a power source, such as voltage (both present and maximum), current, capacity (for batteries), technology used, etc. Since the most important aspect of charging a battery is managing the source of power, and possibly turning it off when temperature or voltage monitors indicate a problem, it is quite reasonable for battery charging to be managed by power supply devices, and this is how it happens in Linux.

One of the properties a power supply can present is the supply type, and until 2010 it was one of battery, UPS, mains, or USB. At that time USB DCP, USB CDP and USB ACA were added. More recently, some more types specific to USB 3.0 have been added. This means we have two subsystems vying for ownership of the USB-charger-type concept. Is the type of charger plugged into a USB receptacle a property of the power supply, or a property of the cable (or external connection)? Or both? The "technology" property mentioned previously is currently used only for batteries, allowing NiMH, LION, NiCd, etc. If the power supply needs to know about the attached charger, rather than just being told the available current, should the various types be treated in the same way as battery technology? While it is doubtless possible to argue for various different options, it is hard to argue against having unified coherent usage and that is certainly missing.

The various USB power supply subtypes are currently used in three different drivers. The axp288_charger.c that we have already met uses some of the values, but just uses them internally. It doesn't use them to report the type of the power supply (that is always POWER_SUPPLY_TYPE_USB) but stores them in a data structure called cable. It finds out the type of charger by registering with an extcon device, but as already noted that doesn't work correctly. So that driver isn't good example to learn from.

Then there is a gpio-charger.c, which is designed to work with power-supply hardware with limited monitoring options: a GPIO input can detect if the charger is active, but that is all. In order to provide the other properties that a power supply should have, gpio-charger.c reads some configuration information from a device-tree description of the hardware. It allows that description to declare that the power supply is some particular subtype of USB. But this type is not changed dynamically, so it could only be meaningful for a USB charger that was hardwired to the device, which seems a little pointless.

Finally there is the isp1704_charger.c. As mentioned, it is a power-supply driver that pokes in the USB registers to determine the power-supply type, which is a bit of a layering violation. So it seems that no power-supply driver in mainline actually uses the USB power-supply subtypes in a particularly useful way.

So let's move on to determining current usage during bus enumeration.

Tracking gadget configuration

When a Standard Downstream Port (SDP) connection is detected, the PHY driver notifies the USB gadget controller, which then proceeds with the enumeration process. The parts of this that interest us are how MaxPower values are chosen and how the MaxPower from the chosen configuration is communicated. MaxPower is the field in a USB configuration table that lists the current requirement, which can be seen using:

    lsusb -v | grep MaxPower

Linux provides a "composite" gadget design where a number of different drivers can each register their own configuration and the composite driver will provide a list of all of those configurations to the host for it to choose from. There is a serial driver, an ether driver for networking, a mass_storage driver, and several others. Each of these just provides a single configuration and, while a few do set the MaxPower field in that configuration, most just leave it as the default. This default can be set using the compile-time configuration option CONFIG_USB_GADGET_VBUS_DRAW. This option defaults to 2mA, which is the smallest non-zero number that can be represented; zero is technically legal but apparently confuses some hosts. CONFIG_USB_GADGET_VBUS_DRAW is the sort of number that doesn't really make sense as a configuration option, but was probably implemented that way because it was easier than finding a real solution. No attempt is made to offer multiple versions of each configuration with different power requirements as was suggested in the previous article.

It may be possible to offer multiple configurations by a different route. The composite USB gadget can be configured at runtime using configfs. As these slides [PDF] describe, it is possible to create multiple configurations and set the MaxPower for each. This interface could be used to create multiple configurations for each driver, but that does feel a little roundabout and clumsy.

Whatever configuration is created, once it has been chosen by the host, the core USB gadget driver will report this information to the hardware-specific gadget driver by calling the vbus_draw() method on that driver. Of those gadget drivers that actually provide a vbus_draw() method (some don't) and don't simply ignore the value (several do), most just call usb_phy_set_power() to tell the PHY driver what power is available. If that sounds like passing the buck to you, I would agree. Most PHY drivers just ignore the number too.

One exception is the s3c2410_udc.c USB gadget driver used in the GTA02, which is the original OpenMoko phone. It calls a function provided by the "board" file that contains specifics of the particular platform. The GTA02 board file uses a private mechanism to pass the number to the power manager. It is probable that out-of-tree drivers in vendor kernels use a similar approach.

Setting the right current

Once the current that might be available has been determined and communicated to the charging manager, it is necessary to configure the charging power supply with an appropriate current, preferably the highest permitted current that doesn't cause the voltage to drop too low. As far as I can tell from exploring the code, there is only one driver that tries anything more sophisticated than setting a fixed current level, possibly dependent on the type of cable or vbus_draw() setting. That driver is the twl4030_charger.c that drives the battery charger in the OpenPhoenux GTA04; I know about that driver, and its imperfections, because I wrote the code to control the current.

The code in this driver increases the current requested in steps of 20mA until the voltage drops to 4.75V or until the maximum permitted is reached. This process mostly works, but subsequent reflections revealed a problem. If the battery is fully charged, then the phone as a whole cannot make use of more that a few hundred mA, so increasing the current setting won't actually put more load on the power supply, and thus won't cause the voltage to drop. This could lead to the current request being set to the maximum permitted even if it exceeds the maximum available. The charging hardware stops feeding current to the battery when the battery voltage reaches a certain level and the battery will be allowed to power at least some of the hardware. After the voltage drops a little, the charging turns back on, and at this point the battery may be able to accept more current than it could when the available current was being measured. This current might overload the charger.

The main point about this code is that it is easy to get wrong, but in principle should be common to all chargers that can limit current and measure voltage. So it really belongs in a common location — but where? There do seem to be a number of different elements of functionality needed for USB charging and they are currently implemented in an ad hoc manner. Bringing it all under a common umbrella appears to be the goal of USB charger framework that is currently being developed by Baolin Wang; it was recently posted in its 15th revision.

The USB charger framework

The framework attaches a "usb charger" object to every USB gadget device that is created and intercepts the vbus_draw() calls so that it knows when an SDP has been configured. If the USB gadget device is described in the device-tree as having an "extcon" connector attached, it will register for notifications for cable-change events.

Other drivers, such as a charger driver, can register to receive notifications from a USB charger if they know the name of the charger. The name will always be usb-charger.0 unless there are multiple chargers. When any change happens to the charger, it will notify all registered listeners to tell them the new current limit. This limit is a single number, not a range, so it needs to be handled carefully.

If charger managers were required to increase the current gradually up to this level, then sending the maximum would be appropriate. If they were expected to always enable exactly this number, then sending the minimum is the only safe approach. In the default configuration, the framework advises a current limit of 1500mA for the various types of chargers. This is the maximum for some, but not all, cable types. The only example of a charger driver that has been modified to use this information simply sets the limit rather than carefully ramping up to the limit. This may be safe, but only if that hardware has its own built-in current ramping.

When the framework registers interest in an extcon, it only requests notification of EXTCON_USB cables, not the various charger cables. When that notification arrives, it checks with the configured power supply to see what USB subtype it is and reports available current based on that. So this framework seems to have sided with USB cable types being the property of the power supply rather than the property of the cable.

Conclusion

While most of the parts needed for compliant USB charging are present, they are not implemented consistently, and it isn't even entirely clear what the right approach should be even if the USB charging framework does get merged. That wasn't the answer I was hoping for when I started examining this issue, but does at least clarify the current situation. Knowing where we stand makes moving forward a lot easier.

The one question I haven't yet covered is the need to keep most devices off until a stable source of power is assured. The reason for keeping this separate is that it is unlikely to ever be a part of Linux. There are enough interdependencies between discovery of different devices in Linux that trying to delay some in unusual circumstances is likely to lead to hard-to-diagnose problems.

Since the device is encouraged to avoid any unnecessary tasks until power is stable, it makes sense to not even boot Linux straight away. U-Boot, a common boot loader for mobile devices, is sufficiently powerful to be able to handle all the necessary negotiation to enable the maximum current possible. It should then be able to enter a low-power state until the battery has reached a sufficient charge to carry all the way through the Linux boot process. Linux will likely turn off battery charging during boot and renegotiate from scratch, so the battery needs enough charge to get all the way through the boot on its own.

There is clearly plenty to do to get USB charging into a healthy state. A particularly valuable first step would be to get clarity on how extcon and power_supply devices should work with the different cable types, and then to provide a standard way for charging power supply devices to ramp up the load while maintaining adequate voltage. With these in place, individual drivers could be updated to use these newly clarified interfaces on an as-needed basis. It's just a small matter of programming.

Comments (4 posted)