The null TTY driver provides a proper (dummy) TTY interface when
console=null is set on the kernel cmdline. This fixes certain
applications which don't correctly handle read() immediately returning
with 0 bytes (e.g. busybox syslogd).
Most normal EFI devices don't boot with console=null and as such there
are various foot-guns littered all over Linux userspace and even in our
own initramfs. However some android devices even enforce console=null,
so it's something we have to deal with.
NULL_TTY should reduce the chance of folks running into strange problems
because of this.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
CONFIG_LEDS_GROUP_MULTICOLOR just had to be re-enabled to fix a
regression. Add this to kconfigcheck to prevent disabling it by
accident in the future. Adjust the description of the Librem 5
specific section while at it.
[ci:skip-build] [ci:skip-vercheck]: no need to rebuild
This drops some kconfig that was added in !5836, which shouldn't be
required for device kernels to comply with the "input" kconfig check.
HID_HYPERV_MOUSE: requires enabling HyperV guest support in the kernel,
we shouldn't impose this on all device kernels.
HID_KUNIT_TEST: No reason to enable kunit support, we aren't testing the
kernel with device kernels
SURFACE_HID: Requires enabling a bunch of Microsoft Surface platform
drivers/support, doesn't make sense to require for all device kernels.
Kernels that support Surface devices can enable these as needed, since I
don't think any non-surface devices would even have surface HID input hw
in them.
Looks like a lot of HID drivers are missing from pmOS device-specific
kernels. Let's try to deal with it by enabling all the HID related
drivers that the Fedora aarch64 and x86 kernels enable.
[ci:skip-kconfig-check]: too many kernels fail from the new required
config here, it's unfeasible to update them all right now
main/postmarketos-base/rootfs-etc-conf.d-zram-init configures zstd as our
default ZRAM configuration, but the kconfigcheck only checks for LZ4 at the
moment. Because of this some of our kernels don't actually have ZSTD
support enabled and end up using the default compression algorithm.
For Linux >=4.18 we should enable CONFIG_CRYPTO_ZSTD to enable ZSTD support
for ZRAM.
In Linux >=6.12 the configuration was changed to CONFIG_ZRAM_BACKEND_ZSTD.
This requires manual edits while upgrading, otherwise only LZO support will
remain enabled.
Checking for >=3.14.0 additionally does not make any sense, because the
kconfig check should not be enabled for kernels that cannot satisfy our
minimum requirements.
Describe this properly in kconfigcheck.toml to ensure kernels are
configured correctly.
The following kernels are currently missing the correct options:
config-htc-flounder.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-postmarketos-amlogic.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-postmarketos-grate.armv7: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-postmarketos-qcom-msm8974.armv7: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-postmarketos-qcom-sc7280.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-postmarketos-qcom-sm6115.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-postmarketos-qcom-sm6350.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-purism-librem5.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
The following kernels are too old to support CONFIG_CRYPTO_ZSTD:
config-samsung-jxelte.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
config-volla-mimameid.aarch64: CONFIG_CRYPTO_ZSTD should be set (category:zram)
We've been disabling CONFIG_RS9116_FLASH_MODE for years at this point,
so this doesn't do anything but enforce the status quo.
Rationale for this can be found in the commit
ddf56b5169.
This is deliberately not added to the community check as it is
device-specific.
Closes https://gitlab.com/postmarketOS/pmaports/-/issues/3157
[ci:skip-build]: already built successfully in CI
Move the kernel config options from the pmbootstrap code to pmaports, so
it can be changed per branch, and it can be changed at the same time as
we actually make the changes to the kernel configs.
Clayton Craft