Messages in this thread | | | From | Mike Frysinger <> | Date | Mon, 12 Oct 2009 11:09:13 -0400 | Subject | Re: [origin tree build failure] [PATCH] Revert "USB: musb: make HAVE_CLK support optional" |
| |
On Mon, Oct 12, 2009 at 11:00, Ingo Molnar wrote: > * Mike Frysinger <vapier.adi@gmail.com> wrote: >> On Mon, Oct 12, 2009 at 10:29, Greg KH wrote: >> > On Mon, Oct 12, 2009 at 09:05:57AM -0400, Mike Frysinger wrote: >> >> On Mon, Oct 12, 2009 at 03:42, Ingo Molnar wrote: >> >> > >> >> > * Linus Torvalds <torvalds@linux-foundation.org> wrote: >> >> > >> >> >> As usual, please test this for regressions, both new and old. >> >> > >> >> >> USB: musb: make HAVE_CLK support optional >> >> > >> >> > This USB/Blackfin commit broke the x86 build with these config options: >> >> > >> >> > CONFIG_USB_MUSB_HDRC=y >> >> > CONFIG_USB_MUSB_HOST=y >> >> > # CONFIG_USB_MUSB_PERIPHERAL is not set >> >> > # CONFIG_USB_MUSB_OTG is not set >> >> > # CONFIG_USB_GADGET_MUSB_HDRC is not set >> >> > CONFIG_USB_MUSB_HDRC_HCD=y >> >> > CONFIG_MUSB_PIO_ONLY=y >> >> > CONFIG_USB_MUSB_DEBUG=y >> >> > >> >> > Because a side-effect of the patch was that it enabled the driver on x86 >> >> > too which doesnt have HAVE_CLK. So this formerly embedded-only driver >> >> > got exposed on the more widely tested x86 platform. >> >> >> >> this is dumb. you're addressing unrealistic scenarios (randconfig) by >> >> reverting code for realistic scenarios. how about updating the >> >> already present arch depend string instead. >> > >> > We want 'randconfig' to work, so this is not unrealistic. Have you not >> > seen Randy Dunlap's zillion patches to get this to all work properly >> > over the past months? >> >> i'm not suggesting it not be fixed, i'm suggested it be *fixed* >> instead of blindly reverted. > > Sure, i'd agree with that if we were in the merge window. The thing is, > -rc4 is not the time to do patches that need fixes. It is to fix > regressions. I dont think this commit applies as a regression fix, does > it? It _introduces_ a regression. > > So a revert is a proper first-level response to this and i fail to > understand your surprise about that. A fix is nice too, of course, if > it's simple enough.
if the change were non-trivial and/or the person making the change were unresponsive, then a revert would certainly make sense this late in the game. but neither really apply here. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |