August 8, 2016
Related Material::
Additional Participants: Alexandre Belloni, Arnd Bergmann, Bjorn Helgaas via Ksummit-discuss, Daniel Vetter, Darren Hart, Jani Nikula, Laurent Pinchart, Mark Brown, Olof Johansson, Peter Ujfalusi, Russell King - ARM Linux, Stephen Rothwell, Tony Lindgren, Vinod Koul, and Wolfram Sang.
People tagged: (none)
Daniel Vetter found the 2013 LKS presentation on “Git tree maintenance to be interesting, and noted a more recent ad-hoc discussion on group maintainership. Daniel also has some group-maintainership tools that he would like to discuss. Darren Hart, Bjorn Helgaas, Olof Johansson, Vinod Koul, and Jani Nikula indicated strong interest interest in this topic, with style points to Bjorn for the obligatory Star Trek quote and with Darren indicating an interest in increasing commonality across maintainers. Daniel Vetter was unsure that he was helping increase commonality, given that he was introducing a new tool set, but Darren Hart reiterated his interest.
Getting the Mess to Even Build:
Vinod Koul called out a tool he would like to see, namely anything making it easier to build ARM drivers. Vinod did note that things have gotten better, calling out multi_xx_defconfig in particular, but is nevertheless not fully happy with the current state. Wolfram Sang presented the manual method he uses to maintain a working set of .config files. Wolfram also called out the COMPILE_TEST Kconfig option as being quite helpful for compile-testing drivers that would normally not even build on your system, for example, allowing drivers for ARM-only devices to be built on x86 systems.
Arnd Bergmann believes that an allmodconfig build on ARM should build most drivers without warnings when using gcc version 4.9 or better. He also believes that such a build might take some time to complete, but nevertheless would like to include additional drivers. Vinod Koul pointed out that some of the drivers he wants to build depend on various ARM subarchitectures, and wonders why more of them don't instead depend solely on ARM. Mark Brown stated that new code should build OK when the COMPILE_TEST Kconfig option is specified, and pointed out that user experience is improved by making drivers fail to build except for subarches having the corresponding hardware: Otherwise, people are asked nonsensical questions about hardware that they don't even have in their system. Vinod Koul agreed that COMPILE_TEST was great for new hardware, but is having trouble with older drivers that are not COMPILE_TEST-aware.
Arnd Bergmann noted that there are three distinct ways of restricting where a given device driver should build, but was not immediately forthcoming as to whether any of the three could safely be retired. Vinod Koul preferred Arnd's third option, and in turn Arnd asked Vinod to let him know if additional depends on arm clauses are required. Alexandre Belloni noted a fourth option, namely selecting the driver directly from the architecture or SoC Kconfig file, but Stephen Rothwell warned of the dangers of selecting any symbol having dependencies.
Daniel Vetter listed some planned improvements for building, which seem to involve git rerere (with apparently mixed results), but noted that compile testing has not yet made its way into the shared tooling.
DMAengine Issues:
Laurent Pinchart suspects that OMAP DMA might need special handling to enable cross-building, given that it depends on the implementation in arch/arm/plat-omap/dma.c. Arnd Bergmann pointed out that this is a dependency on OMAP in particular rather than ARM in general, and also took the opportunity to call for volunteers to convert the last few files to the DMAengine framework. https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003268.html suggested that detailed discussion moved to the dmaengine list and called out Peter as a volunteer, and Peter Ujfalusi confirmed that he was working on several of these, and Arnd Bergmann provided some feedback and seemed happy to learn that someone was actually working on this, as did Tony Lindgren. Laurent Pinchart offered to test one set of drivers.
Russell King suggested that a number of drivers could simply be removed given that he added warnings to a number of them and had received no corresponding error reports. Laurent Pinchart said that he knows of vendors who use the devices on recent kernels, and simply patch out Russell's warning. This prompted Russell King to suggest that he simply queue a commit to remove those drivers, on the grounds that vendors willing to revert a commit adding a warning should be just fine reverting a commit removing a device driver.