On Monday 25 March 2013, Andy Shevchenko wrote:
> > I generally prefer to have all driver code be compiled all the time
> > to catch build regressions independent of the configuration, and leave
> > the #ifdefs in header files that provide the interfaces.
>
> I don't. For checking we have special make targets:
>
> allnoconfig - New config where all options are answered with no
> allyesconfig - New config where all options are accepted with yes
> allmodconfig - New config selecting modules when possible
> alldefconfig - New config with all symbols set to default
That will only help on architectures that support CONFIG_OF, although
that probably includes all the common ones except s390 and ia64 nowadays.
> > if (IS_ENABLED(CONFIG_OF)) && pdev->dev.of_node) {
> > err = of_dma_controller_register(pdev->dev.of_node,
> > dw_dma_of_xlate, dw);
> > if (err)
> > dev_err(&pdev->dev,
> > "could not register of_dma_controller\n");
> > }
> >
> > Or alternatively, we can change the of_dma_controller_register() stub to
> > return 0 if CONFIG_OF is disabled. That would also take care of similar
> > code in other dma engine drivers.
>
> Actually to be aligned with other dmaengine code it should return
> -ENOSYS. And by description ENOSYS seems suitable for "not implemented"
> cases.
I think we use ENOSYS normally when the absence of the interface is
a fatal error, which it would not be here. This case I think is more
like the clk and regulator interfaces, where you want to bail out
if the functions return an actual error but not if the subsystem is
compiled out.
> What about to move all CONFIG_OF stuff into separate file?
Seems not worth it, and still would lead to the code not being
compile tested by default. Right now, there are two small functions,
and I would hope we can turn that into a single even smaller
function eventually if we get right of the silly requirement to
go through a filter function here.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
