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
| ||
|
Date: Mon, 20 Dec 2010 01:29:17 +0100 From: Samuel Ortiz <sameo@...ux.intel.com> To: Paul Mundt <lethal@...ux-sh.org> Cc: Mark Brown <broonie@...nsource.wolfsonmicro.com>, Thomas Gleixner <tglx@...utronix.de>, Peter Huewe <peterhuewe@....de>, Ian Lartey <ian@...nsource.wolfsonmicro.com>, Dimitris Papastamos <dp@...nsource.wolfsonmicro.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] mfd/wm831x-irq: Convert to new irq_chip functions and fix build failure Hi Paul, On Sat, Dec 11, 2010 at 10:59:08AM +0900, Paul Mundt wrote: > 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. I see that you've pushed this one, thanks a lot. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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/
Powered by blists - more mailing lists