Skip to content

misc: Kconfig: ensure adi-axi-data-offload.c compiled as module #2931

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
+4 −23
Closed

misc: Kconfig: ensure adi-axi-data-offload.c compiled as module #2931

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
e46c7cd
iio: frequency: CF_AXI_DDS depends on ADI_AXI_DATA_OFFLOAD
gastmaier Sep 8, 2025
dc65546
misc: Kconfig: ensure adi-axi-data-offload.c compiled as module
gastmaier Sep 8, 2025
db68661
arch: arm: configs: zynq_m2k_defconfig: Enable ADI_AXI_DATA_OFFLOAD
gastmaier Sep 9, 2025
8cc6ed0
arch: arm: configs: zynq_pluto_defconfig: Enable ADI_AXI_DATA_OFFLOAD
gastmaier Sep 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions drivers/iio/frequency/Kconfig
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,7 @@ config CF_AXI_DDS
tristate "Analog Devices CoreFPGA AXI DDS driver"
depends on SPI
depends on COMMON_CLK
depends on ADI_AXI_DATA_OFFLOAD
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I think this is only because we dropped the stubs for the methods you mention in the commit message. AFAIR, data offloading is an optional feature so I think depending on it is "too much".

We might need something better than #ifdef CONFIG_ADI_AXI_DATA_OFFLOAD though

Copy link
Contributor Author

@gastmaier gastmaier Sep 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, this is only required because we made this way, we added the methods directly in the axi dds driver and used a define in the include of the offload to make it optional, but this approach doesn't work with tristates.
it needs to be done through ops, where the offload pointer is acquired during runtime.
the focus of the pr is to allow the offload to be compiled as a module

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I guess the original author indeed did not wanted it to be compiled as a module :).

but this approach doesn't work with tristates

Why not? Can't we use IS_REACHABLE() or something like that? And compromise that it won't be available if the DDS is builtin but OFFLOAD is a module?

Anyways, I'm not 100% happy that we now depend on an "optional" feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we can use IS_REACHABLE in this driver to fallback . making it only compatible with built-in offload for now, or discard this pr and keep built-in only
.

select IIO_BUFFER_DMAENGINE
help
Say yes here to build support for Analog Devices DDS chip
Expand Down