linux-kernel - Re: [PATCH] misc: sram: remove useless #ifdef

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161129233021.2o7hm7cp3abca5sc@piout.net>
Date:   Wed, 30 Nov 2016 00:30:21 +0100
From:   Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        "David S. Miller" <davem@...emloft.net>,
        Marcin Wojtas <mw@...ihalf.com>,
        Vladimir Zapolskiy <vz@...ia.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] misc: sram: remove useless #ifdef

On 29/11/2016 at 21:01:53 +0100, Greg Kroah-Hartman wrote :
> On Tue, Nov 29, 2016 at 08:54:00PM +0100, Alexandre Belloni wrote:
> > On 29/11/2016 at 20:41:54 +0100, Greg Kroah-Hartman wrote :
> > > On Tue, Nov 22, 2016 at 03:30:54PM +0100, Arnd Bergmann wrote:
> > > > A recent patch added a new function that is now unused whenever
> > > > CONFIG_OF is disabled:
> > > > 
> > > > drivers/misc/sram.c:342:12: error: 'atmel_securam_wait' defined but not used [-Werror=unused-function]
> > > > 
> > > > There is actually no reason for the #ifdef, because the driver
> > > > currently cannot be used in a meaningful way without CONFIG_OF,
> > > > and there is no compile-time dependency.
> > > > 
> > > > Removing that #ifdef and the respective of_match_ptr() avoids the
> > > > warning and simplifies the driver slightly.
> > > > 
> > > > Fixes: 2ae2e28852f2 ("misc: sram: add Atmel securam support")
> > > 
> > > What tree is this commit in?  I can't seem to find it in one of mine, am
> > > I just missing it somewhere?
> > > 
> > 
> > It is in arm-soc (it went through the mach-at91 tree)
> 
> Ah, ok, nothing I can do about it then, nice!

Yeah, I was thinking Arnd would take it directly.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com