Re: 2.6.23-git Kconfig regression
On Thursday 17 January 2008, Jan Beulich wrote: > >This stuff isn't for "distro" kernels; it's for embedded > >environments of the "only this hardware exists" sort. > >Space matters, and having small code matters. Nobody has > >been interested enough in an "embedded distro" model to > >provide patches enabling such stuff. > > Why not make the whole thing depend on EMBEDDED then? Because while its design center is small systems, there's actually no technical dependency there. The Kconfig for EMBEDDED also says it's for disabling or tweaking standard settings ... ergo, not *adding* subsystems or drivers. Oddly enough, most things that work on small systems can also be used on bigger ones. :) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
>>> David Brownell <[EMAIL PROTECTED]> 17.01.08 01:02 >>> >On Wednesday 16 January 2008, Jan Beulich wrote: >> >>> Randy Dunlap <[EMAIL PROTECTED]> 20.10.07 05:21 >>> >> >> Sorry for only now getting back to this. >> >> >On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote: >> > >> ... >> >> I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really >> written properly: > >That's orthogonal to whether that patch caused a regression, >of course. The operational semantics have, except when they >were changed, been that it did what it needed to do. > > >> These prompt-less items should go after the choice (resulting >> in the choice to become a boolean one), > >Maybe -- such a change would have been OK as part of the patch >which changed the operational semantics of Kconfig. I simply wasn't aware of dependencies on the hierarchy re-ordering done inside menu_finalize() within choices, which is what broke this. And I'm not convinced this hierarchy re-ordering is even fully consistent in its current shape (i.e. it just happens to work for the few cases it really is used in). >>... >> these options are just pointless except for avoiding >> >> #if defined(CONFIG_...) || defined(CONFIG_..._MODULE)' >> >> in C sources. > >Well, avoiding such error-prone idioms would seem good to me. >They're common enough, and nasty. But that's not why those >mechanisms are there. But nevertheless there are CONFIG_USB_GADGET_* dependencies in sources. But in a draft re-write of that Kconfig I found an easy way to keep these anyway, so the point isn't a concern to me anymore. >> In that latter case, the choice could become a tristate >> one, allowing all of the selections to be built at once as modules >> (which really seems to be the way distro kernels would want to use >> it) or any one of them to be built in (the current behavior, except >> that at present even when using these as a module only a single >> one can be selected). > >The requirements are that (a) just one peripheral controller >driver be selectable, and (b) that it be linked either >statically or dynamically. Related, that for the gadget >drivers (c) none may be selected until the peripheral >controller driver they'll be used with is known, and either >(d1) one may be statically linked, or else (d2) any number >may be built as modules, with only one loaded at a time. So I'll keep it that way. >This stuff isn't for "distro" kernels; it's for embedded >environments of the "only this hardware exists" sort. >Space matters, and having small code matters. Nobody has >been interested enough in an "embedded distro" model to >provide patches enabling such stuff. Why not make the whole thing depend on EMBEDDED then? Or is development for this perhaps being done in non-embedded environments? Thanks for the clarification in any case, now I just needs Roman's opinion on the re-ordering issue in order to come up with a revised patch. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Thursday 17 January 2008, Jan Beulich wrote: This stuff isn't for distro kernels; it's for embedded environments of the only this hardware exists sort. Space matters, and having small code matters. Nobody has been interested enough in an embedded distro model to provide patches enabling such stuff. Why not make the whole thing depend on EMBEDDED then? Because while its design center is small systems, there's actually no technical dependency there. The Kconfig for EMBEDDED also says it's for disabling or tweaking standard settings ... ergo, not *adding* subsystems or drivers. Oddly enough, most things that work on small systems can also be used on bigger ones. :) - Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Wednesday 16 January 2008, Jan Beulich wrote: > >>> Randy Dunlap <[EMAIL PROTECTED]> 20.10.07 05:21 >>> > > Sorry for only now getting back to this. > > >On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote: > > > ... > > I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really > written properly: That's orthogonal to whether that patch caused a regression, of course. The operational semantics have, except when they were changed, been that it did what it needed to do. > These prompt-less items should go after the choice (resulting > in the choice to become a boolean one), Maybe -- such a change would have been OK as part of the patch which changed the operational semantics of Kconfig. For better or worse, operational semantics are most of what we have to go by here. It would be nice if they were cleanly and clearly specified, like a Prolog engine ... just a simple little tristate logic engine, provably correct, with some UI wrappers. But that's not what we have today. > these options are just pointless except for avoiding > > #if defined(CONFIG_...) || defined(CONFIG_..._MODULE)' > > in C sources. Well, avoiding such error-prone idioms would seem good to me. They're common enough, and nasty. But that's not why those mechanisms are there. > In that latter case, the choice could become a tristate > one, allowing all of the selections to be built at once as modules > (which really seems to be the way distro kernels would want to use > it) or any one of them to be built in (the current behavior, except > that at present even when using these as a module only a single > one can be selected). The requirements are that (a) just one peripheral controller driver be selectable, and (b) that it be linked either statically or dynamically. Related, that for the gadget drivers (c) none may be selected until the peripheral controller driver they'll be used with is known, and either (d1) one may be statically linked, or else (d2) any number may be built as modules, with only one loaded at a time. This stuff isn't for "distro" kernels; it's for embedded environments of the "only this hardware exists" sort. Space matters, and having small code matters. Nobody has been interested enough in an "embedded distro" model to provide patches enabling such stuff. > The second choice appears suspicious altogether - is it really that > just any one of these items can be selected to be built into the > kernel? Yes. We may want to change that requirement at some point, but as a rule there can be no more than one upstream USB link in systems certified as USB conformant. Most hardware doesn't even allow it. Certainly, *right now* we don't support multiple upstream links, and that's been true for as long as that driver stack has existed. - Dave > Bottom line is, in order to suggest an appropriate adjustment to this > Kconfig file I need clarification on its intentions. Meanwhile I'll scan > the tree for other suspicious choices... > > Thanks, Jan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
>>> Randy Dunlap <[EMAIL PROTECTED]> 20.10.07 05:21 >>> Sorry for only now getting back to this. >On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote: > >> On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote: >> >> > >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig; >> > >>> it seems to be quite recent. >> > >>> >> > >>> ... >> > >> Hm, it does look very odd. It looks like it has something to >> > >> do with working differently for some reason. >> > >> >> > >> In xconfig, I set all of the View Options and when I click on one >> > >> of the periph. controllers, it says >> > >> >> > >> depends on =y && PCI >> > > >> > > That's what I saw too. Looked dubious ... >> > > >> > > >> > >> but if I back up to -git7, it says >> > >> >> > >> depends on && PCI >> > > >> > > And that git7 thing doesn't look _quite_ so odd. Did git7 actually But it still doesn't look like it ought to be that way. Still, I'll try to make this display e.g. =y instead. >> > > let you configure a modular GOKU (for example), i.e. work correctly? >> > >> > Yes, -git9 does. >> > >> > Looks to me like it broke on -git10. -git9 is OK. >> > >> > >> I'll keep looking. >> > > >> > > Thanks. Kconfig is one of the areas I prefer to let others >> > > be the experts. :) >> >> [hm, odd email problems, changing SMTP] >> >> David, >> >> Just a small update. >> >> If I set USB gadget support to Y instead of M and peripheral >> controller menu item to Y instead of M, then I can select any of the >> 4 periph. controllers that are available to me. (on -git14) >> I don't know why it's like this though. > >David, > >My (quick, meaning that I may have missed something) testing >indicates that the problem is in the patches attached. > >Can you revert them and test that? > >From git: >http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a5bf3d891a6a0fb5aa122792d965e3774108b923 > > >Change kconfig behavior so that mixing bool and tristate config settings in >a choice is possible and has the desired effect of offering just the >tristate options individually if the choice gets set to M, and a normal >boolean selection if the choice gets set to Y. > >Odd, I don't recall seeing this patch... I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really written properly: The first choice contains a mixture of boolean and tristate values; all of the tristate ones are auto-select values (i.e. such with no prompt), which results in all of them being unavailable when the choice itself is set to M (the default with the patch - previously, the choice type got derived from just the first contained value's type, which was clearly wrong). These prompt-less items should go after the choice (resulting in the choice to become a boolean one), if they're needed at all (I think, especially with the intended change, these options are just pointless except for avoiding #if defined(CONFIG_...) || defined(CONFIG_..._MODULE)' in C sources. In that latter case, the choice could become a tristate one, allowing all of the selections to be built at once as modules (which really seems to be the way distro kernels would want to use it) or any one of them to be built in (the current behavior, except that at present even when using these as a module only a single one can be selected). The second choice appears suspicious altogether - is it really that just any one of these items can be selected to be built into the kernel? And again, there are items inside that choice that really seem to belong outside - I think this is an abuse of the choice construct, which just happened to work when the choice type (as described above) was derived from only its first contained value. Bottom line is, in order to suggest an appropriate adjustment to this Kconfig file I need clarification on its intentions. Meanwhile I'll scan the tree for other suspicious choices... Thanks, Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
Randy Dunlap [EMAIL PROTECTED] 20.10.07 05:21 Sorry for only now getting back to this. On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote: On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote: I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. ... Hm, it does look very odd. It looks like it has something to do with choice working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y PCI That's what I saw too. Looked dubious ... but if I back up to -git7, it says depends on choice PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually But it still doesn't look like it ought to be that way. Still, I'll try to make this display e.g. choice=y instead. let you configure a modular GOKU (for example), i.e. work correctly? Yes, -git9 does. Looks to me like it broke on -git10. -git9 is OK. I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) [hm, odd email problems, changing SMTP] David, Just a small update. If I set USB gadget support to Y instead of M and peripheral controller menu item to Y instead of M, then I can select any of the 4 periph. controllers that are available to me. (on -git14) I don't know why it's like this though. David, My (quick, meaning that I may have missed something) testing indicates that the problem is in the patches attached. Can you revert them and test that? From git: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a5bf3d891a6a0fb5aa122792d965e3774108b923 Change kconfig behavior so that mixing bool and tristate config settings in a choice is possible and has the desired effect of offering just the tristate options individually if the choice gets set to M, and a normal boolean selection if the choice gets set to Y. Odd, I don't recall seeing this patch... I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really written properly: The first choice contains a mixture of boolean and tristate values; all of the tristate ones are auto-select values (i.e. such with no prompt), which results in all of them being unavailable when the choice itself is set to M (the default with the patch - previously, the choice type got derived from just the first contained value's type, which was clearly wrong). These prompt-less items should go after the choice (resulting in the choice to become a boolean one), if they're needed at all (I think, especially with the intended change, these options are just pointless except for avoiding #if defined(CONFIG_...) || defined(CONFIG_..._MODULE)' in C sources. In that latter case, the choice could become a tristate one, allowing all of the selections to be built at once as modules (which really seems to be the way distro kernels would want to use it) or any one of them to be built in (the current behavior, except that at present even when using these as a module only a single one can be selected). The second choice appears suspicious altogether - is it really that just any one of these items can be selected to be built into the kernel? And again, there are items inside that choice that really seem to belong outside - I think this is an abuse of the choice construct, which just happened to work when the choice type (as described above) was derived from only its first contained value. Bottom line is, in order to suggest an appropriate adjustment to this Kconfig file I need clarification on its intentions. Meanwhile I'll scan the tree for other suspicious choices... Thanks, Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Wednesday 16 January 2008, Jan Beulich wrote: Randy Dunlap [EMAIL PROTECTED] 20.10.07 05:21 Sorry for only now getting back to this. On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote: ... I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really written properly: That's orthogonal to whether that patch caused a regression, of course. The operational semantics have, except when they were changed, been that it did what it needed to do. These prompt-less items should go after the choice (resulting in the choice to become a boolean one), Maybe -- such a change would have been OK as part of the patch which changed the operational semantics of Kconfig. For better or worse, operational semantics are most of what we have to go by here. It would be nice if they were cleanly and clearly specified, like a Prolog engine ... just a simple little tristate logic engine, provably correct, with some UI wrappers. But that's not what we have today. these options are just pointless except for avoiding #if defined(CONFIG_...) || defined(CONFIG_..._MODULE)' in C sources. Well, avoiding such error-prone idioms would seem good to me. They're common enough, and nasty. But that's not why those mechanisms are there. In that latter case, the choice could become a tristate one, allowing all of the selections to be built at once as modules (which really seems to be the way distro kernels would want to use it) or any one of them to be built in (the current behavior, except that at present even when using these as a module only a single one can be selected). The requirements are that (a) just one peripheral controller driver be selectable, and (b) that it be linked either statically or dynamically. Related, that for the gadget drivers (c) none may be selected until the peripheral controller driver they'll be used with is known, and either (d1) one may be statically linked, or else (d2) any number may be built as modules, with only one loaded at a time. This stuff isn't for distro kernels; it's for embedded environments of the only this hardware exists sort. Space matters, and having small code matters. Nobody has been interested enough in an embedded distro model to provide patches enabling such stuff. The second choice appears suspicious altogether - is it really that just any one of these items can be selected to be built into the kernel? Yes. We may want to change that requirement at some point, but as a rule there can be no more than one upstream USB link in systems certified as USB conformant. Most hardware doesn't even allow it. Certainly, *right now* we don't support multiple upstream links, and that's been true for as long as that driver stack has existed. - Dave Bottom line is, in order to suggest an appropriate adjustment to this Kconfig file I need clarification on its intentions. Meanwhile I'll scan the tree for other suspicious choices... Thanks, Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
I'll try to, but it may take some time. Jan >>> Sam Ravnborg <[EMAIL PROTECTED]> 10/20/07 6:50 PM >>> Jan - I assume you will look into this. And thanks to David/Randy for narrowing this down. Thanks, Sam On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote: > > > On Fri, 19 Oct 2007, David Brownell wrote: > > > > My (quick, meaning that I may have missed something) testing > > > indicates that the problem is in the patches attached. > > > > Yes, reverting this seems to resolve the problem: > > > > > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > > > > > Change kconfig behavior so that mixing bool and tristate config settings > > > in > > > a choice is possible and has the desired effect of offering just the > > > tristate options individually if the choice gets set to M, and a normal > > > boolean selection if the choice gets set to Y. > > > > Reverting this patch also fixes a second problem that I didn't > > mention: various dependent options couldn't be enabled. > > > > Again in drivers/usb/gadget/Kconfig, examples include the > > ability to configure the Ethernet gadget to act as an RNDIS > > peripheral; or enabling Mass Storage gadget debug options. > > > > > > Good sleuthing, and thanks! > > > > Now we just need to see that patch reverted before RC1... I don't > > know how Linus deals with all his LKML mail, so I cc'd him in > > the hope that direct messages get through a bit faster. > > Ok, I'll revert it, but wanted to make sure that the parties that pushed > the change are aware of this. > > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
Jan - I assume you will look into this. And thanks to David/Randy for narrowing this down. Thanks, Sam On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote: > > > On Fri, 19 Oct 2007, David Brownell wrote: > > > > My (quick, meaning that I may have missed something) testing > > > indicates that the problem is in the patches attached. > > > > Yes, reverting this seems to resolve the problem: > > > > > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > > > > > Change kconfig behavior so that mixing bool and tristate config settings > > > in > > > a choice is possible and has the desired effect of offering just the > > > tristate options individually if the choice gets set to M, and a normal > > > boolean selection if the choice gets set to Y. > > > > Reverting this patch also fixes a second problem that I didn't > > mention: various dependent options couldn't be enabled. > > > > Again in drivers/usb/gadget/Kconfig, examples include the > > ability to configure the Ethernet gadget to act as an RNDIS > > peripheral; or enabling Mass Storage gadget debug options. > > > > > > Good sleuthing, and thanks! > > > > Now we just need to see that patch reverted before RC1... I don't > > know how Linus deals with all his LKML mail, so I cc'd him in > > the hope that direct messages get through a bit faster. > > Ok, I'll revert it, but wanted to make sure that the parties that pushed > the change are aware of this. > > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
Jan - I assume you will look into this. And thanks to David/Randy for narrowing this down. Thanks, Sam On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote: On Fri, 19 Oct 2007, David Brownell wrote: My (quick, meaning that I may have missed something) testing indicates that the problem is in the patches attached. Yes, reverting this seems to resolve the problem: a5bf3d891a6a0fb5aa122792d965e3774108b923 Change kconfig behavior so that mixing bool and tristate config settings in a choice is possible and has the desired effect of offering just the tristate options individually if the choice gets set to M, and a normal boolean selection if the choice gets set to Y. Reverting this patch also fixes a second problem that I didn't mention: various dependent options couldn't be enabled. Again in drivers/usb/gadget/Kconfig, examples include the ability to configure the Ethernet gadget to act as an RNDIS peripheral; or enabling Mass Storage gadget debug options. Good sleuthing, and thanks! Now we just need to see that patch reverted before RC1... I don't know how Linus deals with all his LKML mail, so I cc'd him in the hope that direct messages get through a bit faster. Ok, I'll revert it, but wanted to make sure that the parties that pushed the change are aware of this. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
I'll try to, but it may take some time. Jan Sam Ravnborg [EMAIL PROTECTED] 10/20/07 6:50 PM Jan - I assume you will look into this. And thanks to David/Randy for narrowing this down. Thanks, Sam On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote: On Fri, 19 Oct 2007, David Brownell wrote: My (quick, meaning that I may have missed something) testing indicates that the problem is in the patches attached. Yes, reverting this seems to resolve the problem: a5bf3d891a6a0fb5aa122792d965e3774108b923 Change kconfig behavior so that mixing bool and tristate config settings in a choice is possible and has the desired effect of offering just the tristate options individually if the choice gets set to M, and a normal boolean selection if the choice gets set to Y. Reverting this patch also fixes a second problem that I didn't mention: various dependent options couldn't be enabled. Again in drivers/usb/gadget/Kconfig, examples include the ability to configure the Ethernet gadget to act as an RNDIS peripheral; or enabling Mass Storage gadget debug options. Good sleuthing, and thanks! Now we just need to see that patch reverted before RC1... I don't know how Linus deals with all his LKML mail, so I cc'd him in the hope that direct messages get through a bit faster. Ok, I'll revert it, but wanted to make sure that the parties that pushed the change are aware of this. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007, David Brownell wrote: > > My (quick, meaning that I may have missed something) testing > > indicates that the problem is in the patches attached. > > Yes, reverting this seems to resolve the problem: > > > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > > > Change kconfig behavior so that mixing bool and tristate config settings in > > a choice is possible and has the desired effect of offering just the > > tristate options individually if the choice gets set to M, and a normal > > boolean selection if the choice gets set to Y. > > Reverting this patch also fixes a second problem that I didn't > mention: various dependent options couldn't be enabled. > > Again in drivers/usb/gadget/Kconfig, examples include the > ability to configure the Ethernet gadget to act as an RNDIS > peripheral; or enabling Mass Storage gadget debug options. > > > Good sleuthing, and thanks! > > Now we just need to see that patch reverted before RC1... I don't > know how Linus deals with all his LKML mail, so I cc'd him in > the hope that direct messages get through a bit faster. Ok, I'll revert it, but wanted to make sure that the parties that pushed the change are aware of this. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
> My (quick, meaning that I may have missed something) testing > indicates that the problem is in the patches attached. Yes, reverting this seems to resolve the problem: > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > Change kconfig behavior so that mixing bool and tristate config settings in > a choice is possible and has the desired effect of offering just the > tristate options individually if the choice gets set to M, and a normal > boolean selection if the choice gets set to Y. Reverting this patch also fixes a second problem that I didn't mention: various dependent options couldn't be enabled. Again in drivers/usb/gadget/Kconfig, examples include the ability to configure the Ethernet gadget to act as an RNDIS peripheral; or enabling Mass Storage gadget debug options. Good sleuthing, and thanks! Now we just need to see that patch reverted before RC1... I don't know how Linus deals with all his LKML mail, so I cc'd him in the hope that direct messages get through a bit faster. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
> On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote:
>
> > >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig;
> > >>> it seems to be quite recent.
> > >>>
> > >>> ...
> > >> Hm, it does look very odd. It looks like it has something to
> > >> do with working differently for some reason.
> > >>
> > >> In xconfig, I set all of the View Options and when I click on one
> > >> of the periph. controllers, it says
> > >>
> > >> depends on =y && PCI
> > >
> > > That's what I saw too. Looked dubious ...
> > >
> > >
> > >> but if I back up to -git7, it says
> > >>
> > >> depends on && PCI
> > >
> > > And that git7 thing doesn't look _quite_ so odd. Did git7 actually
> > > let you configure a modular GOKU (for example), i.e. work correctly?
> >
> > Yes, -git9 does.
> >
> > Looks to me like it broke on -git10. -git9 is OK.
> >
> > >> I'll keep looking.
> > >
> > > Thanks. Kconfig is one of the areas I prefer to let others
> > > be the experts. :)
>
> [hm, odd email problems, changing SMTP]
>
> David,
>
> Just a small update.
>
> If I set USB gadget support to Y instead of M and peripheral
> controller menu item to Y instead of M, then I can select any of the
> 4 periph. controllers that are available to me. (on -git14)
> I don't know why it's like this though.
David,
My (quick, meaning that I may have missed something) testing
indicates that the problem is in the patches attached.
Can you revert them and test that?
>From git:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a5bf3d891a6a0fb5aa122792d965e3774108b923
Change kconfig behavior so that mixing bool and tristate config settings in
a choice is possible and has the desired effect of offering just the
tristate options individually if the choice gets set to M, and a normal
boolean selection if the choice gets set to Y.
Odd, I don't recall seeing this patch...
---
~Randy
diff -u b/Makefile b/Makefile
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -235,16 +235,23 @@ void menu_finalize(struct menu *parent)
sym = parent->sym;
if (parent->list) {
if (sym && sym_is_choice(sym)) {
- /* find the first choice value and find out choice type */
+ /* find out choice type */
+ enum symbol_type type = S_UNKNOWN;
+
for (menu = parent->list; menu; menu = menu->next) {
-if (menu->sym) {
- current_entry = parent;
- menu_set_type(menu->sym->type);
- current_entry = menu;
- menu_set_type(sym->type);
- break;
+if (menu->sym && menu->sym->type != S_UNKNOWN) {
+ if (type == S_UNKNOWN)
+ type = menu->sym->type;
+ if (type != S_BOOLEAN)
+ break;
+ if (menu->sym->type == S_TRISTATE) {
+ type = S_TRISTATE;
+ break;
+ }
}
}
+ current_entry = parent;
+ menu_set_type(type);
parentdep = expr_alloc_symbol(sym);
} else if (parent->prompt)
parentdep = parent->prompt->visible.expr;
@@ -253,7 +260,16 @@ void menu_finalize(struct menu *parent)
for (menu = parent->list; menu; menu = menu->next) {
basedep = expr_transform(menu->dep);
- basedep = expr_alloc_and(expr_copy(parentdep), basedep);
+ dep = parentdep;
+ if (sym && sym_is_choice(sym) && menu->sym) {
+enum symbol_type type = menu->sym->type;
+
+if (type == S_UNKNOWN)
+ type = sym->type;
+ if (type != S_TRISTATE)
+ dep = expr_alloc_comp(E_EQUAL, sym, _yes);
+ }
+ basedep = expr_alloc_and(expr_copy(dep), basedep);
basedep = expr_eliminate_dups(basedep);
menu->dep = basedep;
if (menu->sym)
@@ -326,7 +342,8 @@ void menu_finalize(struct menu *parent)
"values not supported");
}
current_entry = menu;
- menu_set_type(sym->type);
+ if (menu->sym->type == S_UNKNOWN)
+menu_set_type(sym->type);
menu_add_symbol(P_CHOICE, sym, NULL);
prop = sym_get_choice_prop(sym);
for (ep = >expr; *ep; ep = &(*ep)->left.expr)
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -84,12 +84,15 @@ void str_free(struct gstr *gs)
/* Append to growable string */
void str_append(struct gstr *gs, const char *s)
{
- size_t l = strlen(gs->s) + strlen(s) + 1;
- if (l > gs->len) {
- gs->s = realloc(gs->s, l);
- gs->len = l;
+ size_t l;
+ if (s) {
+ l = strlen(gs->s) + strlen(s) + 1;
+ if (l > gs->len) {
+ gs->s = realloc(gs->s, l);
+ gs->len = l;
+ }
+ strcat(gs->s, s);
}
- strcat(gs->s, s);
}
/* Append printf formatted string to growable string */
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote: > >>> I noticed a regression, visible in the drivers/usb/gadget Kconfig; > >>> it seems to be quite recent. > >>> > >>> ... > >> Hm, it does look very odd. It looks like it has something to > >> do with working differently for some reason. > >> > >> In xconfig, I set all of the View Options and when I click on one > >> of the periph. controllers, it says > >> > >>depends on =y && PCI > > > > That's what I saw too. Looked dubious ... > > > > > >> but if I back up to -git7, it says > >> > >>depends on && PCI > > > > And that git7 thing doesn't look _quite_ so odd. Did git7 actually > > let you configure a modular GOKU (for example), i.e. work correctly? > > Yes, -git9 does. > > Looks to me like it broke on -git10. -git9 is OK. > > >> I'll keep looking. > > > > Thanks. Kconfig is one of the areas I prefer to let others > > be the experts. :) [hm, odd email problems, changing SMTP] David, Just a small update. If I set USB gadget support to Y instead of M and peripheral controller menu item to Y instead of M, then I can select any of the 4 periph. controllers that are available to me. (on -git14) I don't know why it's like this though. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
David Brownell wrote: (Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) That mailing list is no longer used. Today's git pull for kbuild included this change: KCONFIG P: Roman Zippel M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] S: Maintained I hadn't pulled that one yet... ;) I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. ... Hm, it does look very odd. It looks like it has something to do with working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y && PCI That's what I saw too. Looked dubious ... but if I back up to -git7, it says depends on && PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually let you configure a modular GOKU (for example), i.e. work correctly? Yes, -git9 does. Looks to me like it broke on -git10. -git9 is OK. I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
> > (Originally posted to kbuild-devel per MAINTAINERS, but > > that post was rejected since that is -- undocumented, > > sigh -- a members-only list.) > > That mailing list is no longer used. Today's git pull for kbuild > included this change: > > KCONFIG > P: Roman Zippel > M: [EMAIL PROTECTED] > -L: [EMAIL PROTECTED] > +L: [EMAIL PROTECTED] > S: Maintained I hadn't pulled that one yet... ;) > > I noticed a regression, visible in the drivers/usb/gadget Kconfig; > > it seems to be quite recent. > > > > ... > > Hm, it does look very odd. It looks like it has something to > do with working differently for some reason. > > In xconfig, I set all of the View Options and when I click on one > of the periph. controllers, it says > > depends on =y && PCI That's what I saw too. Looked dubious ... > but if I back up to -git7, it says > > depends on && PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually let you configure a modular GOKU (for example), i.e. work correctly? > I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 18:22:45 -0700 David Brownell wrote: > (Originally posted to kbuild-devel per MAINTAINERS, but > that post was rejected since that is -- undocumented, > sigh -- a members-only list.) That mailing list is no longer used. Today's git pull for kbuild included this change: KCONFIG P: Roman Zippel M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] S: Maintained > Hi, > > I noticed a regression, visible in the drivers/usb/gadget Kconfig; > it seems to be quite recent. > > That Kconfig hasn't changed (other than adding new drivers), and > it's worked that way for several years now ... so the issue seems > to be changes in menuconfig/kconfig/etc semantics. > > The issue is that when USB_GADGET=m, it's no longer possible to > configure peripheral controller drivers as modules ... the controller > drivers can now only be configured for static linkage. > > It should be making a choice of one of the controller drivers which > could work on the target system, and allow that driver to be linked > either as a module (ok iff USB_GADGET=m) or statically. > > What's the deal here? Hm, it does look very odd. It looks like it has something to do with working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y && PCI but if I back up to -git7, it says depends on && PCI I'll keep looking. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-git Kconfig regression
(Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) Hi, I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. That Kconfig hasn't changed (other than adding new drivers), and it's worked that way for several years now ... so the issue seems to be changes in menuconfig/kconfig/etc semantics. The issue is that when USB_GADGET=m, it's no longer possible to configure peripheral controller drivers as modules ... the controller drivers can now only be configured for static linkage. It should be making a choice of one of the controller drivers which could work on the target system, and allow that driver to be linked either as a module (ok iff USB_GADGET=m) or statically. What's the deal here? - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 18:22:45 -0700 David Brownell wrote: (Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) That mailing list is no longer used. Today's git pull for kbuild included this change: KCONFIG P: Roman Zippel M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] S: Maintained Hi, I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. That Kconfig hasn't changed (other than adding new drivers), and it's worked that way for several years now ... so the issue seems to be changes in menuconfig/kconfig/etc semantics. The issue is that when USB_GADGET=m, it's no longer possible to configure peripheral controller drivers as modules ... the controller drivers can now only be configured for static linkage. It should be making a choice of one of the controller drivers which could work on the target system, and allow that driver to be linked either as a module (ok iff USB_GADGET=m) or statically. What's the deal here? Hm, it does look very odd. It looks like it has something to do with choice working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y PCI but if I back up to -git7, it says depends on choice PCI I'll keep looking. --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-git Kconfig regression
(Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) Hi, I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. That Kconfig hasn't changed (other than adding new drivers), and it's worked that way for several years now ... so the issue seems to be changes in menuconfig/kconfig/etc semantics. The issue is that when USB_GADGET=m, it's no longer possible to configure peripheral controller drivers as modules ... the controller drivers can now only be configured for static linkage. It should be making a choice of one of the controller drivers which could work on the target system, and allow that driver to be linked either as a module (ok iff USB_GADGET=m) or statically. What's the deal here? - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
David Brownell wrote: (Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) That mailing list is no longer used. Today's git pull for kbuild included this change: KCONFIG P: Roman Zippel M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] S: Maintained I hadn't pulled that one yet... ;) I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. ... Hm, it does look very odd. It looks like it has something to do with choice working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y PCI That's what I saw too. Looked dubious ... but if I back up to -git7, it says depends on choice PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually let you configure a modular GOKU (for example), i.e. work correctly? Yes, -git9 does. Looks to me like it broke on -git10. -git9 is OK. I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) -- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote:
I noticed a regression, visible in the drivers/usb/gadget Kconfig;
it seems to be quite recent.
...
Hm, it does look very odd. It looks like it has something to
do with choice working differently for some reason.
In xconfig, I set all of the View Options and when I click on one
of the periph. controllers, it says
depends on =y PCI
That's what I saw too. Looked dubious ...
but if I back up to -git7, it says
depends on choice PCI
And that git7 thing doesn't look _quite_ so odd. Did git7 actually
let you configure a modular GOKU (for example), i.e. work correctly?
Yes, -git9 does.
Looks to me like it broke on -git10. -git9 is OK.
I'll keep looking.
Thanks. Kconfig is one of the areas I prefer to let others
be the experts. :)
[hm, odd email problems, changing SMTP]
David,
Just a small update.
If I set USB gadget support to Y instead of M and peripheral
controller menu item to Y instead of M, then I can select any of the
4 periph. controllers that are available to me. (on -git14)
I don't know why it's like this though.
David,
My (quick, meaning that I may have missed something) testing
indicates that the problem is in the patches attached.
Can you revert them and test that?
From git:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a5bf3d891a6a0fb5aa122792d965e3774108b923
Change kconfig behavior so that mixing bool and tristate config settings in
a choice is possible and has the desired effect of offering just the
tristate options individually if the choice gets set to M, and a normal
boolean selection if the choice gets set to Y.
Odd, I don't recall seeing this patch...
---
~Randy
diff -u b/Makefile b/Makefile
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -235,16 +235,23 @@ void menu_finalize(struct menu *parent)
sym = parent-sym;
if (parent-list) {
if (sym sym_is_choice(sym)) {
- /* find the first choice value and find out choice type */
+ /* find out choice type */
+ enum symbol_type type = S_UNKNOWN;
+
for (menu = parent-list; menu; menu = menu-next) {
-if (menu-sym) {
- current_entry = parent;
- menu_set_type(menu-sym-type);
- current_entry = menu;
- menu_set_type(sym-type);
- break;
+if (menu-sym menu-sym-type != S_UNKNOWN) {
+ if (type == S_UNKNOWN)
+ type = menu-sym-type;
+ if (type != S_BOOLEAN)
+ break;
+ if (menu-sym-type == S_TRISTATE) {
+ type = S_TRISTATE;
+ break;
+ }
}
}
+ current_entry = parent;
+ menu_set_type(type);
parentdep = expr_alloc_symbol(sym);
} else if (parent-prompt)
parentdep = parent-prompt-visible.expr;
@@ -253,7 +260,16 @@ void menu_finalize(struct menu *parent)
for (menu = parent-list; menu; menu = menu-next) {
basedep = expr_transform(menu-dep);
- basedep = expr_alloc_and(expr_copy(parentdep), basedep);
+ dep = parentdep;
+ if (sym sym_is_choice(sym) menu-sym) {
+enum symbol_type type = menu-sym-type;
+
+if (type == S_UNKNOWN)
+ type = sym-type;
+ if (type != S_TRISTATE)
+ dep = expr_alloc_comp(E_EQUAL, sym, symbol_yes);
+ }
+ basedep = expr_alloc_and(expr_copy(dep), basedep);
basedep = expr_eliminate_dups(basedep);
menu-dep = basedep;
if (menu-sym)
@@ -326,7 +342,8 @@ void menu_finalize(struct menu *parent)
values not supported);
}
current_entry = menu;
- menu_set_type(sym-type);
+ if (menu-sym-type == S_UNKNOWN)
+menu_set_type(sym-type);
menu_add_symbol(P_CHOICE, sym, NULL);
prop = sym_get_choice_prop(sym);
for (ep = prop-expr; *ep; ep = (*ep)-left.expr)
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -84,12 +84,15 @@ void str_free(struct gstr *gs)
/* Append to growable string */
void str_append(struct gstr *gs, const char *s)
{
- size_t l = strlen(gs-s) + strlen(s) + 1;
- if (l gs-len) {
- gs-s = realloc(gs-s, l);
- gs-len = l;
+ size_t l;
+ if (s) {
+ l = strlen(gs-s) + strlen(s) + 1;
+ if (l gs-len) {
+ gs-s = realloc(gs-s, l);
+ gs-len = l;
+ }
+ strcat(gs-s, s);
}
- strcat(gs-s, s);
}
/* Append printf formatted string to growable string */
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007 19:01:09 -0700 Randy Dunlap wrote: I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. ... Hm, it does look very odd. It looks like it has something to do with choice working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y PCI That's what I saw too. Looked dubious ... but if I back up to -git7, it says depends on choice PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually let you configure a modular GOKU (for example), i.e. work correctly? Yes, -git9 does. Looks to me like it broke on -git10. -git9 is OK. I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) [hm, odd email problems, changing SMTP] David, Just a small update. If I set USB gadget support to Y instead of M and peripheral controller menu item to Y instead of M, then I can select any of the 4 periph. controllers that are available to me. (on -git14) I don't know why it's like this though. --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
(Originally posted to kbuild-devel per MAINTAINERS, but that post was rejected since that is -- undocumented, sigh -- a members-only list.) That mailing list is no longer used. Today's git pull for kbuild included this change: KCONFIG P: Roman Zippel M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] S: Maintained I hadn't pulled that one yet... ;) I noticed a regression, visible in the drivers/usb/gadget Kconfig; it seems to be quite recent. ... Hm, it does look very odd. It looks like it has something to do with choice working differently for some reason. In xconfig, I set all of the View Options and when I click on one of the periph. controllers, it says depends on =y PCI That's what I saw too. Looked dubious ... but if I back up to -git7, it says depends on choice PCI And that git7 thing doesn't look _quite_ so odd. Did git7 actually let you configure a modular GOKU (for example), i.e. work correctly? I'll keep looking. Thanks. Kconfig is one of the areas I prefer to let others be the experts. :) - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
On Fri, 19 Oct 2007, David Brownell wrote: My (quick, meaning that I may have missed something) testing indicates that the problem is in the patches attached. Yes, reverting this seems to resolve the problem: a5bf3d891a6a0fb5aa122792d965e3774108b923 Change kconfig behavior so that mixing bool and tristate config settings in a choice is possible and has the desired effect of offering just the tristate options individually if the choice gets set to M, and a normal boolean selection if the choice gets set to Y. Reverting this patch also fixes a second problem that I didn't mention: various dependent options couldn't be enabled. Again in drivers/usb/gadget/Kconfig, examples include the ability to configure the Ethernet gadget to act as an RNDIS peripheral; or enabling Mass Storage gadget debug options. Good sleuthing, and thanks! Now we just need to see that patch reverted before RC1... I don't know how Linus deals with all his LKML mail, so I cc'd him in the hope that direct messages get through a bit faster. Ok, I'll revert it, but wanted to make sure that the parties that pushed the change are aware of this. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
My (quick, meaning that I may have missed something) testing indicates that the problem is in the patches attached. Yes, reverting this seems to resolve the problem: a5bf3d891a6a0fb5aa122792d965e3774108b923 Change kconfig behavior so that mixing bool and tristate config settings in a choice is possible and has the desired effect of offering just the tristate options individually if the choice gets set to M, and a normal boolean selection if the choice gets set to Y. Reverting this patch also fixes a second problem that I didn't mention: various dependent options couldn't be enabled. Again in drivers/usb/gadget/Kconfig, examples include the ability to configure the Ethernet gadget to act as an RNDIS peripheral; or enabling Mass Storage gadget debug options. Good sleuthing, and thanks! Now we just need to see that patch reverted before RC1... I don't know how Linus deals with all his LKML mail, so I cc'd him in the hope that direct messages get through a bit faster. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
