On Wed, 22 Jun 2011 00:02:42 +0100 Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Jun 21, 2011 at 01:48:05PM -0700, Dmitry Torokhov wrote: > > On Tue, Jun 21, 2011 at 06:27:45PM +0100, Mark Brown wrote: > > > > Right, but this is something that it's not reasonable to implement in > > > board code - if nothing else implementing it in board code would mean > > > we'd got lots of repitition of common patterns. > > > I agree here. I just disagree that we should be implementing this in > > driver core by having special -EAGAIN handling. Having a common > > library-like code (probably tied to device-tree) that handles device > > dependencies would be great. > > Ah, that's more OK then. I'm not entirely sure about the -EAGAIN > proposal but it does seem to have some advantages in terms of > deployment. > > > Ah, OK, so we basically in agreement here with the exception that I do > > not want the band-aid to hit mainline since it takes the heat off people > > who need inter-device dependency to actually work. > > > Can the initcall stuff be kept out of mainline? I'd expect > > The init order stuff is in mainline already, you're far too late to the > party here. > > > there exist board-specific trees where such patches could be kept? Or > > maybe interested parties could create board-crap tree to store patches > > like this one? > > Keeping things in board trees is exactly the sort of thing we want to > avoid people doing. That just means people do all sorts of stuff that > wouldn't be acceptable upstream, either out of ignorance or through > knowing that only their systems have to work with what they're doing, > and just don't bother working upstream at all half the time making life > miserable for pretty much everyone. Looks like we all agree then? Dmitry, would you consider the late_initcall() part of the hack now (temporarily)? Best regards, -- David Jander Protonic Holland. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
