On Tue, 17 Jan 2012, Andrew Jones wrote: > > > For instance, Why would CONFIG_EXPERT disable by default some HID devices? > > > I could understand why it is done for CONFIG_EMBEDDED, but certainly not > > > for an general EXPERT option. > > > > > > > Then this is a prime example that you've identified were it would make > > sense to have the default value be dependant on EMBEDDED rather than > > EXPERT. Feel free to send a patch to the HID maintainers. > > > > How would you propose to write this patch? You say the default value > should be dependant on EMBEDDED, instead of EXPERT? So maybe something > like > > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig > index a421abd..73c2d39 100644 > --- a/drivers/hid/Kconfig > +++ b/drivers/hid/Kconfig > @@ -63,7 +63,7 @@ menu "Special HID drivers" > config HID_A4TECH > tristate "A4 tech mice" if EXPERT > depends on USB_HID > - default !EXPERT > + default !EMBEDDED > ---help--- > Support for A4 tech X5 and WOP-35 / Trust 450L mice. > > and the other HID drivers... > Um, no, HID_A4TECH is still only configurable for CONFIG_EXPERT with this patch. Jerome's premise is that this should be configurable for CONFIG_EMBEDDED instead. Please read what he wrote. When it's configurable only for CONFIG_EMBEDDED, then you can propose that to the HID maintainers. If they agree, then we don't care if users currently with CONFIG_EXPERT=y and CONFIG_EMBEDDED=n lose the option, but that needs to be handled on a case-by-case basis when breaking backwards compatibility. > I guess it could be changed to 'if EXPERT || EMBEDDED', but at the moment > EMBEDDED selects EXPERT, so that's not currently necessary. I guess what's > above should be sufficient then. Oh, wait! That's exactly what this patch > does! And anybody who actually read it would have seen that. > One of many reasons why it's completely wrong, and is nacked. > BTW, the HID maintainer, Jiri Kosina, is already on cc, since I cc'ed > every maintainer of the files that this patch touches. > That type of attitude is a great way for your patches to be lost in oblivion, you can't expect everyone on the cc list to be actively reading this thread. I've considered not reading it myself since it's pretty pointless. If you wish to submit kconfig patches for options that touch specific subsystems, you'll need to separate them out and propose them to the individual subsystem maintainers. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
