[OpenWrt-Devel] Build system puzzles: PCI_SUPPORT not being set for subtarget

Jeff Kletsky lede at allycomm.com
Thu May 9 04:29:31 EDT 2019


I'm having some challenges understanding why PCI_SUPPORT is being set
for the "generic" target, but not being set for the "nand" subtarget.
This seems to be the cause for the ath10k drivers not being available
in menuconfig.

While this has become an issue with the first port of an ath79 device
using the spinand framework backported to Linux 4.19, it can be seen
on `master` without any modifications.

All that follows is based on `master` as of

   commit 165d598521 (HEAD -> master, openwrt/master)
   Author: Hans Dedecker <reacted>
   Date:   Wed May 8 21:52:20 2019 +0200


To replicate:

* Check out `master`
* `make menuconfig`

* Select
   * Target System (Atheros ATH79 (DTS))
   * Subtarget (Generic)
   * Target Profile (GL.iNet GL-AR300M)
* Search (with /) for "mod-ath10k"
* Note that
   * PACKAGE_kmod-ath10k-ct is available for selection
   * It "Depends on: PCI_SUPPORT [=y] && ..."
* Exit from the search

* Change the selection to
   * Target System (Atheros ATH79 (DTS))
   * Subtarget (Generic devices with NAND flash)
   * Target Profile (GL.iNet GL-AR300M (NAND))
* Search (with /) for "mod-ath10k"
* Note that
   * PACKAGE_kmod-ath10k-ct is *not* available for selection
   * It "Depends on: PCI_SUPPORT [=n] && ..."

I don't see any differences between the generic and nand subtargets'
`config-default`, `target.mk`, or `image/*.mk` that seem related to
PCI_SUPPORT.

FEATURES don't seem to come into play at the target level

   target/linux/ath79$ fgrep -r FEATURES .
   ./Makefile:FEATURES:=ramdisk
   ./tiny/target.mk:FEATURES += squashfs small_flash
   ./nand/target.mk:FEATURES += squashfs nand rtc
   ./generic/target.mk:FEATURES += squashfs

I've tried adding FEATURES += pci with no apparent change in behavior.

I've tried to follow through `include/target.mk` and `scripts/kconfig.pl`
around LINUX_KCONFIG_LIST and LINUX_RECONFIG_LIST and it appears to me
that the "starting" config is generic, then platform, then subtarget,
(then local from ./env/, at least for compile). __config_name_list
suggests to me that `config-4.x` is processed before `config-default`
for each of these levels. It seems that this is a "last wins" process
for each specific config line.

Is my understanding of this process correct?

Can you provide any insight as how to resolve this specific problem
with PCI_SUPPORT?

Thanks,

Jeff




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190509/997e7903/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list