Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Monday 19 September 2011, Greg KH wrote: > That sounds good to me, I'll be glad to collect the patches and push > them to Linus for both of those trees (might as well keep them in the > same git tree, no need to separate them, right?) and I'll rely on you > for review and acking them. Much like I do today for the tty and serial > trees. > > I'll go set up the trees locally today and when kernel.org opens back > up, make them public and add them to linux-next. Ok, great! Thanks, Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Mon, Sep 19, 2011 at 10:47:50AM +0200, Arnd Bergmann wrote:
> On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
> > >> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
> > >> consistent or timely with applying drivers/misc/ patches. It deserves
> > >> better.
> > >> [added him to Cc: list]
> > >
> > > I do try to handle patches sent to me for misc/ in time for the
> > > different merge windows as that directory contains drivers that have
> > > moved out of the staging/ directory.
> > >
> > > But yes, I'm not the overall drivers/misc/ maintainer, do we really need
> > > one? If so, I can easily start maintaining a development tree for it to
> > > keep it separate for the different driver authors to send me stuff and
> > > start tracking it more "for real" if Arnd doesn't want to do it.
> >
> > We need for the patches to be applied in a timely manner.
> > Sometimes when there is no real maintainer, that does not happen.
>
> I think the other equally import aspect of maintainership that
> drivers/misc (and drivers/char) needs is someone who says no to
> stuff that doesn't belong there and helps submitters to find a
> proper place where appropriate and to come up with a proper user
> interface abstraction.
>
> I'm definitely willing to do that part.
>
> Greg, how about we both formally take ownership of driver/{misc,char}
> and you track the patches while I do the bulk of the reviews? You
> are definitely better than me with the patch tracking workflow.
That sounds good to me, I'll be glad to collect the patches and push
them to Linus for both of those trees (might as well keep them in the
same git tree, no need to separate them, right?) and I'll rely on you
for review and acking them. Much like I do today for the tty and serial
trees.
I'll go set up the trees locally today and when kernel.org opens back
up, make them public and add them to linux-next.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
> >> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
> >> consistent or timely with applying drivers/misc/ patches. It deserves
> >> better.
> >> [added him to Cc: list]
> >
> > I do try to handle patches sent to me for misc/ in time for the
> > different merge windows as that directory contains drivers that have
> > moved out of the staging/ directory.
> >
> > But yes, I'm not the overall drivers/misc/ maintainer, do we really need
> > one? If so, I can easily start maintaining a development tree for it to
> > keep it separate for the different driver authors to send me stuff and
> > start tracking it more "for real" if Arnd doesn't want to do it.
>
> We need for the patches to be applied in a timely manner.
> Sometimes when there is no real maintainer, that does not happen.
I think the other equally import aspect of maintainership that
drivers/misc (and drivers/char) needs is someone who says no to
stuff that doesn't belong there and helps submitters to find a
proper place where appropriate and to come up with a proper user
interface abstraction.
I'm definitely willing to do that part.
Greg, how about we both formally take ownership of driver/{misc,char}
and you track the patches while I do the bulk of the reviews? You
are definitely better than me with the patch tracking workflow.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On 09/18/2011 08:28 AM, Greg KH wrote: > On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote: >> On 09/05/2011 07:19 AM, Arnd Bergmann wrote: >>> I think it would simply be more consistent to have it enabled all >>> the time. Well, even better would be to move the bulk of the misc >>> drivers to a proper location sorted by their subsystems. A lot of them >>> should never have been merged in their current state IMHO. >> >> >> If it's clear where they belong, then sure, they should be somewhere >> other than drivers/misc/, but I don't see that it's clear for several >> of them. >> >> >>> I think I should finally do what has been talked about a few times and >>> formally become the maintainer of drivers/char and drivers/misc ;-) >>> >>> The problem is that I'm not actually a good maintainer, but maybe it's >>> better to just have someone instead of falling back to Andrew or >>> some random subsystem maintainer to send any patches for drivers/misc. >> >> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not >> consistent or timely with applying drivers/misc/ patches. It deserves >> better. >> [added him to Cc: list] > > I do try to handle patches sent to me for misc/ in time for the > different merge windows as that directory contains drivers that have > moved out of the staging/ directory. > > But yes, I'm not the overall drivers/misc/ maintainer, do we really need > one? If so, I can easily start maintaining a development tree for it to > keep it separate for the different driver authors to send me stuff and > start tracking it more "for real" if Arnd doesn't want to do it. We need for the patches to be applied in a timely manner. Sometimes when there is no real maintainer, that does not happen. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote: > On 09/05/2011 07:19 AM, Arnd Bergmann wrote: > > I think it would simply be more consistent to have it enabled all > > the time. Well, even better would be to move the bulk of the misc > > drivers to a proper location sorted by their subsystems. A lot of them > > should never have been merged in their current state IMHO. > > > If it's clear where they belong, then sure, they should be somewhere > other than drivers/misc/, but I don't see that it's clear for several > of them. > > > > I think I should finally do what has been talked about a few times and > > formally become the maintainer of drivers/char and drivers/misc ;-) > > > > The problem is that I'm not actually a good maintainer, but maybe it's > > better to just have someone instead of falling back to Andrew or > > some random subsystem maintainer to send any patches for drivers/misc. > > We have fallbacks to Andrew and/or GregKH currently, but GregKH is not > consistent or timely with applying drivers/misc/ patches. It deserves better. > [added him to Cc: list] I do try to handle patches sent to me for misc/ in time for the different merge windows as that directory contains drivers that have moved out of the staging/ directory. But yes, I'm not the overall drivers/misc/ maintainer, do we really need one? If so, I can easily start maintaining a development tree for it to keep it separate for the different driver authors to send me stuff and start tracking it more "for real" if Arnd doesn't want to do it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On 09/05/2011 07:19 AM, Arnd Bergmann wrote: > I think it would simply be more consistent to have it enabled all > the time. Well, even better would be to move the bulk of the misc > drivers to a proper location sorted by their subsystems. A lot of them > should never have been merged in their current state IMHO. If it's clear where they belong, then sure, they should be somewhere other than drivers/misc/, but I don't see that it's clear for several of them. > I think I should finally do what has been talked about a few times and > formally become the maintainer of drivers/char and drivers/misc ;-) > > The problem is that I'm not actually a good maintainer, but maybe it's > better to just have someone instead of falling back to Andrew or > some random subsystem maintainer to send any patches for drivers/misc. We have fallbacks to Andrew and/or GregKH currently, but GregKH is not consistent or timely with applying drivers/misc/ patches. It deserves better. [added him to Cc: list] So yes, I think that drivers/misc/ (and probably drivers/char/) deserves a maintainer, but you are not making a good case for you being that person. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Mon, 5 Sep 2011 16:19:35 +0200, Arnd Bergmann wrote: > On Monday 05 September 2011, Jean Delvare wrote: > > As said before, I'm not sure. Yes, it makes it easier to select misc > > device drivers from Kconfig files. But it also makes it impossible to > > deselect all misc device drivers at once. > > > > I think that what we really need is the implementation in the Kconfig > > system of smart selects, i.e. whenever an entry is selected, everything > > it depends on gets selected as well. I don't know how feasible this is, > > but if it can be done then I'd prefer this to your proposal. > > > > Meanwhile, I am not in favor of applying your patch. The benefit is > > relatively small IMHO (misc device drivers are rarely selected) and > > there is one significant drawback. > > Before I made this patch, I started a different one that added about > a dozen 'select MISC_DEVICES' statements sprinkled all over the kernel > in order to silence the Kconfig warnings. Ah, OK. This certainly shifts the scales towards your side. > The problem is that whenever you select that option, the misc directory > suddenly becomes visible when it was disabled before, and things like > 'oldconfig' will start asking about all other misc drivers as well. Another good point. Maybe I'm convinced now. > I think it would simply be more consistent to have it enabled all > the time. Well, even better would be to move the bulk of the misc > drivers to a proper location sorted by their subsystems. A lot of them > should never have been merged in their current state IMHO. As one of the offenders, I won't dare to comment on this ;) > > That being said, I'm not the one to decide, so if you can convince > > someone with more power (aka Andrew Morton)... > > I think I should finally do what has been talked about a few times and > formally become the maintainer of drivers/char and drivers/misc ;-) > > The problem is that I'm not actually a good maintainer, but maybe it's > better to just have someone instead of falling back to Andrew or > some random subsystem maintainer to send any patches for drivers/misc. Certainly. And having a maintainer for these (non-)subsystems would certainly help keep their size low, while the current trend is in the other direction. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Monday 05 September 2011, Jean Delvare wrote: > As said before, I'm not sure. Yes, it makes it easier to select misc > device drivers from Kconfig files. But it also makes it impossible to > deselect all misc device drivers at once. > > I think that what we really need is the implementation in the Kconfig > system of smart selects, i.e. whenever an entry is selected, everything > it depends on gets selected as well. I don't know how feasible this is, > but if it can be done then I'd prefer this to your proposal. > > Meanwhile, I am not in favor of applying your patch. The benefit is > relatively small IMHO (misc device drivers are rarely selected) and > there is one significant drawback. Before I made this patch, I started a different one that added about a dozen 'select MISC_DEVICES' statements sprinkled all over the kernel in order to silence the Kconfig warnings. The problem is that whenever you select that option, the misc directory suddenly becomes visible when it was disabled before, and things like 'oldconfig' will start asking about all other misc drivers as well. I think it would simply be more consistent to have it enabled all the time. Well, even better would be to move the bulk of the misc drivers to a proper location sorted by their subsystems. A lot of them should never have been merged in their current state IMHO. > That being said, I'm not the one to decide, so if you can convince > someone with more power (aka Andrew Morton)... I think I should finally do what has been talked about a few times and formally become the maintainer of drivers/char and drivers/misc ;-) The problem is that I'm not actually a good maintainer, but maybe it's better to just have someone instead of falling back to Andrew or some random subsystem maintainer to send any patches for drivers/misc. > > config AD525X_DPOT > > tristate "Analog Devices Digital Potentiometers" > > @@ -344,6 +328,12 @@ config ISL29020 > > This driver can also be built as a module. If so, the module > > will be called isl29020. > > > > +config SENSORS_LIS3LV02D > > + tristate > > + depends on INPUT > > + select INPUT_POLLDEV > > + default n > > + > > If you patch gets applied, then this one would better be moved to > drivers/misc/lis3lv02d/Kconfig. Ah, that's true. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
Hi Arnd, On Fri, 2 Sep 2011 16:43:14 +0200, Arnd Bergmann wrote: > Since misc devices have nothing in common besides fitting in no > other category, there is no need to group them in one Kconfig > symbol. Simply removing the symbol gets rid of all sorts of > Kconfig warnings about missing dependencies when another driver > selects a misc driver without also selecting MISC_DEVICES. > > Signed-off-by: Arnd Bergmann > --- > arch/arm/mach-davinci/Kconfig |6 -- > arch/unicore32/Kconfig|1 - > drivers/misc/Kconfig | 26 -- > drivers/mmc/host/Kconfig |1 - > 4 files changed, 8 insertions(+), 26 deletions(-) > (...) > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -2,23 +2,7 @@ > # Misc strange devices > # > > -# This one has to live outside of the MISC_DEVICES conditional, > -# because it may be selected by drivers/platform/x86/hp_accel. > -config SENSORS_LIS3LV02D > - tristate > - depends on INPUT > - select INPUT_POLLDEV > - default n > - > -menuconfig MISC_DEVICES > - bool "Misc devices" > - ---help--- > - Say Y here to get to see options for device drivers from various > - different categories. This option alone does not add any kernel code. > - > - If you say N, all options in this submenu will be skipped and > disabled. > - > -if MISC_DEVICES > +menu "Misc devices" As said before, I'm not sure. Yes, it makes it easier to select misc device drivers from Kconfig files. But it also makes it impossible to deselect all misc device drivers at once. I think that what we really need is the implementation in the Kconfig system of smart selects, i.e. whenever an entry is selected, everything it depends on gets selected as well. I don't know how feasible this is, but if it can be done then I'd prefer this to your proposal. Meanwhile, I am not in favor of applying your patch. The benefit is relatively small IMHO (misc device drivers are rarely selected) and there is one significant drawback. That being said, I'm not the one to decide, so if you can convince someone with more power (aka Andrew Morton)... > > config AD525X_DPOT > tristate "Analog Devices Digital Potentiometers" > @@ -344,6 +328,12 @@ config ISL29020 > This driver can also be built as a module. If so, the module > will be called isl29020. > > +config SENSORS_LIS3LV02D > + tristate > + depends on INPUT > + select INPUT_POLLDEV > + default n > + If you patch gets applied, then this one would better be moved to drivers/misc/lis3lv02d/Kconfig. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
Since misc devices have nothing in common besides fitting in no other category, there is no need to group them in one Kconfig symbol. Simply removing the symbol gets rid of all sorts of Kconfig warnings about missing dependencies when another driver selects a misc driver without also selecting MISC_DEVICES. Signed-off-by: Arnd Bergmann --- arch/arm/mach-davinci/Kconfig |6 -- arch/unicore32/Kconfig|1 - drivers/misc/Kconfig | 26 -- drivers/mmc/host/Kconfig |1 - 4 files changed, 8 insertions(+), 26 deletions(-) diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index c0deaca..3755cec 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -61,7 +61,6 @@ config MACH_DAVINCI_EVM bool "TI DM644x EVM" default ARCH_DAVINCI_DM644x depends on ARCH_DAVINCI_DM644x - select MISC_DEVICES select EEPROM_AT24 select I2C help @@ -71,7 +70,6 @@ config MACH_DAVINCI_EVM config MACH_SFFSDR bool "Lyrtech SFFSDR" depends on ARCH_DAVINCI_DM644x - select MISC_DEVICES select EEPROM_AT24 select I2C help @@ -105,7 +103,6 @@ config MACH_DAVINCI_DM6467_EVM default ARCH_DAVINCI_DM646x depends on ARCH_DAVINCI_DM646x select MACH_DAVINCI_DM6467TEVM - select MISC_DEVICES select EEPROM_AT24 select I2C help @@ -119,7 +116,6 @@ config MACH_DAVINCI_DM365_EVM bool "TI DM365 EVM" default ARCH_DAVINCI_DM365 depends on ARCH_DAVINCI_DM365 - select MISC_DEVICES select EEPROM_AT24 select I2C help @@ -131,7 +127,6 @@ config MACH_DAVINCI_DA830_EVM default ARCH_DAVINCI_DA830 depends on ARCH_DAVINCI_DA830 select GPIO_PCF857X - select MISC_DEVICES select EEPROM_AT24 select I2C help @@ -208,7 +203,6 @@ config MACH_TNETV107X config MACH_MITYOMAPL138 bool "Critical Link MityDSP-L138/MityARM-1808 SoM" depends on ARCH_DAVINCI_DA850 - select MISC_DEVICES select EEPROM_AT24 select I2C help diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig index e57dcce..5fb023a 100644 --- a/arch/unicore32/Kconfig +++ b/arch/unicore32/Kconfig @@ -244,7 +244,6 @@ config I2C_BATTERY_BQ27200 config I2C_EEPROM_AT24 tristate "I2C EEPROMs AT24 support" select PUV3_I2C - select MISC_DEVICES select EEPROM_AT24 config LCD_BACKLIGHT diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2d6423c..c11e5ba 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -2,23 +2,7 @@ # Misc strange devices # -# This one has to live outside of the MISC_DEVICES conditional, -# because it may be selected by drivers/platform/x86/hp_accel. -config SENSORS_LIS3LV02D - tristate - depends on INPUT - select INPUT_POLLDEV - default n - -menuconfig MISC_DEVICES - bool "Misc devices" - ---help--- - Say Y here to get to see options for device drivers from various - different categories. This option alone does not add any kernel code. - - If you say N, all options in this submenu will be skipped and disabled. - -if MISC_DEVICES +menu "Misc devices" config AD525X_DPOT tristate "Analog Devices Digital Potentiometers" @@ -344,6 +328,12 @@ config ISL29020 This driver can also be built as a module. If so, the module will be called isl29020. +config SENSORS_LIS3LV02D + tristate + depends on INPUT + select INPUT_POLLDEV + default n + config SENSORS_TSL2550 tristate "Taos TSL2550 ambient light sensor" depends on I2C && SYSFS @@ -507,4 +497,4 @@ source "drivers/misc/ti-st/Kconfig" source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" -endif # MISC_DEVICES +endmenu diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 8c87096..4fb03d4 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -477,7 +477,6 @@ config MMC_SDHI config MMC_CB710 tristate "ENE CB710 MMC/SD Interface support" depends on PCI - select MISC_DEVICES select CB710_CORE help This option enables support for MMC/SD part of ENE CB710/720 Flash -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
