OpenWrt sources diag.sh at the preinit_main hook stage (02_default_set_state),
resolving LED aliases from the device tree so that set_state() can blink the
boot LED through the preinit and preinit_regular phases before init takes
over. For that to work the LED driver must be present before the preinit
scripts run.
Without the boot flag, AutoProbe only places the module in etc/modules.d,
which is loaded by /etc/init.d/boot once preinit has finished. By that
point the entire preinit LED window has passed and the boot indication on
any ST LED1202-backed LED is silently skipped.
Set the boot flag so the module is also linked into etc/modules-boot.d,
which procd loads before running the preinit scripts. The previous commits
bring the driver to a state where loading it at early boot is appropriate.
Assisted-by: LLM
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23456
Signed-off-by: Robert Marko <robimarko@gmail.com>
The sound and DRM modules carry a dependency on audio-support and
video-support, which is what decides whether an image handles those
devices. The AUDIO_SUPPORT and DISPLAY_SUPPORT tokens beside them add a
second, per-SoC-family condition that a board cannot influence, and that
DISPLAY_SUPPORT is half derived from whatever kernel configuration was
copied into a target's fragment.
Drop the tokens from the module dependencies and from fbtest.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The USB and parallel port printer nodes come out 0600 root:root, so a
print spooler runs as root. The lp group is already allocated by p910nd
in the packages feed with gid 7, without anything creating it.
Add a printer-support package which allocates that group and puts the
usblp, lp and ppdev nodes into it, and make kmod-usb-printer and kmod-lp
depend on it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The DVB adapter nodes under /dev/dvb come out 0600 root:root, so a
tuner daemon runs as root.
Add a dvb-support package which allocates the dvb group and puts those
nodes into it, and make kmod-dvb-core depend on it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The evdev character devices come out 0600 root:root, so a display server
or any other process reading keyboards and pointers runs as root.
Add an input-support package which allocates the input group and puts the
input nodes into it, and make the evdev and joydev modules depend on it.
The one device profile that ships evdev lists the package directly.
kmod-input-core stays ungated: it carries no device node of its own, and
most drivers built on it deliver their events to in-kernel consumers such
as the keyboard and button handlers.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The display target feature gates every DRM module, but it says nothing
useful: it is set on ten targets, so a mediatek/mt7623 board can have a
display while a filogic board with a MIPI DBI panel cannot, and rockchip
claims it for a NanoPi R2S as much as for a Rock 5B. Whether a board
drives a panel is a per-device choice, not a property of the SoC family.
The DRM and V4L2 nodes also end up 0600 root:root, so a display server
runs as root or not at all.
Add a video-support package which allocates the video and video-capture
groups and installs the hotplug rules for the DRM and V4L2 nodes, and
make the modules depend on it. The dependency is a plain one, not a
select, so the modules are offered once the feature is chosen. Targets
whose display drivers are built into the kernel carry the package in
DEFAULT_PACKAGES, since no module pulls it in for them, and the one
device profile that ships a DRM module on another target lists it
directly. DISPLAY_SUPPORT stays for now, so this changes no existing
selection.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The audio group and the rule that puts the ALSA character devices in it
are part of procd and base-files, so every image carries them whether or
not it has a sound card, and a package wanting the group has nothing to
depend on. Playback, capture and MIDI all land in one group as well, so a
process allowed to play is also allowed to record.
Move the lot into a new audio-support package with three groups, audio,
audio-capture and midi, and a hotplug fragment that sorts the sound nodes
between them. kmod-sound-core depends on the package, and so do the image
profiles that ship a sound driver. The dependency is a plain one, not a
select, so sound support is offered once the feature is chosen; userspace
that needs one of the groups depends on the same package. Images without
it fall back to the generic rule and get /dev/snd/* as 0600 root:root.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
BlueZ creates Bluetooth Low Energy HID devices through uhid, so a
Bluetooth remote or keyboard needs it in addition to kmod-bluetooth.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Enable MACsec (Media Access Control Security) support in the Mellanox
mlx5 driver by setting CONFIG_MLX5_MACSEC=y.
Enabling this configuration allows users to utilize hardware MACsec
offload capabilities on supported Mellanox ConnectX network adapters.
This provides point-to-point Layer 2 encryption at line rate while
significantly reducing CPU overhead.
The kmod-macsec dependency is intentionally omitted to make this an
opt-in feature. The offload support only builds if kmod-macsec is
also selected, preventing driver bloat for standard users.
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://github.com/openwrt/openwrt/pull/25400
Signed-off-by: Robert Marko <robimarko@gmail.com>
The media tuner packages set CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y but hang
off kmod-i2c-core rather than kmod-dvb-core, so commit ccbdf20984
("kernel: restrict DVB and rc-core modules to kernel 6.18") left them
selectable on kernel 6.12. They open the digital TV menus on their own,
target/linux/generic/config-6.12 has no answer for the symbols that
become visible and syncconfig stops waiting for input. Restrict them
the same way until config-6.12 answers those symbols.
Fixes: 1560c75fa2 ("kernel: add initial DVB support")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The new DVB and remote controller packages are kernel version agnostic,
but the media symbols they make reachable were only answered in
target/linux/generic/config-6.18. On the targets still building kernel
6.12 the buildbot selects the packages through CONFIG_ALL_KMODS,
kconfig has no answer for the newly visible symbols and syncconfig
stops waiting for input.
Restrict the three packages the others hang off. Everything DVB
depends on kmod-dvb-core and kmod-video-em28xx-dvb follows
kmod-video-em28xx, while kmod-rc-core is a root of its own: RC_DEVICES
opens the remote controller menu with no DVB package involved.
Fixes: 1560c75fa2 ("kernel: add initial DVB support")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The kernel package lists $(SUBTARGET_MODULES) among its SCAN_DEPS, but
scan.mk takes that line as text and expands it in its own context,
where the variable does not exist. The per-target modules.mk files
therefore never invalidate the kernel package metadata, and an edited
or newly added modules.mk only takes effect after removing tmp/. Name
the files with wildcards that scan.mk can expand itself.
Fixes: 3a8825ad6a ("build: fix issues with targets installed via feeds")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add kernel packages for DVB adapters, frontends and tuners. Not
everything is covered, but the list can grow over the time.
Userspace uses these through /dev/dvb, for example tvheadend from the
packages feed, which streams the tuners to network clients over HTTP
and HTSP.
Remote controller support (kmod-rc-core) goes into the Input modules
menu: rc-core depends only on INPUT and is not DVB specific.
Enabling DVB_CORE and RC_CORE makes parts of the media driver menu
visible which nothing in the tree has enabled so far, so kconfig has
no answer for them and stops for input. Add the 98 missing symbols to
the generic config. CONFIG_MEDIA_RC_SUPPORT, CONFIG_VIDEO_V4L2,
CONFIG_DVB_HD29L2, CONFIG_DVB_USB_FRIIO and CONFIG_IR_SIR do not exist
in kernel 6.18 anymore and are removed.
Tested on kernel 6.18.44, all 78 packages build with CONFIG_ALL_KMODS
and their module paths and kernel symbols were verified against the
kernel tree.
Signed-off-by: Michal Hrusecky <michal.hrusecky@nic.cz>
Signed-off-by: Karel Kočí <karel.koci@nic.cz>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24788
Signed-off-by: Robert Marko <robimarko@gmail.com>
Remove the LINUX_6_12/LINUX_6_18 version guards that are now dead
weight following the removal of the 6.12 kernel, and drop the
kmod-rp1 and kmod-rp1-mailbox packages, which are no longer
buildable now that CONFIG_FIRMWARE_RP1 and CONFIG_MBOX_RP1 are
built into the bcm2712 6.18 kernel (=y) rather than as modules.
In detail:
- i2c.mk: drop the now-always-true LINUX_6_18 condition from the
i2c-designware-core DEPENDS.
- other.mk: remove kmod-rp1 and kmod-rp1-mailbox (now built into
the kernel on 6.18 via CONFIG_FIRMWARE_RP1/CONFIG_MBOX_RP1), and
drop the LINUX_6_12/LINUX_6_18 conditionals from kmod-rp1-pio and
kmod-rp1-pio-uart.
- video.mk: collapse the RP1_CFE_KCONFIG/RP1_CFE_FILES/
RP1_CFE_DEPENDS ifeq(CONFIG_LINUX_6_12/6_18) blocks in kmod-rp1-cfe
down to the 6.18 values, and drop the now-unconditional LINUX_6_18
dependency from kmod-rp1-cfe-downstream, kmod-rp1-hevc-dec and
kmod-drm-vc4.
Signed-off-by: Joshua Covington <joshuacov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25037
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add the two external Aeonsemi AS21xxx PHYs used by the LAN and WAN
10GBASE-T ports of the BPI-R4 Pro 8x. Configure their firmware, reset
timing and LEDs, and connect them to the MxL switch and GMAC1.
Replace the fixed SFP GPIO hog configuration with LAN and WAN overlays
selecting either the copper PHY or the corresponding SFP cage. Build all
four overlays, include them in the device image and select the SFP
overlays by default through U-Boot `bootconf_extra`.
Make the AS21xxx firmware package pull in the PHY driver on Linux 6.18,
instead of making the driver depend on the firmware. Update existing
Airoha device package lists accordingly so they continue to install both
components through the firmware package.
Breaking change for users using the router with SFP hogs from PR #21083.
After flashing the new image, configure `bootconf_extra` to select
between SFP or PHY overlays:
fw_setenv bootconf_extra \
mt7988a-bananapi-bpi-r4-pro-8x-lan-phy#mt7988a-bananapi-bpi-r4-pro-8x-wan-phy
If bootconf_extra had additional overlays (CN13 or CN14) keep them appended
Signed-off-by: Pietro Ameruoso <p.ameruoso@live.it>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
CONFIG_LEDS_LP5521 has no corresponding KernelPackage, unlike its
LP55xx siblings (LP5523, LP5562), so the driver could only ever be
built in, never as a module. Add the missing package definition,
mirroring KernelPackage/leds-lp5523.
Signed-off-by: Matt Eaton <git@divinehawk.com>
Link: https://github.com/openwrt/openwrt/pull/24812
Signed-off-by: Robert Marko <robimarko@gmail.com>
videobuf2-vmalloc.ko was listed unconditionally in video-videobuf2's
FILES, but CONFIG_VIDEOBUF2_VMALLOC is only reliably built when a
driver that needs a vmalloc-backed allocator (e.g. pwc, uvc, gspca)
is itself selected. Any build where none of those drivers happen to
be enabled (e.g. under CONFIG_ALL_KMODS=y on a target where those USB
webcam drivers aren't selected) fails hard while packaging
kmod-video-videobuf2, since the .ko it expects to copy was never
built:
ERROR: module '.../videobuf2-vmalloc.ko' is missing.
Split it out into its own kmod-video-vmalloc package, following the
same pattern already used for video-dma-contig and video-dma-sg.
videobuf2-vmalloc.c calls dma_buf_vmap_unlocked/dma_buf_vunmap_unlocked
directly, so the new package depends on kmod-dma-buf explicitly rather
than only transitively through kmod-video-videobuf2.
Adjust the DEPENDS of all six in-tree drivers that previously got the
module for free from kmod-video-videobuf2: video-pwc, video-uvc,
video-gspca-core, video-coda, video-tw686x and camera-bcm2835.
camera-bcm2835's AUTOLOAD priority also moves from 66 to 67, matching
its siblings bcm2835-codec/bcm2835-isp/rp1-cfe*, which already sit one
priority above the videobuf2 allocator helper (65/66) they depend on.
Fix also two dead entries in video-videobuf2's AUTOLOAD that never
matched a built module (videobuf2-core and videobuf-v4l2, vs. the actual
videobuf2-common.ko/videobuf2-v4l2.ko), which caused kmodloader to
complain on every boot; pre-existing, unrelated to the split itself.
Signed-off-by: Joshua Covington <joshuacov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24647
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since 6.18, fb.ko calls into the backlight class rather than the
reverse, so it depends on backlight.ko when CONFIG_FB_BACKLIGHT is set,
which in-tree only happens via FB_TFT's select. Building kmod-fb-tft on
a 6.18 target with DISPLAY_SUPPORT therefore fails with:
Package kmod-fb is missing dependencies for the following libraries:
backlight.ko
Declare the dependency on kmod-fb, conditional on kmod-backlight being
built. An unconditional +kmod-backlight would form a recursive
dependency with KernelPackage/backlight's +kmod-fb, both as a kconfig
select cycle and as a circular PACK_ prerequisite that make resolves by
dropping an edge.
backlight.ko only references fb.ko on 6.12, so narrow that reverse
dependency to +LINUX_6_12:kmod-fb, which leaves a single edge on 6.18.
Signed-off-by: Matt Eaton <git@divinehawk.com>
Link: https://github.com/openwrt/openwrt/pull/24765
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add support for the GPIO-based backlight driver, which allows controlling
display backlights connected via GPIO pins. This is commonly used on
embedded boards and SBCs where a display backlight is toggled through
a GPIO line rather than a dedicated backlight IC.
Enables CONFIG_BACKLIGHT_GPIO.
Signed-off-by: Matt Eaton <git@divinehawk.com>
Link: https://github.com/openwrt/openwrt/pull/22740
Signed-off-by: Robert Marko <robimarko@gmail.com>
nf_flow_table.ko now links in the flowtable path discovery code
(nft_flow_route() and friends), which was moved out of
nft_flow_offload.c and references nf_tables symbols directly. This
makes nf_flow_table.ko depend on nf_tables.ko at load time, so
kmod-nf-flow needs kmod-nft-core.
Upstream: 93d7a7ed0734 ("netfilter: flowtable: move path discovery infrastructure to its own file")
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/24419
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This was changed in upstream linux kernel with:
|commit db4bfcba7bb8 um: Fix hostaudio build errors
|Author: Randy Dunlap <rdunlap@infradead.org>
|Date: Tue Aug 1 22:15:00 2023 -0700
|
| um: Fix hostaudio build errors
|
| Use "select" to ensure that the required kconfig symbols are set
| as expected.
| Drop HOSTAUDIO since it is now equivalent to UML_SOUND.
|
| Set CONFIG_SOUND=m in ARCH=um defconfig files to maintain the
| status quo of the default configs.
|
| Allow SOUND with UML regardless of HAS_IOMEM. Otherwise there is a
| kconfig warning for unmet dependencies. (This was not an issue when
| SOUND was defined in arch/um/drivers/Kconfig. I have done 50 randconfig
| builds and didn't find any issues.)
| [...]
The reason why this was not spotted is because of IOMEM. We would need
to have a device that requires IOMEM first and the obvious choice would
be VFIO_PCI. But none of the pci features are set for the UML target.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Do not pull iptables core for kmod-sched-ctinfo, only nf-conntrack,
reflecting kernel config dependencies.
There is no use of this module in openwrt repos, but it is used by
@hudra0 qosmate
and some less popular qos scripts.
Signed-off-by: Andris PE <neandris@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24104
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Direct-I2C driver for the HS104 PSE chip (unlike the MCU-fronted
realtek-pse-mcu family). Packaged as kmod-pse-hasivo-hs104.
This driver will be submitted upstream once the pending PSE-core
patches it builds on (above) have landed.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/22245
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add kmod packages to support accessing the fTPM (in-firmware TPM) which
can be implemented in the boot firmware of most modern platforms.
- kmod-optee: Open Portable Trusted Execution Environment
- kmod-optee-rng: OP-TEE random number generator client
- kmod-rtc-optee: OP-TEE real-time clock client
- kmod-scmi-transport-optee: SCMI OP-TEE transport
- kmod-tee: Generic Trusted Execution Environment
- kmod-tee-stmm-efi: EFI variable service Trusted Application
- kmod-tpm-ftpm-tee: Microsoft fTPM Trusted Application
Using the TPM 2.0 can be useful for various security applications,
such as encrypting on-disk credentials. OP-TEE itself alone is also
useful as it can provide a PKCS#11 token for authentication (eg. to
connect to a VPN) and significantly lower the risk of leaking secrets
used for authentication. Also, on some platforms RNG and RTC can only be
accessed via OP-TEE, and some ARM SystemReady platforms require EFI
variables to be access via a TA.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add pending patches which add a PSE driver for the PSE setup found on
most of Realtek-based switches. An MCU with a Realtek-defined firmware
and protocol fronts one or more PSE chips (from Realtek or Broadcom) as
a management controller.
The driver provides both I2C/SMBus and UART communication, which varies
among our supported switches. There is no need for complicated userspace
handling anymore, the PSE setup is defined in the device tree and
interfaced in userspace via ethtool, netlink and netifd support.
Those patches have progressed far enough upstream, the bindings are
reviewed. Thus, we can keep this intermediate version downstream to open
it up earlier for usage. Only little changes are expected til the final
version lands.
Link: https://github.com/openwrt/openwrt/pull/23222
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The bcm27xx/bcm2708 all-kmods CI build fails when modpost reaches the
DesignWare I2C core module:
ERROR: modpost: "__aeabi_uldivmod"
[drivers/i2c/busses/i2c-designware-core.ko] undefined!
This is triggered by CONFIG_ALL_KMODS=y. The old 32-bit Raspberry Pi
subtargets do not normally select this driver for runtime use, but all-kmods
forces the kmod package to be built anyway. On 32-bit ARM, raw 64-bit
division in a module can cause GCC to emit the ARM EABI helper
__aeabi_uldivmod, which is not available as a kernel module symbol.
The failing reference comes from i2c-designware-master.c, where clock_calc()
uses raw u64 division for SCL timing calculations (introduced with commit
3805d13c3ead21494f7d00aa44f10e3656363d4c in rpi-6.18.y / "i2c: designware:
Support non-standard bus speeds"). That is a kernel-side portability issue,
but these old bcm27xx subtargets do not use DesignWare I2C hardware. They
use the Broadcom I2C controller instead.
The failure is emitted for i2c-designware-core.ko, so guard the hidden core
package itself rather than only guarding the platform or PCI frontend package.
This prevents CONFIG_ALL_KMODS from selecting the failing core module directly
on the affected 32-bit bcm27xx subtargets.
DesignWare I2C is relevant for newer Raspberry Pi 5 / RP1 based systems, so
keep it available for bcm2712.
A similar issue was reported by NixOS for Raspberry Pi ARM builds, where
i2c-designware-core.ko failed with the same unresolved __aeabi_uldivmod symbol.
Their workaround was to disable the DesignWare I2C symbols for older Raspberry
Pi targets that do not need them.
Link: https://github.com/NixOS/nixpkgs/issues/464515
Until the underlying ARM32 kernel-side issue is fixed, avoid building
the DesignWare core package on bcm2708, bcm2709 and bcm2710.
Signed-off-by: Joshua Covington <joshuacov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23703
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
These path names are unlikely to change. There is no need for variables.
Tested on Turris Omnia, but not all of these drivers were tested. Variables
were replaced automatically (search-and-replace in text editor). There
shouldn't be any problems.
Signed-off-by: Marius Dinu <m95d+git@psihoexpert.ro>
Create a package for ov5645 kernel module, required to support camera on
PICO-PI-IMX7D board.
Currently limit the visibility to imx_cortexa7 subtarget, but this can
be enabled on other platforms if needed.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17606
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Split kmod-nf-nathelper-extra into separate helper packages
and keep the original package as a compatibility meta-package.
This allows selecting only the required protocol helpers
instead of installing all helper modules and dependencies.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/23690
Signed-off-by: Robert Marko <robimarko@gmail.com>
LED trigger for network interfaces.
- Aggregated per-family (lan/wan/wlan).
- Family and flags are taken from device tree properties:
- "family" : simple family string "lan" | "wan" | "wlan"
- "mode" : any combination of "link", "tx", "rx" flags
Priority/combination:
* If "mode" present: flags come from "mode" and take precedence.
Family is taken from "family" if present, otherwise from the LED name.
* If only "family" present: use its family and default flags = link+tx+rx.
* If neither present: fall back to LED device name parsing.
- Suffix "-online" is valid ONLY in the LED name (label),
e.g. "green:wlan-online". It indicates the online variant but is applied
only when DT "mode" is absent.
Behaviour:
- wlan (normal): blink/solid driven by throughput table
- lan/wan (normal): one-shot blink on TX/RX packet change
- *-online variants: steady ON while any interface of the family has carrier
Interfaces are auto-tracked by name match (lan0, wan1, wlan2, phy0, wl1,
ath0, ra0...). Up to MAX_IFACES (16) interfaces per family
This trigger is intended for board/device authors and drivers to provide simple
network-activity LED behaviour without per-interface wiring in userspace.
Refresh bcm27xx patches in the same commit to account for line shifts in
drivers/leds/trigger/Kconfig and Makefile, ensuring clean applies for
bisectability.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/19903
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add support for the Micro Crystal RV3028 I2C real-time clock chip.
Tested on a Kontron OSM-S/BL i.MX8MP eval board.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Since upstream commit 60e3f1e9b7a5 ("lib/crypto: arm64/sha512:
Migrate optimized SHA-512 code to library"), the kernel module is no
longer available, and its fucntionality os provided by the kernel
core. Thus do not try to package this for linux 6.18 and later.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21506
Signed-off-by: Robert Marko <robimarko@gmail.com>
Manuel Fombuena
Daniel Golle
Til Kaiser
Michal Hrusecky
Joshua Covington
Frank Wunderlich
Erik Larsson
Matt Eaton
Shiji Yang
John Audia
Christian Lamparter
Steffen Loley
Andris PE
Carlo Szelinsky
Rosen Penev
Jonas Jelonek
Marius Dinu
Lech Perczak
Mieczyslaw Nalewaj
Qingfang Deng
Thomas Richard
Martin Schiller
Alexandru Gagniuc
Dee HY