drivers/pci/endpoint/functions/Kconfig | 1 + 1 file changed, 1 insertion(+)
From: Arnd Bergmann <arnd@arndb.de>
Like some of the other endpoint modules, this one now also
uses configfs, but is missing an indication in Kconfig:
arm-linux-gnueabi-ld: drivers/pci/endpoint/functions/pci-epf-test.o: in function `pci_epf_test_add_cfs':
pci-epf-test.c:(.text.pci_epf_test_add_cfs+0x2c): undefined reference to `config_group_init_type_name'
Select the symbol as needed.
Fixes: ffcc4850a161 ("PCI: endpoint: pci-epf-test: Allow overriding default BAR sizes")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/pci/endpoint/functions/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/endpoint/functions/Kconfig b/drivers/pci/endpoint/functions/Kconfig
index 0c9cea0698d7..bb5a23994288 100644
--- a/drivers/pci/endpoint/functions/Kconfig
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -6,6 +6,7 @@
config PCI_EPF_TEST
tristate "PCI Endpoint Test driver"
depends on PCI_ENDPOINT
+ select CONFIGFS_FS
select CRC32
help
Enable this configuration option to enable the test driver
--
2.39.5
On Wed, Feb 11, 2026 at 08:07:40AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Like some of the other endpoint modules, this one now also
> uses configfs, but is missing an indication in Kconfig:
>
> arm-linux-gnueabi-ld: drivers/pci/endpoint/functions/pci-epf-test.o: in function `pci_epf_test_add_cfs':
> pci-epf-test.c:(.text.pci_epf_test_add_cfs+0x2c): undefined reference to `config_group_init_type_name'
>
> Select the symbol as needed.
>
> Fixes: ffcc4850a161 ("PCI: endpoint: pci-epf-test: Allow overriding default BAR sizes")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to pci/for-linus for v7.0, thanks!
> ---
> drivers/pci/endpoint/functions/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/endpoint/functions/Kconfig b/drivers/pci/endpoint/functions/Kconfig
> index 0c9cea0698d7..bb5a23994288 100644
> --- a/drivers/pci/endpoint/functions/Kconfig
> +++ b/drivers/pci/endpoint/functions/Kconfig
> @@ -6,6 +6,7 @@
> config PCI_EPF_TEST
> tristate "PCI Endpoint Test driver"
> depends on PCI_ENDPOINT
> + select CONFIGFS_FS
> select CRC32
> help
> Enable this configuration option to enable the test driver
> --
> 2.39.5
>
On Wed, Feb 11, 2026 at 08:07:40AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Like some of the other endpoint modules, this one now also
> uses configfs, but is missing an indication in Kconfig:
>
> arm-linux-gnueabi-ld: drivers/pci/endpoint/functions/pci-epf-test.o: in function `pci_epf_test_add_cfs':
> pci-epf-test.c:(.text.pci_epf_test_add_cfs+0x2c): undefined reference to `config_group_init_type_name'
>
> Select the symbol as needed.
>
> Fixes: ffcc4850a161 ("PCI: endpoint: pci-epf-test: Allow overriding default BAR sizes")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/pci/endpoint/functions/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/endpoint/functions/Kconfig b/drivers/pci/endpoint/functions/Kconfig
> index 0c9cea0698d7..bb5a23994288 100644
> --- a/drivers/pci/endpoint/functions/Kconfig
> +++ b/drivers/pci/endpoint/functions/Kconfig
> @@ -6,6 +6,7 @@
> config PCI_EPF_TEST
> tristate "PCI Endpoint Test driver"
> depends on PCI_ENDPOINT
> + select CONFIGFS_FS
> select CRC32
> help
> Enable this configuration option to enable the test driver
> --
> 2.39.5
>
Patch is fine with me:
Reviewed-by: Niklas Cassel <cassel@kernel.org>
However, I remember that you Arnd was one of the main reasons why Kishon
decided to use configfs to configure a PCI endpoint controller and to
bind a PCI endpoint function driver with a PCI endpoint controller.
I don't know of any other way than configfs to bind a PCI endpoint function
driver with a PCI endpoint controller.
To me, it seems a bit silly to be able to build PCI_ENDPOINT without
configfs. What should a user do with a library that they cannot bind to
a PCI endpoint controller?
Why shouldn't we just do something like:
diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index 8dad291be8b8..d6f898094509 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -8,6 +8,7 @@ menu "PCI Endpoint"
config PCI_ENDPOINT
bool "PCI Endpoint Support"
depends on HAVE_PCI
+ select PCI_ENDPOINT_CONFIGFS
help
Enable this configuration option to support configurable PCI
endpoint. This should be enabled if the platform has a PCI
diff --git a/drivers/pci/endpoint/functions/Kconfig b/drivers/pci/endpoint/functions/Kconfig
index 0c9cea0698d7..d7a4bea7d7b8 100644
--- a/drivers/pci/endpoint/functions/Kconfig
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -16,7 +16,6 @@ config PCI_EPF_TEST
config PCI_EPF_NTB
tristate "PCI Endpoint NTB driver"
depends on PCI_ENDPOINT
- select CONFIGFS_FS
help
Select this configuration option to enable the Non-Transparent
Bridge (NTB) driver for PCI Endpoint. NTB driver implements NTB
@@ -30,7 +29,6 @@ config PCI_EPF_VNTB
tristate "PCI Endpoint Virtual NTB driver"
depends on PCI_ENDPOINT
depends on NTB
- select CONFIGFS_FS
help
Select this configuration option to enable the Non-Transparent
Bridge (NTB) driver for PCIe Endpoint. NTB driver implements NTB
On Wed, Feb 11, 2026, at 10:05, Niklas Cassel wrote:
> On Wed, Feb 11, 2026 at 08:07:40AM +0100, Arnd Bergmann wrote:
>
> However, I remember that you Arnd was one of the main reasons why Kishon
> decided to use configfs to configure a PCI endpoint controller and to
> bind a PCI endpoint function driver with a PCI endpoint controller.
>
> I don't know of any other way than configfs to bind a PCI endpoint function
> driver with a PCI endpoint controller.
>
> To me, it seems a bit silly to be able to build PCI_ENDPOINT without
> configfs. What should a user do with a library that they cannot bind to
> a PCI endpoint controller?
>
> Why shouldn't we just do something like:
>
> diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
> index 8dad291be8b8..d6f898094509 100644
> --- a/drivers/pci/endpoint/Kconfig
> +++ b/drivers/pci/endpoint/Kconfig
> @@ -8,6 +8,7 @@ menu "PCI Endpoint"
> config PCI_ENDPOINT
> bool "PCI Endpoint Support"
> depends on HAVE_PCI
> + select PCI_ENDPOINT_CONFIGFS
> help
> Enable this configuration option to support configurable PCI
> endpoint. This should be enabled if the platform has a PCI
I think at that point we would instead drop PCI_ENDPOINT_CONFIGFS
as a Kconfig option, since it is never user selectable. Otherwise
this is probably a sensible solution as well.
Arnd
On 2/11/26 18:37, Arnd Bergmann wrote: > On Wed, Feb 11, 2026, at 10:05, Niklas Cassel wrote: >> On Wed, Feb 11, 2026 at 08:07:40AM +0100, Arnd Bergmann wrote: >> >> However, I remember that you Arnd was one of the main reasons why Kishon >> decided to use configfs to configure a PCI endpoint controller and to >> bind a PCI endpoint function driver with a PCI endpoint controller. >> >> I don't know of any other way than configfs to bind a PCI endpoint function >> driver with a PCI endpoint controller. >> >> To me, it seems a bit silly to be able to build PCI_ENDPOINT without >> configfs. What should a user do with a library that they cannot bind to >> a PCI endpoint controller? >> >> Why shouldn't we just do something like: >> >> diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig >> index 8dad291be8b8..d6f898094509 100644 >> --- a/drivers/pci/endpoint/Kconfig >> +++ b/drivers/pci/endpoint/Kconfig >> @@ -8,6 +8,7 @@ menu "PCI Endpoint" >> config PCI_ENDPOINT >> bool "PCI Endpoint Support" >> depends on HAVE_PCI >> + select PCI_ENDPOINT_CONFIGFS >> help >> Enable this configuration option to support configurable PCI >> endpoint. This should be enabled if the platform has a PCI > > > I think at that point we would instead drop PCI_ENDPOINT_CONFIGFS > as a Kconfig option, since it is never user selectable. Otherwise > this is probably a sensible solution as well. +1. That option is mandatory, so it is not an option at all :) If PCI_ENDPOINT is set, we must have configfs. > > Arnd -- Damien Le Moal Western Digital Research
On Fri, Feb 13, 2026 at 08:39:34AM +0900, Damien Le Moal wrote: > > I think at that point we would instead drop PCI_ENDPOINT_CONFIGFS > > as a Kconfig option, since it is never user selectable. Otherwise > > this is probably a sensible solution as well. > > +1. That option is mandatory, so it is not an option at all :) > If PCI_ENDPOINT is set, we must have configfs. A quick git grep: $ git grep PCI_ENDPOINT_CONFIGFS Documentation/PCI/endpoint/pci-ntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: Documentation/PCI/endpoint/pci-ntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: Documentation/PCI/endpoint/pci-test-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: Documentation/PCI/endpoint/pci-test-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: Documentation/PCI/endpoint/pci-vntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: Documentation/PCI/endpoint/pci-vntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: Documentation/nvme/nvme-pci-endpoint-target.rst:CONFIG_PCI_ENDPOINT_CONFIGFS, and CONFIG_NVME_TARGET_PCI_EPF enabled. Documentation/nvme/nvme-pci-endpoint-target.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: arch/arm/configs/multi_v7_defconfig:CONFIG_PCI_ENDPOINT_CONFIGFS=y arch/arm/configs/omap2plus_defconfig:CONFIG_PCI_ENDPOINT_CONFIGFS=y arch/arm64/configs/defconfig:CONFIG_PCI_ENDPOINT_CONFIGFS=y drivers/pci/endpoint/Makefile:obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS) += pci-ep-cfs.o drivers/pci/endpoint/pci-epf-core.c: if (!IS_ENABLED(CONFIG_PCI_ENDPOINT_CONFIGFS)) drivers/pci/endpoint/pci-epf-core.c: if (!IS_ENABLED(CONFIG_PCI_ENDPOINT_CONFIGFS)) include/linux/pci-ep-cfs.h:#ifdef CONFIG_PCI_ENDPOINT_CONFIGFS tools/testing/selftests/pci_endpoint/config:CONFIG_PCI_ENDPOINT_CONFIGFS=y I think we should just merge and send Arnd's fix to Linus for the 7.0 release cycle. If we want to remove CONFIG_PCI_ENDPOINT_CONFIGFS, it will require changes in the docs, defconfigs, etc., so it does seem like something that would have to target 7.1 rather than 7.0. Kind regards, Niklas
On Fri, Feb 13, 2026 at 10:35:24AM +0100, Niklas Cassel wrote: > On Fri, Feb 13, 2026 at 08:39:34AM +0900, Damien Le Moal wrote: > > > I think at that point we would instead drop PCI_ENDPOINT_CONFIGFS > > > as a Kconfig option, since it is never user selectable. Otherwise > > > this is probably a sensible solution as well. > > > > +1. That option is mandatory, so it is not an option at all :) > > If PCI_ENDPOINT is set, we must have configfs. > > A quick git grep: > > $ git grep PCI_ENDPOINT_CONFIGFS > Documentation/PCI/endpoint/pci-ntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: > Documentation/PCI/endpoint/pci-ntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: > Documentation/PCI/endpoint/pci-test-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: > Documentation/PCI/endpoint/pci-test-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: > Documentation/PCI/endpoint/pci-vntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: > Documentation/PCI/endpoint/pci-vntb-howto.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: > Documentation/nvme/nvme-pci-endpoint-target.rst:CONFIG_PCI_ENDPOINT_CONFIGFS, and CONFIG_NVME_TARGET_PCI_EPF enabled. > Documentation/nvme/nvme-pci-endpoint-target.rst:If PCI_ENDPOINT_CONFIGFS is enabled:: > arch/arm/configs/multi_v7_defconfig:CONFIG_PCI_ENDPOINT_CONFIGFS=y > arch/arm/configs/omap2plus_defconfig:CONFIG_PCI_ENDPOINT_CONFIGFS=y > arch/arm64/configs/defconfig:CONFIG_PCI_ENDPOINT_CONFIGFS=y > drivers/pci/endpoint/Makefile:obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS) += pci-ep-cfs.o > drivers/pci/endpoint/pci-epf-core.c: if (!IS_ENABLED(CONFIG_PCI_ENDPOINT_CONFIGFS)) > drivers/pci/endpoint/pci-epf-core.c: if (!IS_ENABLED(CONFIG_PCI_ENDPOINT_CONFIGFS)) > include/linux/pci-ep-cfs.h:#ifdef CONFIG_PCI_ENDPOINT_CONFIGFS > tools/testing/selftests/pci_endpoint/config:CONFIG_PCI_ENDPOINT_CONFIGFS=y > > > I think we should just merge and send Arnd's fix to Linus for the 7.0 > release cycle. > > If we want to remove CONFIG_PCI_ENDPOINT_CONFIGFS, it will require changes > in the docs, defconfigs, etc., so it does seem like something that would > have to target 7.1 rather than 7.0. Are there other undefined references lurking that we just haven't tripped over yet?
On Wed, Feb 18, 2026 at 12:00:27PM -0600, Bjorn Helgaas wrote:
> Are there other undefined references lurking that we just haven't
> tripped over yet?
I guess time (or Arnd's randconfig builds, or kernel test robot) will tell :)
On a more serious note:
I don't think there are any other undefined references caused by my
commit ffcc4850a161 ("PCI: endpoint: pci-epf-test: Allow overriding
default BAR sizes").
Bjorn, btw, is it perhaps possible for you to remove the tag:
pci/for-linus
tag pci/for-linus
Tagger: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon Aug 20 16:37:46 2012 -0600
PCI updates for v3.6:
Power management
- Fix EHCI-related crash during hibernation on ASUS (extension of similar suspend fix we merged in v3.6-rc1) (Rafael Wysocki)
- Clarify D3/D3cold/D4 messages related to runtime D3cold support we added in v3.6-rc1 (Rafael Wysocki)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJQMr2TAAoJEPGMOI97Hn6zcIYP/0GNPqoPWKxummEVZJO4ctZW
l/c1HrsBdh8Yd296wLsI8LFb4ELWL9YYusFxRXjbBiq45QyH50f1n7plq4qxH6gZ
cjf1s2OkMEK3/nh2kXj4FNjFDSAA2vgcTQI8p4M+BcNaKq87hvvT/OQ0iEi4fOul
E9UMrSf1RP9hkHit/pbPm53JARYHNEWoZxc1p8+Dd0I6i6igdRuYDoT8eUYp6l+c
Fw7oR0qmxy6fByqhjKGJjc1rzs/1J7SDPDUzPuMtd6XAUni0+V9gfOl2/YoMzB8H
C5f8OYB4Raoz3uKR/rqNXS8dcxAxkzhtUQQ+CvZ4t7qhQueGI0KZMrJItJyinvQb
NJuaE/7VJJP3/sPtO0X4Q+UPWvMoASswcDyR59NAUroD/WmlGLSg+GiySPC/kn+H
URUeqF2ZlNsQmZNnw2j3g1HD3dipYEAivDIt2Z6CCi0080tokFINAxEibkpCyjB2
WiMKkC6tw5ol9avbRtV6OlJDwbEKSqm+LmwBcTCTz09lUBD1+aMTL+s8SnE9y4aN
AowpRWkKhRyiZsYrRSsiL16wAZZB11ueRWIJ6veA4+KFQxyoVof1IvbmBZ1EEhAU
/AJ7jkPHG4yKfk/K9w7oCCVI4lT7rKTerjzvw1kd8Z4zs0KMfI4TJKBRaDK49gA7
p3b1r1nisHMhPPh1zXal
=2g7M
-----END PGP SIGNATURE-----
commit 10c63c9aec648402f593b6c883ca247ece7b2af9 (tag: pci/for-linus)
Merge: c3e2f79d2d48 8f057d7bca54
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon Aug 20 13:14:22 2012 -0700
Merge tag 'usb-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull more USB patches from Greg Kroah-Hartman:
"Here are 10 more USB patches for 3.6-rc3. They all fix reported
problems (build problems for one of them, and easily repeatable oopses
for the others.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'usb-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
gpu/mfd/usb: Fix USB randconfig problems
USB: CDC ACM: Fix NULL pointer dereference
USB: emi62: remove __devinit* from the struct usb_device_id table
USB: winbond: remove __devinit* from the struct usb_device_id table
USB: vt6656: remove __devinit* from the struct usb_device_id table
USB: rtl8187: remove __devinit* from the struct usb_device_id table
USB: p54usb: remove __devinit* from the struct usb_device_id table
USB: spca506: remove __devinit* from the struct usb_device_id table
USB: jl2005bcd: remove __devinit* from the struct usb_device_id table
USB: smsusb: remove __devinit* from the struct usb_device_id table
It was created in 2012, and looking at the commit which the tag points to,
it is just merge commit from Linus, which is merging the USB tree, so it
does not even seem to correspond to the description of the tag.
The tag is annoying because, if the remote is named pci (which I assume I'm
not alone to name the PCI tree remote as), you will get a warning from git:
warning: refname 'pci/for-linus' is ambiguous.
Because the ref pci/for-linus can mean both your branch (for-linus) and the
ancient tag pci/for-linus.
Since most people why do a git log pci/for-linus wants to see what you have
queued for linus, and since the ancient tag seems bogus anyway, perhaps you
could just remove the tag from the PCI tree?
Kind regards,
Niklas
On Thu, Feb 19, 2026 at 10:02:16AM +0100, Niklas Cassel wrote: > Bjorn, btw, is it perhaps possible for you to remove the tag: > pci/for-linus > > tag pci/for-linus > ... > Since most people why do a git log pci/for-linus wants to see what > you have queued for linus, and since the ancient tag seems bogus > anyway, perhaps you could just remove the tag from the PCI tree? Thanks for reminding me about this. I've tried in the past but was unsuccessful. I tried again and I *think* got it removed. I'm including the details in case I ever need to do this again :) Current pci/for-linus branch in case I delete it by mistake: $ git show --oneline for-linus | cat a7b3343bbb57 PCI: endpoint: pci-epf-test: Select configfs Local pci/for-linus tag: $ git tag -l pci/for-linus | cat pci/for-linus $ cat .git/refs/tags/pci/for-linus b4aef5ce82f1d27e0f14d1f8488dc2db9c22dd38 Delete local tag: $ git tag -d pci/for-linus Deleted tag 'pci/for-linus' (was b4aef5ce82f1) $ cat .git/refs/tags/pci/for-linus cat: .git/refs/tags/pci/for-linus: No such file or directory (os error 2) Delete remote tag: $ git push --delete pci pci/for-linus remote: Recorded in the transparency log remote: manifest: updated /pub/scm/linux/kernel/git/pci/pci.git To ra.kernel.org:/pub/scm/linux/kernel/git/pci/pci.git - [deleted] pci/for-linus Verify: $ git fetch --prune --prune-tags $ git tag -l pci/for-linus | cat <none> $ git fetch pci $ git tag -l pci/for-linus | cat <none>
Hello Bjorn, Since there now is a for-linus branch, is there any chance that we could include: https://lore.kernel.org/linux-pci/20260202145407.503348-3-den@valinux.co.jp/ In the for-linus branch? Otherwise, the new inbound submapping feature in the PCI endpoint framework, that was added in the v7.0 merge window, will be buggy with regards to in-place updates. If we include the above series before v7.0 final, all kernel versions with this new feature will have non-buggy in-place updates. Kind regards, Niklas
On Thu, Feb 19, 2026 at 02:04:20PM +0100, Niklas Cassel wrote: > Hello Bjorn, > > Since there now is a for-linus branch, is there any chance that we could > include: > https://lore.kernel.org/linux-pci/20260202145407.503348-3-den@valinux.co.jp/ > > In the for-linus branch? > > Otherwise, the new inbound submapping feature in the PCI endpoint > framework, that was added in the v7.0 merge window, will be buggy > with regards to in-place updates. > > If we include the above series before v7.0 final, all kernel > versions with this new feature will have non-buggy in-place updates. The URL you mentioned is for "[PATCH v2 2/2] PCI: dwc: ep: Always clear IB maps on BAR update", but here you mention "the above *series*". Do we need both commits of that series?
On Thu, Feb 19, 2026 at 10:13:48AM -0600, Bjorn Helgaas wrote: > On Thu, Feb 19, 2026 at 02:04:20PM +0100, Niklas Cassel wrote: > > Since there now is a for-linus branch, is there any chance that we could > > include: > > https://lore.kernel.org/linux-pci/20260202145407.503348-3-den@valinux.co.jp/ > > > > In the for-linus branch? > > The URL you mentioned is for "[PATCH v2 2/2] PCI: dwc: ep: Always > clear IB maps on BAR update", but here you mention "the above > *series*". Do we need both commits of that series? Yes, sorry that I linked to 2/2 instead of the cover-letter (0/2): https://lore.kernel.org/linux-pci/20260202145407.503348-1-den@valinux.co.jp/ If possible, I think it would be nice if we could queue both patches in the series for-linus: [PATCH v2 0/2] PCI: dwc: ep: Fix BAR update handling with in-place epf_bar reuse Even if the first patch mainly avoid pointless execution of code, it also helped us realize that patch 2/2 was needed in the first place. Kind regards, Niklas
On 2/11/26 16:07, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Like some of the other endpoint modules, this one now also
> uses configfs, but is missing an indication in Kconfig:
>
> arm-linux-gnueabi-ld: drivers/pci/endpoint/functions/pci-epf-test.o: in function `pci_epf_test_add_cfs':
> pci-epf-test.c:(.text.pci_epf_test_add_cfs+0x2c): undefined reference to `config_group_init_type_name'
>
> Select the symbol as needed.
>
> Fixes: ffcc4850a161 ("PCI: endpoint: pci-epf-test: Allow overriding default BAR sizes")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
--
Damien Le Moal
Western Digital Research
© 2016 - 2026 Red Hat, Inc.