staging: gpib: Fix allyesconfig build failures

My tests run an allyesconfig build and it failed with the following errors:

LD [M] samples/kfifo/dma-example.ko
ld.lld: error: undefined symbol

staging: gpib: Fix allyesconfig build failures

My tests run an allyesconfig build and it failed with the following errors:

LD [M] samples/kfifo/dma-example.ko
ld.lld: error: undefined symbol: nec7210_board_reset
ld.lld: error: undefined symbol: nec7210_read
ld.lld: error: undefined symbol: nec7210_write

It appears that some modules call the function nec7210_board_reset()
that is defined in nec7210.c. In an allyesconfig build, these other
modules are built in. But the file that holds nec7210_board_reset()
has:

obj-m += nec7210.o

Where that "-m" means it only gets built as a module. With the other
modules built in, they have no access to nec7210_board_reset() and the build
fails.

This isn't the only function. After fixing that one, I hit another:

ld.lld: error: undefined symbol: push_gpib_event
ld.lld: error: undefined symbol: gpib_match_device_path

Where push_gpib_event() was also used outside of the file it was defined
in, and that file too only was built as a module.

Since the directory that nec7210.c is only traversed when
CONFIG_GPIB_NEC7210 is set, and the directory with gpib_common.c is only
traversed when CONFIG_GPIB_COMMON is set, use those configs as the
option to build those modules. When it is an allyesconfig, then they
will both be built in and their functions will be available to the other
modules that are also built in.

Fixes: 3ba84ac69b53e ("staging: gpib: Add nec7210 GPIB chip driver")
Fixes: 9dde4559e9395 ("staging: gpib: Add GPIB common core driver")
Signed-off-by: Steven Rostedt (Google) <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

staging: gpib: fix Makefiles

Having gpib drivers built-in rather than as loadable modules causes
link failure because the drivers are never actually built:

arm-linux-gnueabi-ld: drivers/staging/gpi

staging: gpib: fix Makefiles

Having gpib drivers built-in rather than as loadable modules causes
link failure because the drivers are never actually built:

arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_t1_delay':
fmh_gpib.c:(.text+0x3b0): undefined reference to `nec7210_t1_delay'
arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_serial_poll_status':
fmh_gpib.c:(.text+0x418): undefined reference to `nec7210_serial_poll_status'
arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_secondary_address':
fmh_gpib.c:(.text+0x57c): undefined reference to `nec7210_secondary_address'
arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_primary_address':
fmh_gpib.c:(.text+0x5ac): undefined reference to `nec7210_primary_address'

Change this to use the correct Makefile syntax, setting either obj-m or obj-y.

Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

staging: gpib: Add GPIB common core driver

This is the common core driver that interfaces with the userland code
and creates the gpib device files.

Signed-off-by: Dave Penkler <[email protected]>

staging: gpib: Add GPIB common core driver

This is the common core driver that interfaces with the userland code
and creates the gpib device files.

Signed-off-by: Dave Penkler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...