| Message ID | 51BF6BFF.7050705@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dne 17.6.2013 22:05, Jiri Slaby napsal(a): > On 05/23/2013 05:09 AM, Jeff Mahoney wrote: >> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote: >>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote: >>>> Some drivers can be built on more platforms than they run on. This >>>> causes users and distributors packaging burden when they have to >>>> manually deselect some drivers from their allmodconfigs. Or sometimes >>>> it is even impossible to disable the drivers without patching the >>>> kernel. >>>> >>>> Introduce a new config option COMPILE_TEST and make all those drivers >>>> to depend on the platform they run on, or on the COMPILE_TEST option. >>>> Now, when users/distributors choose COMPILE_TEST=n they will not have >>>> the drivers in their allmodconfig setups, but developers still can >>>> compile-test them with COMPILE_TEST=y. >>> >>> I understand the urge, and it's getting hard for distros to handle these >>> drivers that just don't work on other architectures, but it's really >>> valuable to ensure that they build properly, for those of us that don't >>> have many/any cross compilers set up. > > But this is exactly what COMPILE_TEST will give us when set to "y", or > am I missing something? > >>>> Now the drivers where we use this new option: >>>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom >>>> processors so it should depend on x86. >>>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. >>>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc >>>> systems -- which do not actually support the hardware via that >>>> method. >>> >>> This seems ripe to start to get really messy, really quickly. Shouldn't >>> "default configs" handle if this "should" be enabled for a platform or >>> not, and let the rest of us just build them with no problems? >> >> If every time a new Kconfig option is added, corresponding default >> config updates come with it, sure. I just don't see that happening, >> especially when it can be done much more clearly in the Kconfig while >> the developer is writing the driver. >> >>> What problems is this causing you? Are you running out of space in >>> kernel packages with drivers that will never be actually used? >> >> Wasted build resources. Wasted disk space on /every/ system the kernel >> package is installed on. We're all trying to pare down the kernel >> packages to eliminate wasted space and doing it manually means a bunch >> of research, sometimes with incorrect assumptions about the results, >> needs to be done by someone not usually associated with that code. That >> research gets repeated by people maintaining kernel packages for pretty >> much every distro. > > I second all the above. > >>>> +config COMPILE_TEST >>>> + bool "Compile also drivers which will not load" if EXPERT >>> >>> EXPERT is getting to be the "let's hide it here" option, isn't it... >>> >>> I don't know, if no one else strongly objects, I can be convinced that >>> this is needed, but so far, I don't see why it really is, or what this >>> is going to help with. >> >> I'm not convinced adding a || COMPILE_TEST option to every driver that >> may be arch specific is the best way to go either. Perhaps adding a new >> Kconfig verb called "archdepends on" or something that will evaluate as >> true if COMPILE_TEST is enabled but will evaluate the conditional if >> not. *waves hands* > > Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want > to extend the kconfig language for this purpose (which I support). That > a config option is fine and sufficient in this case [1]. Except he > called the config option "SHOW_ALL_DRIVERS". Adding the current > maintainer to CCs ;). I agree with Sam. 'depends on XY || COMPILE_TEST' is quite self-explanatory. And even if it's not, you can look up the help text for COMPILE_TEST. With "archdepends on" or "available on", you need to know what to look for to override the dependency. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Jun 18, 2013 at 06:51:32AM +0200, Michal Marek wrote: > Dne 17.6.2013 22:05, Jiri Slaby napsal(a): > > On 05/23/2013 05:09 AM, Jeff Mahoney wrote: > >> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote: > >>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote: > >>>> Some drivers can be built on more platforms than they run on. This > >>>> causes users and distributors packaging burden when they have to > >>>> manually deselect some drivers from their allmodconfigs. Or sometimes > >>>> it is even impossible to disable the drivers without patching the > >>>> kernel. > >>>> > >>>> Introduce a new config option COMPILE_TEST and make all those drivers > >>>> to depend on the platform they run on, or on the COMPILE_TEST option. > >>>> Now, when users/distributors choose COMPILE_TEST=n they will not have > >>>> the drivers in their allmodconfig setups, but developers still can > >>>> compile-test them with COMPILE_TEST=y. > >>> > >>> I understand the urge, and it's getting hard for distros to handle these > >>> drivers that just don't work on other architectures, but it's really > >>> valuable to ensure that they build properly, for those of us that don't > >>> have many/any cross compilers set up. > > > > But this is exactly what COMPILE_TEST will give us when set to "y", or > > am I missing something? > > > >>>> Now the drivers where we use this new option: > >>>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom > >>>> processors so it should depend on x86. > >>>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. > >>>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc > >>>> systems -- which do not actually support the hardware via that > >>>> method. > >>> > >>> This seems ripe to start to get really messy, really quickly. Shouldn't > >>> "default configs" handle if this "should" be enabled for a platform or > >>> not, and let the rest of us just build them with no problems? > >> > >> If every time a new Kconfig option is added, corresponding default > >> config updates come with it, sure. I just don't see that happening, > >> especially when it can be done much more clearly in the Kconfig while > >> the developer is writing the driver. > >> > >>> What problems is this causing you? Are you running out of space in > >>> kernel packages with drivers that will never be actually used? > >> > >> Wasted build resources. Wasted disk space on /every/ system the kernel > >> package is installed on. We're all trying to pare down the kernel > >> packages to eliminate wasted space and doing it manually means a bunch > >> of research, sometimes with incorrect assumptions about the results, > >> needs to be done by someone not usually associated with that code. That > >> research gets repeated by people maintaining kernel packages for pretty > >> much every distro. > > > > I second all the above. > > > >>>> +config COMPILE_TEST > >>>> + bool "Compile also drivers which will not load" if EXPERT > >>> > >>> EXPERT is getting to be the "let's hide it here" option, isn't it... > >>> > >>> I don't know, if no one else strongly objects, I can be convinced that > >>> this is needed, but so far, I don't see why it really is, or what this > >>> is going to help with. > >> > >> I'm not convinced adding a || COMPILE_TEST option to every driver that > >> may be arch specific is the best way to go either. Perhaps adding a new > >> Kconfig verb called "archdepends on" or something that will evaluate as > >> true if COMPILE_TEST is enabled but will evaluate the conditional if > >> not. *waves hands* > > > > Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want > > to extend the kconfig language for this purpose (which I support). That > > a config option is fine and sufficient in this case [1]. Except he > > called the config option "SHOW_ALL_DRIVERS". Adding the current > > maintainer to CCs ;). > > I agree with Sam. 'depends on XY || COMPILE_TEST' is quite > self-explanatory. And even if it's not, you can look up the help text > for COMPILE_TEST. With "archdepends on" or "available on", you need to > know what to look for to override the dependency. you will still end up with: depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || ARCH_PPC || ...) And every now and again that particular line will be updated to add another arch dependency.
On 06/18/2013 10:18 AM, Felipe Balbi wrote: > Hi, > > On Tue, Jun 18, 2013 at 06:51:32AM +0200, Michal Marek wrote: >> Dne 17.6.2013 22:05, Jiri Slaby napsal(a): >>> On 05/23/2013 05:09 AM, Jeff Mahoney wrote: >>>> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote: >>>>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby >>>>> wrote: >>>>>> Some drivers can be built on more platforms than they run >>>>>> on. This causes users and distributors packaging burden >>>>>> when they have to manually deselect some drivers from >>>>>> their allmodconfigs. Or sometimes it is even impossible >>>>>> to disable the drivers without patching the kernel. >>>>>> >>>>>> Introduce a new config option COMPILE_TEST and make all >>>>>> those drivers to depend on the platform they run on, or >>>>>> on the COMPILE_TEST option. Now, when users/distributors >>>>>> choose COMPILE_TEST=n they will not have the drivers in >>>>>> their allmodconfig setups, but developers still can >>>>>> compile-test them with COMPILE_TEST=y. >>>>> >>>>> I understand the urge, and it's getting hard for distros to >>>>> handle these drivers that just don't work on other >>>>> architectures, but it's really valuable to ensure that they >>>>> build properly, for those of us that don't have many/any >>>>> cross compilers set up. >>> >>> But this is exactly what COMPILE_TEST will give us when set to >>> "y", or am I missing something? >>> >>>>>> Now the drivers where we use this new option: * >>>>>> PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with >>>>>> Intel Atom processors so it should depend on x86. * >>>>>> FB_GEODE: Geode is 32-bit only so only enable it for >>>>>> X86_32. * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will >>>>>> be met on powerpc systems -- which do not actually >>>>>> support the hardware via that method. >>>>> >>>>> This seems ripe to start to get really messy, really >>>>> quickly. Shouldn't "default configs" handle if this >>>>> "should" be enabled for a platform or not, and let the rest >>>>> of us just build them with no problems? >>>> >>>> If every time a new Kconfig option is added, corresponding >>>> default config updates come with it, sure. I just don't see >>>> that happening, especially when it can be done much more >>>> clearly in the Kconfig while the developer is writing the >>>> driver. >>>> >>>>> What problems is this causing you? Are you running out of >>>>> space in kernel packages with drivers that will never be >>>>> actually used? >>>> >>>> Wasted build resources. Wasted disk space on /every/ system >>>> the kernel package is installed on. We're all trying to pare >>>> down the kernel packages to eliminate wasted space and doing >>>> it manually means a bunch of research, sometimes with >>>> incorrect assumptions about the results, needs to be done by >>>> someone not usually associated with that code. That research >>>> gets repeated by people maintaining kernel packages for >>>> pretty much every distro. >>> >>> I second all the above. >>> >>>>>> +config COMPILE_TEST + bool "Compile also drivers which >>>>>> will not load" if EXPERT >>>>> >>>>> EXPERT is getting to be the "let's hide it here" option, >>>>> isn't it... >>>>> >>>>> I don't know, if no one else strongly objects, I can be >>>>> convinced that this is needed, but so far, I don't see why >>>>> it really is, or what this is going to help with. >>>> >>>> I'm not convinced adding a || COMPILE_TEST option to every >>>> driver that may be arch specific is the best way to go >>>> either. Perhaps adding a new Kconfig verb called "archdepends >>>> on" or something that will evaluate as true if COMPILE_TEST >>>> is enabled but will evaluate the conditional if not. *waves >>>> hands* >>> >>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he >>> doesn't want to extend the kconfig language for this purpose >>> (which I support). That a config option is fine and sufficient >>> in this case [1]. Except he called the config option >>> "SHOW_ALL_DRIVERS". Adding the current maintainer to CCs ;). >> >> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite >> self-explanatory. And even if it's not, you can look up the help >> text for COMPILE_TEST. With "archdepends on" or "available on", >> you need to know what to look for to override the dependency. > > you will still end up with: > > depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || ARCH_PPC || > ...) > > And every now and again that particular line will be updated to > add another arch dependency. But that is perfectly fine *when* the driver is supported on those archs only. And come on, how much often will this "every now and again" happen? We don't have that much cases where a driver is augmented to work on another arch or platform. It either works on all of them => doesn't need COMPILE_TEST, or work on one or two arches at most.
Hi, On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote: > >>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he > >>> doesn't want to extend the kconfig language for this purpose > >>> (which I support). That a config option is fine and sufficient > >>> in this case [1]. Except he called the config option > >>> "SHOW_ALL_DRIVERS". Adding the current maintainer to CCs ;). > >> > >> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite > >> self-explanatory. And even if it's not, you can look up the help > >> text for COMPILE_TEST. With "archdepends on" or "available on", > >> you need to know what to look for to override the dependency. > > > > you will still end up with: > > > > depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || ARCH_PPC || > > ...) > > > > And every now and again that particular line will be updated to > > add another arch dependency. > > But that is perfectly fine *when* the driver is supported on those > archs only. > > And come on, how much often will this "every now and again" happen? We > don't have that much cases where a driver is augmented to work on > another arch or platform. It either works on all of them => doesn't > need COMPILE_TEST, or work on one or two arches at most. MUSB alone has 8 different arch choices. Before, it used to be that core driver was dependendent on all of them, so whenever someone wanted to build MUSB for another arch, they had to introdude their glue code and modify the dependency of the core driver. Also EHCI, it works on pretty much everything, so does DWC3. DWC3 already has three possibilities but I know of at least 3 others which could show up soonish.
On 18/06/13 07:51, Michal Marek wrote: >> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want >> to extend the kconfig language for this purpose (which I support). That >> a config option is fine and sufficient in this case [1]. Except he >> called the config option "SHOW_ALL_DRIVERS". Adding the current >> maintainer to CCs ;). > > I agree with Sam. 'depends on XY || COMPILE_TEST' is quite > self-explanatory. And even if it's not, you can look up the help text > for COMPILE_TEST. With "archdepends on" or "available on", you need to > know what to look for to override the dependency. I would rather have "depends on", when the code actually depends on something (i.e. you can't compile/load the code otherwise), and "used on"/"available on" when the code is just normally not used except on the listed platforms (but nothing prevents from compiling and using the code on all platforms). But I'm fine with COMPILE_TEST or similar, I guess it's an acceptable compromise and trivial to implement. Even if we had "used on" we'd still need to update the Kconfig file when the code is being used on a new platform, just like with COMPILE_TEST. Tomi
Dne 18.6.2013 10:34, Felipe Balbi napsal(a): > Hi, > > On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote: >>>>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that >>>>> he doesn't want to extend the kconfig language for this >>>>> purpose (which I support). That a config option is fine and >>>>> sufficient in this case [1]. Except he called the config >>>>> option "SHOW_ALL_DRIVERS". Adding the current maintainer to >>>>> CCs ;). >>>> >>>> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite >>>> self-explanatory. And even if it's not, you can look up the >>>> help text for COMPILE_TEST. With "archdepends on" or >>>> "available on", you need to know what to look for to override >>>> the dependency. >>> >>> you will still end up with: >>> >>> depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || >>> ARCH_PPC || ...) >>> >>> And every now and again that particular line will be updated >>> to add another arch dependency. >> >> But that is perfectly fine *when* the driver is supported on >> those archs only. >> >> And come on, how much often will this "every now and again" >> happen? We don't have that much cases where a driver is augmented >> to work on another arch or platform. It either works on all of >> them => doesn't need COMPILE_TEST, or work on one or two arches >> at most. > > MUSB alone has 8 different arch choices. Before, it used to be that > core driver was dependendent on all of them, so whenever someone > wanted to build MUSB for another arch, they had to introdude their > glue code and modify the dependency of the core driver. But that you have complex dependencies in some drivers is mostly orthogonal to the two choices of syntax, isn't it? depends on ARCH1 || ARCH2 || .... || ARCH8 || COMPILE_TEST vs. archdepends on ARCH1 || ARCH2 || .... || ARCH8 Michal -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Jun 18, 2013 at 10:44:52AM +0200, Michal Marek wrote: > > On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote: > >>>>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that > >>>>> he doesn't want to extend the kconfig language for this > >>>>> purpose (which I support). That a config option is fine and > >>>>> sufficient in this case [1]. Except he called the config > >>>>> option "SHOW_ALL_DRIVERS". Adding the current maintainer to > >>>>> CCs ;). > >>>> > >>>> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite > >>>> self-explanatory. And even if it's not, you can look up the > >>>> help text for COMPILE_TEST. With "archdepends on" or > >>>> "available on", you need to know what to look for to override > >>>> the dependency. > >>> > >>> you will still end up with: > >>> > >>> depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || > >>> ARCH_PPC || ...) > >>> > >>> And every now and again that particular line will be updated > >>> to add another arch dependency. > >> > >> But that is perfectly fine *when* the driver is supported on > >> those archs only. > >> > >> And come on, how much often will this "every now and again" > >> happen? We don't have that much cases where a driver is augmented > >> to work on another arch or platform. It either works on all of > >> them => doesn't need COMPILE_TEST, or work on one or two arches > >> at most. > > > > MUSB alone has 8 different arch choices. Before, it used to be that > > core driver was dependendent on all of them, so whenever someone > > wanted to build MUSB for another arch, they had to introdude their > > glue code and modify the dependency of the core driver. > > But that you have complex dependencies in some drivers is mostly > orthogonal to the two choices of syntax, isn't it? > > depends on ARCH1 || ARCH2 || .... || ARCH8 || COMPILE_TEST > > vs. > > archdepends on ARCH1 || ARCH2 || .... || ARCH8 right, but my argument is that I rather not have either. Depend on PCI if you us PCI, depend on EXTCON if you use extcon, but no driver should have an ARCH dependency. Specially since it lets people include mach/* and asm/* headers because "it doesn't break compilation for anyone".
On 06/18/2013 10:51 AM, Felipe Balbi wrote: > right, but my argument is that I rather not have either. Depend on > PCI if you us PCI, depend on EXTCON if you use extcon, but no > driver should have an ARCH dependency. Specially since it lets > people include mach/* and asm/* headers because "it doesn't break > compilation for anyone". The argument is elsewhere. If I understand correctly, Kconfig is for users, not to be hi-jacked by kernel developers. And users should not really care about our development processes, cross compilations or whatever bells and whistles we use. They just don't want to see drivers which they have no way to *use*, they indeed don't care whether some more compile at all. We do not want every kernel packager for every distro out in the wild, to go through all the help texts, to see whether they should compile and package a driver or not. It's a tedious work and this option would save time to the packagers. Try to package and maintain a kernel for a distribution, you will find out what a cool and surprising work that is... In the best case I would vote for hard dependencies as cross-compilers are easy to obtain and set up nowadays. But well, we still want to ("cross") compile drivers, so let's add COMPILE_TEST and use that to save time to automatic builds.
On Mon, Jun 17, 2013 at 10:05:19PM +0200, Jiri Slaby wrote: > On 05/23/2013 05:09 AM, Jeff Mahoney wrote: > > On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote: > >> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote: > >>> Some drivers can be built on more platforms than they run on. This > >>> causes users and distributors packaging burden when they have to > >>> manually deselect some drivers from their allmodconfigs. Or sometimes > >>> it is even impossible to disable the drivers without patching the > >>> kernel. > >>> > >>> Introduce a new config option COMPILE_TEST and make all those drivers > >>> to depend on the platform they run on, or on the COMPILE_TEST option. > >>> Now, when users/distributors choose COMPILE_TEST=n they will not have > >>> the drivers in their allmodconfig setups, but developers still can > >>> compile-test them with COMPILE_TEST=y. > >> > >> I understand the urge, and it's getting hard for distros to handle these > >> drivers that just don't work on other architectures, but it's really > >> valuable to ensure that they build properly, for those of us that don't > >> have many/any cross compilers set up. > > But this is exactly what COMPILE_TEST will give us when set to "y", or > am I missing something? > > >>> Now the drivers where we use this new option: > >>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom > >>> processors so it should depend on x86. > >>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. > >>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc > >>> systems -- which do not actually support the hardware via that > >>> method. > >> > >> This seems ripe to start to get really messy, really quickly. Shouldn't > >> "default configs" handle if this "should" be enabled for a platform or > >> not, and let the rest of us just build them with no problems? > > > > If every time a new Kconfig option is added, corresponding default > > config updates come with it, sure. I just don't see that happening, > > especially when it can be done much more clearly in the Kconfig while > > the developer is writing the driver. > > > >> What problems is this causing you? Are you running out of space in > >> kernel packages with drivers that will never be actually used? > > > > Wasted build resources. Wasted disk space on /every/ system the kernel > > package is installed on. We're all trying to pare down the kernel > > packages to eliminate wasted space and doing it manually means a bunch > > of research, sometimes with incorrect assumptions about the results, > > needs to be done by someone not usually associated with that code. That > > research gets repeated by people maintaining kernel packages for pretty > > much every distro. > > I second all the above. > > >>> +config COMPILE_TEST > >>> + bool "Compile also drivers which will not load" if EXPERT > >> > >> EXPERT is getting to be the "let's hide it here" option, isn't it... > >> > >> I don't know, if no one else strongly objects, I can be convinced that > >> this is needed, but so far, I don't see why it really is, or what this > >> is going to help with. > > > > I'm not convinced adding a || COMPILE_TEST option to every driver that > > may be arch specific is the best way to go either. Perhaps adding a new > > Kconfig verb called "archdepends on" or something that will evaluate as > > true if COMPILE_TEST is enabled but will evaluate the conditional if > > not. *waves hands* > > Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want > to extend the kconfig language for this purpose (which I support). That > a config option is fine and sufficient in this case [1]. Except he > called the config option "SHOW_ALL_DRIVERS". Adding the current > maintainer to CCs ;). > > [1] http://comments.gmane.org/gmane.linux.kbuild.devel/9829 > > The last point I inclined to the Greg's argument to remove the EXPERT > dependency. > > So currently I have what is attached... Comments? Looks good to me, want me to queue it up through my char/misc driver tree for 3.11? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote: >> So currently I have what is attached... Comments? > > Looks good to me, want me to queue it up through my char/misc driver > tree for 3.11? If there are no objections... Whoever picks that up, I would be happy 8-).
On 17/06/13 23:05, Jiri Slaby wrote: > The last point I inclined to the Greg's argument to remove the EXPERT > dependency. > > So currently I have what is attached... Comments? The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're not adding COMPILE_TEST there, but you're adding a totally new config option, and also changing the Makefile. Maybe that's ok, but there's no mention about this in the desc. Tomi
On 06/19/2013 09:10 AM, Tomi Valkeinen wrote: > On 17/06/13 23:05, Jiri Slaby wrote: > >> The last point I inclined to the Greg's argument to remove the >> EXPERT dependency. >> >> So currently I have what is attached... Comments? > > The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're > not adding COMPILE_TEST there, but you're adding a totally new > config option, and also changing the Makefile. Look: +config USB_CHIPIDEA_IMX + bool "ChipIdea IMX support" + depends on OF_DEVICE && (ARM || COMPILE_TEST) COMPILE_TEST added here ----------------^^^^^^^^^^^^
On 19/06/13 10:12, Jiri Slaby wrote: > On 06/19/2013 09:10 AM, Tomi Valkeinen wrote: >> On 17/06/13 23:05, Jiri Slaby wrote: >> >>> The last point I inclined to the Greg's argument to remove the >>> EXPERT dependency. >>> >>> So currently I have what is attached... Comments? >> >> The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're >> not adding COMPILE_TEST there, but you're adding a totally new >> config option, and also changing the Makefile. > > Look: > > +config USB_CHIPIDEA_IMX > + bool "ChipIdea IMX support" > + depends on OF_DEVICE && (ARM || COMPILE_TEST) > > COMPILE_TEST added here ----------------^^^^^^^^^^^^ My point was that you're not adding COMPILE_TEST to an existing config option, you're creating a totally new config option. As I said, that's probably ok, but it'd be nice to mention extra things like that in the desc. The pedantic approach would be to do the makefile and Kconfig change in an earlier patch, and then add only COMPILE_TEST. Tomi
On Wed, Jun 19, 2013 at 09:12:56AM +0200, Jiri Slaby wrote: > On 06/19/2013 09:10 AM, Tomi Valkeinen wrote: > > On 17/06/13 23:05, Jiri Slaby wrote: > > > >> The last point I inclined to the Greg's argument to remove the > >> EXPERT dependency. > >> > >> So currently I have what is attached... Comments? > > > > The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're > > not adding COMPILE_TEST there, but you're adding a totally new > > config option, and also changing the Makefile. > > Look: > > +config USB_CHIPIDEA_IMX > + bool "ChipIdea IMX support" > + depends on OF_DEVICE && (ARM || COMPILE_TEST) Ah, what about all of the chipidea chips on x86 boxes (yes, they are rare, but they are present, so you can't just turn them off for that whole platform here. I'd leave chipidea alone, it's getting more prelevant, not on a desktop or server, but in SoC systems, which is x86 for a lot of devices. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 18, 2013 at 11:34:26AM +0300, Felipe Balbi wrote: > MUSB alone has 8 different arch choices. Before, it used to be that core > driver was dependendent on all of them, so whenever someone wanted to > build MUSB for another arch, they had to introdude their glue code and > modify the dependency of the core driver. > Also EHCI, it works on pretty much everything, so does DWC3. > DWC3 already has three possibilities but I know of at least 3 others > which could show up soonish. If the number of architectures supported is getting large enough then it's probably reasonable to just enable the driver all the time, probably it'll also appear on some PCI cards or something anyway. The things people are complaining about here are things that are clearly unlikely to appear on other architectures like a particular SoC vendor's custom IPs that they don't license out.
On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote: > On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote: > >> So currently I have what is attached... Comments? > > > > Looks good to me, want me to queue it up through my char/misc driver > > tree for 3.11? > > If there are no objections... Whoever picks that up, I would be happy 8-). I've taken it, without the chipidea portion, through my driver-core tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/25/2013 01:42 AM, Greg Kroah-Hartman wrote: > On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote: >> On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote: >>>> So currently I have what is attached... Comments? >>> >>> Looks good to me, want me to queue it up through my char/misc driver >>> tree for 3.11? >> >> If there are no objections... Whoever picks that up, I would be happy 8-). > > I've taken it, without the chipidea portion, through my driver-core > tree. Ok thanks. (FWIW I sent v3 without the chipidea change too...)
From e818e90b4f901c8d949d08bd05735203c5e88530 Mon Sep 17 00:00:00 2001 From: Jiri Slaby <jslaby@suse.cz> Date: Wed, 22 May 2013 10:56:24 +0200 Subject: [PATCH v2] build some drivers only when compile-testing Some drivers can be built on more platforms than they run on. This is a burden for users and distributors who package a kernel. They have to manually deselect some (for them useless) drivers when updating their configs via oldconfig. And yet, sometimes it is even impossible to disable the drivers without patching the kernel. Introduce a new config option COMPILE_TEST and make all those drivers to depend on the platform they run on, or on the COMPILE_TEST option. Now, when users/distributors choose COMPILE_TEST=n they will not have the drivers in their allmodconfig setups, but developers still can compile-test them with COMPILE_TEST=y. Now the drivers where we use this new option: * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom processors so it should depend on x86. * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc systems -- which do not actually support the hardware via that method. * INTEL_MID_PTI: It is specific to the Penwell type of Intel Atom device. [v2] * remove EXPERT dependency Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jeff Mahoney <jeffm@suse.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: linux-geode@lists.infradead.org Cc: linux-fbdev@vger.kernel.org Cc: Richard Cochran <richardcochran@gmail.com> Cc: netdev@vger.kernel.org Cc: Ben Hutchings <ben@decadent.org.uk> Cc: "Keller, Jacob E" <jacob.e.keller@intel.com> --- drivers/misc/Kconfig | 2 +- drivers/ptp/Kconfig | 1 + drivers/usb/chipidea/Kconfig | 6 ++++++ drivers/usb/chipidea/Makefile | 4 +--- drivers/video/geode/Kconfig | 2 +- init/Kconfig | 14 ++++++++++++++ 6 files changed, 24 insertions(+), 5 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 80889d5..8dacd4c 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -135,7 +135,7 @@ config PHANTOM config INTEL_MID_PTI tristate "Parallel Trace Interface for MIPI P1149.7 cJTAG standard" - depends on PCI && TTY + depends on PCI && TTY && (X86_INTEL_MID || COMPILE_TEST) default n help The PTI (Parallel Trace Interface) driver directs diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index 1ea6f1d..5be73ba 100644 --- a/drivers/ptp/Kconfig +++ b/drivers/ptp/Kconfig @@ -72,6 +72,7 @@ config DP83640_PHY config PTP_1588_CLOCK_PCH tristate "Intel PCH EG20T as PTP clock" + depends on X86 || COMPILE_TEST select PTP_1588_CLOCK help This driver adds support for using the PCH EG20T as a PTP diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index b2df442..3491d86 100644 --- a/drivers/usb/chipidea/Kconfig +++ b/drivers/usb/chipidea/Kconfig @@ -31,4 +31,10 @@ config USB_CHIPIDEA_DEBUG help Say Y here to enable debugging output of the ChipIdea driver. +config USB_CHIPIDEA_IMX + bool "ChipIdea IMX support" + depends on OF_DEVICE && (ARM || COMPILE_TEST) + help + This option enables ChipIdea support on IMX. + endif diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile index 4113feb..76d66ff 100644 --- a/drivers/usb/chipidea/Makefile +++ b/drivers/usb/chipidea/Makefile @@ -16,6 +16,4 @@ ifneq ($(CONFIG_PCI),) obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_pci.o endif -ifneq ($(CONFIG_OF),) - obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o usbmisc_imx.o -endif +obj-$(CONFIG_USB_CHIPIDEA_IMX) += ci13xxx_imx.o usbmisc_imx.o diff --git a/drivers/video/geode/Kconfig b/drivers/video/geode/Kconfig index 21e351a..1e85552 100644 --- a/drivers/video/geode/Kconfig +++ b/drivers/video/geode/Kconfig @@ -3,7 +3,7 @@ # config FB_GEODE bool "AMD Geode family framebuffer support" - depends on FB && PCI && X86 + depends on FB && PCI && (X86_32 || (X86 && COMPILE_TEST)) ---help--- Say 'Y' here to allow you to select framebuffer drivers for the AMD Geode family of processors. diff --git a/init/Kconfig b/init/Kconfig index fd0e436..e1854b2 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -53,6 +53,20 @@ config CROSS_COMPILE need to set this unless you want the configured kernel build directory to select the cross-compiler automatically. +config COMPILE_TEST + bool "Compile also drivers which will not load" + default n + help + Some drivers can be compiled on a different platform than they are + intended to be run on. Despite they cannot be loaded there (or even + when they load they cannot be used due to missing HW support), + developers still, opposing to distributors, might want to build such + drivers to compile-test them. + + If you are a developer and want to build everything available, say Y + here. If you are a user/distributor, say N here to exclude useless + drivers to be distributed. + config LOCALVERSION string "Local version - append to kernel release" help -- 1.8.3