linux-kernel - Re: [PATCH] mfd/wm831x-irq: Convert to new irq

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 10 Dec 2010 12:14:21 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Huewe <peterhuewe@....de>,
	Ian Lartey <ian@...nsource.wolfsonmicro.com>,
	Dimitris Papastamos <dp@...nsource.wolfsonmicro.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mfd/wm831x-irq: Convert to new irq_chip functions and
 fix build failure

On Fri, Dec 10, 2010 at 02:07:55PM +0900, Paul Mundt wrote:
> On Fri, Dec 10, 2010 at 02:39:55AM +0100, Thomas Gleixner wrote:
> > On Fri, 10 Dec 2010, Mark Brown wrote:

> > > The driver has already been converted; if this is required we should
> > > just backport the relevant change (mfd: Convert WM831x to new irq_
> > > interrupt methods) in order to avoid merge issues with current code
> > > rather than reimplementing. However, at this stage in 2.6.37 I don't
> > > think that's a good idea.

> > I think it is.

> > # git grep GENERIC_HARDIRQS_NO_DEPRECATED arch/
> > arch/sh/Kconfig:        select GENERIC_HARDIRQS_NO_DEPRECATED

Oh dear.  Can anyone comment on why SH is selecting this?  My first
thought is that the savings from enabling it are going to be on the
small side so it wouldn't be a big issue to leave it off for 2.6.37
and possibly 2.6.38 also.

If we're going to start enabling this on platforms I'd also suggest that
we enable it on x86 in -next so that we get reasonable coverage from
build tests.  It needs to be enabled on a major architecture to catch
the change during development.

> > Though the question remains, whether this driver is actually used with
> > sh platforms. If yes, then pushing the already existing change to

It's not just this driver - I'd expect everything with an interrupt
controller in drivers/mfd to have an issue here, and I don't think
disabling them all on SH for this release is such a good approach.

> > Linus is the right way to go. If no, adding a "depends on !SH" is the
> > simple fix to prevent this allmodconfig fallout. Another option is to
> > ignore it :) I leave that up to Paul.

> There are no current SH boards that are using this MFD, but there's
> certainly no technical reason for why there can't be. I'd rather avoid an
> artificial !SH dependency, but adding in something like

> 	depends on !GENERIC_HARDIRQS_NO_DEPRECATED

> for .37 would be fine. We do build randconfigs and so on quite regularly,
> so it would obviously be nice not to have this break the build.

I'd rather not do that, certainly not for everything.
--
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/