Source: linux Version: 4.15.4-1 Severity: wishlist Hi,
I have the TERES I open hardware laptop from olimex https://www.olimex.com/Products/DIY-Laptop/ running with buster, but I had to recompile the kernel to get all the modules necessary to have a useable system. Mainlineing the devicetree file for the teres is work in progress, (see: https://lkml.org/lkml/2018/3/12/653 ) but most of the missing bit's in the kernel config are needed for all Allwinner A64 based boards anyway - many of which already have upstream support. Please enable the following configuration symbols for arm64 builds: 1) Relevant to all A64 based systems and other SoCs using the AXP803 PMIC: at least: CONFIG_MFD_AXP20X=y CONFIG_MFD_AXP20X_RSB=y CONFIG_REGULATOR_AXP20X=m CONFIG_INPUT_AXP20X_PEK=m (note about builtin vs. module: This is the combination I tested. It should be possible to have everything as modules so long as mkinitramfs puts them into the initrd. In theory we also need the regulator module in the initrd to power up the supply chain of the MMC hosts. In practice MMCs are already powered up by the boot loader, but we need at least the mfd part of the pmic driver, to get the kernel probing the devices. You might want to draw the line between builtin and module drivers in a saner way. I can test your configuration, once you have made up your mind.) probably also (untested yet, but will be demanded in the future obviously): CONFIG_PINCTRL_AXP209=m CONFIG_CHARGER_AXP20X=m CONFIG_BATTERY_AXP20X=m CONFIG_AXP20X_POWER=m CONFIG_AXP288_FUEL_GAUGE=m CONFIG_AXP20X_ADC=m CONFIG_AXP288_ADC=m 2) Relevant to A64 based systems, driver available since long and likely going to be enabled by default in upstream devicetrees starting with 4.17: CONFIG_SUNXI_WATCHDOG=m 3) Relevant at least to A64 based systems with backlight. Probably at the moment only the teres-i laptop: CONFIG_PWM_SUN4I=m CONFIG_BACKLIGHT_PWM=m 4) Maybe not relevant at the moment, but might be a sane default to include anyway: CONFIG_LEDS_PWM=m BTW, as you might have inferred from my message, I'm a bit unsure how you decide which drivers to enable. Do you have a script, that scan's the device trees for required drivers (if so it clearly failed to find the drivers listed in (1)), or do you rely solely on users speaking up when something is missing? Any hints on how to efficiently report missing drivers or upcoming upstream changes would be appreciated. Thanks for your consideration, Harald