Bug#892786: linux,arm64: please enable modules needed for teres-i OSHW laptop
Control: tag 892786 + pending
On Mon, Mar 12, 2018 at 10:06:37PM +0100, Harald Geyer wrote:
> 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
I enabled them all as modules, see https://deb.li/RhEe.
> 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.
I think we rely on people reporting problems. Reporting a bug as you did
is fine, if you're lucky comming into the irc channel #debian-kernel and
mentioning there what you need to have enabled might be good enough,
too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Reply to: