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

[Paul Mundt <lethal@linux-sh.org>]

On Fri, Dec 10, 2010 at 06:24:55PM +0000, Mark Brown wrote:
> On Sat, Dec 11, 2010 at 02:48:43AM +0900, Paul Mundt wrote:
> 
> > I have no intention of dropping the select from SH, but I'm not going to
> > insist that these drivers have the deprecated dependency if we're a) not
> > really using them and b) there's a reasonable expectation that they'll
> > basically be taken care of in .38 anyways.
> 
> That's unfortunate, I'm a bit concerned about support for users picking
> up the kernel and using it to build products.
> 
As I pointed out initially, backtracking would only encourage people to
continue to add new code that uses deprecated interfaces. This happens
time and time again, and is a far greater concern.

> Samuel, would you be OK with cherry picking the relevant commits to the
> Wolfson drivers back into .37?  I'm especially concerned about WM8994
> here - I'd really not like to see a kernel version go out where that
> doesn't work.
> 
That hardly addresses the issue, and simply covers your own driver. The
issue at hand is whether it's worth flagging the deprecated API users
with an explicit dependency or not. You've dismissed the idea of getting
your dependencies right out of hand, but also don't wish to ship a broken
driver, so we need an alternative.

After a full tree audit it's the MFD drivers and a couple of GPIO
expanders that could theoretically be enabled and break the build. I
suppose I could switch to

	select GENERIC_HARDIRQS_NO_DEPRECATED if !MFD_SUPPORT && !GPIOLIB

for .37 since it's too late to convert the remaining drivers now.
Conditionalizing it will at least limit the number of platforms where the
old API is visible.

> > I haven't been following the progress in -next, but now that you've
> > pointed it out I'll give it a look. It's less effort to just fix up the
> > remaining users than it is to audit API dependencies for all of them at
> > least.
> 
> Probably slightly more in that you can't just blindly add the dependency
> when you see the problem but yeah.

At what point is a dependency being "blindly" added? The patch provided
was meant as a stop-gap for .37 so that the drivers using the deprecated
API have an explicit dependency on it. For .38 it's trivial to convert
them, and as I've done pretty much all of the conversion work that's
upstream right now I don't think you're in much position to say what has
and hasn't been thought out.