Re: [PATCH 3/4] dw_dmac: make build of DT related methods optional

[Arnd Bergmann]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/