Re: [PATCH net] net: macb: Move macb_{alloc,free}_tieoff() out of CONFIG_OF block

On Wed Aug 19, 2026 at 8:54 PM CEST, Nathan Chancellor wrote:

On Wed, Aug 19, 2026 at 08:06:48PM +0200, Théo Lebrun wrote:

quoted

On Wed Aug 19, 2026 at 3:14 AM CEST, Nathan Chancellor wrote:

quoted

Commit 5262eab9462a ("net: macb: allocate tieoff descriptor once across
device lifetime") moved macb_alloc_tieoff() and macb_free_tieoff() into
a CONFIG_OF block, breaking the build when it is disabled:

That commit message is somewhat off: the commit created the two
functions, it didn't move them around. But indeed I was wrong in the

Oh correct, I misread macb_init_tieoff() as macb_alloc_tieoff() so
considered it a "move" but "placed" would definitely be more accurate.

quoted

location where I created them (argh I hate #if/ifdef blocks, especially
long ones).

Yeah, I had to grep for the pairs because this one was so big.

quoted

Can reproduce using my host toolchain easily:

   ⟩ unset ARCH CROSS_COMPILE
   ⟩ make mrproper
   ⟩ make defconfig
   ⟩ ./scripts/config -e COMMON_CLK -e MACB
   ⟩ make olddefconfig
   ⟩ make drivers/net/ethernet/cadence/
   ⟩ echo $?
   2

Yup, same exact reproducer I used.

quoted

Here is an alternative fix proposal: let's drop the #ifdef. It will
avoid any future error. Almost all drivers have no #ifdef as such:

⟩ git grep -l MODULE_DEVICE_TABLE drivers/ | wc -l
7458
⟩ git grep -l MODULE_DEVICE_TABLE drivers/ | xargs git grep -l CONFIG_OF | wc -l
391

Yes, I know this means the match table land in the module in !OF case.
Almost everyone on the ML I've seen seem to consider that it's trivial.
Apparently it's even useful because some ACPI can match on compatible,
somehow.

Opinions?

I am always in favor of dropping #ifdefs to make it easier to avoid
compile issues like this. If that is the route we want to go, please
feel free to send a patch for it (or I can if you prefer).

Done. Just sent now and noticed I forgot CCing you, sorry!
https://lore.kernel.org/netdev/20260820-macb-fix-x86-v1-1-b2e7c902104e@bootlin.com/ (local)

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com