Re: [PATCH] mfd/wm831x-irq: Convert to new irq_chip functions and fix build failure

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.