x86: detangle meraki-mx100 / nu801 build confusion
authorChristian Lamparter <chunkeey@gmail.com>
Sun, 1 May 2022 12:10:35 +0000 (14:10 +0200)
committerChristian Lamparter <chunkeey@gmail.com>
Sun, 1 May 2022 12:10:35 +0000 (14:10 +0200)
commit9a137477811611f6363fb049b8356457798169a6
tree54004654b6190a92219386ee105ee806b4b281b6
parent414521332401f852e5e1552a69eb277a0d5eea86
x86: detangle meraki-mx100 / nu801 build confusion

Grommish reported the dreaded build error that happend with 5.4
since the kernel didn't have the cgpio v2 interface. His reason
for the removed 5.4 was that the octeon target had a memory leak
issue, so he had to backport the removed 5.4 kernel for his tests.

Chen Minqiang chimed in and noted that no matter what (i.e.
@TARGET_x86 in depends) didn't prevent the package from being build
on other targets.

From what I can tell, the reason for this was that +nu801 meant
that kmod-meraki-mx100 pulled in an unconditional dependency as
part of to the kernel build.

|scripts/package-metadata.pl mk tmp/.packageinfo
|
|$(curdir)/kernel/linux/compile += $(curdir)/firmware/linux-firmware/compile \
| $(curdir)/firmware/prism54-firmware/compile \
| $(curdir)/kernel/gpio-button-hotplug/compile \
| >>> $(curdir)/system/gpio-cdev/nu801/compile <<<

change this by making the dependency conditional on the
meraki-mx100 module itself. Note that the nu801 enables/sets
the  KCONFIG for the cgpio v2 interface itself, since the
userspace program and not the kernel meraki-mx100 relies on it.

Reference: <https://github.com/openwrt/openwrt/commit/eeb8fd4ce7e9>
Reported-by: Grommish <grommish@gmail.com>
Reported-by: Chen Minqiang <ptpt52@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
target/linux/x86/modules.mk