hostapd is the upstream project, which tends to get split (and only released as such) into two separate components, wpa_supplicant (most of the client/ STA related wireless handling) and hostapd itself (most of the AP side wireless handling). Both components share a considerable amount of code (and are developed as one in a single git repository) and are increasingly intertwined (wpa_supplicant has learned some basic AP operations, partially for WiFi-Direct® - hostapd needs wpa_supplicant assistance for WDS/ 4addr). In OpenWrt, both components are merged into a single package and (multi-call) binary, mostly for space reasons. This means the single wpad binary (or its various variants) does assume both roles as needed.
Technically speaking the kernel doesn't know anything[0, 1] about wireless encryption, that is done in userspace by hostapd (read, wpad). hostapd is the one in charge of the key exchange, of the rekeying, of all the security- and policy decisions. Traditionally hostapd provided multiple APIs to communicate with hardware drivers (hostap was the first one, to communicate with the very first wireless chipsets using the hostap_{cs,pci,…} suite of drivers, madwifi/ atheros and intel were others), before this converged first into the generic wext and nowadays the nl80211 API (this one is the only fully supported one, the only contemporary one with AP support). Kernel- and hostapd upstream have decided that they will not accept new driver specific APIs anymore, everything has to be nl80211 compatible (wext is provided for legacy/ compatibility reasons, hostapd, madwifi/ atheros and intel have been dropped; wired does exist for IEEE802.1x ethernet authentication).
But some vendors do insist on using a custom API between their (proprietary) kernel drivers and hostapd (e.g. RealTek for many of their chipsets, assuming your hunch is correct probably also lantiq). Given that hostapd doesn't accept these and considering that vendors usually don't bother about submitting them anyways, they usually ship an ancient (v0.4.7 in case of RealTek, while v2.9 would be the current version) and heavily patched fork of hostapd. That is not a workable situation for upstream or OpenWrt, as hostapd is a highly security sensitive component (e.g. it had 7 security bugs this year alone - guess how many of those were fixed in those ancient custom vendor forks[2]) and because those different APIs also require a completely different configuration syntax.
--
[0] at least for anything beyond WEP. WEP was historically implemented in the kernel via the wext API - and for compatibility reasons these features remain, but are rarely used directly these days. This procedures was considered as very inflexible and abandoned for anything newer than WEP.
[1] most WLAN cards to have some hardware accelerated cipher support (AES, etc.) in the wireless chipset, these days with 802.11ac and beyond functionality is increasingly offloaded into hardware (both for secrecy reasons (don't giving users or competitors too much insight in the chips inner workings/ abilities) and performance/ power envelope reasons (hardware accelerations and reducing power usage, especially while idle)
[2] if you guessed zero, you would be correct.