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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201303252209.30634.arnd@arndb.de>
Date:	Mon, 25 Mar 2013 22:09:30 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	linux-kernel@...r.kernel.org,
	"spear-devel" <spear-devel@...t.st.com>
Subject: Re: [PATCH 3/4] dw_dmac: make build of DT related methods optional

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