Hi Keerthy, On Sat, Jan 22, 2011 at 10:19:33PM +0530, J, KEERTHY wrote: > On Fri, Jan 7, 2011 at 5:42 PM, J, KEERTHY <j-keerthy@xxxxxx> wrote: > > On Fri, Jan 7, 2011 at 3:25 AM, Guenter Roeck > > <guenter.roeck@xxxxxxxxxxxx> wrote: > >> On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote: > >>> On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote: > >>> > On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote: > >>> > >>> > > Why? It's not like hwmon has an unreasonably large core or similar. > >>> > >>> > Because it creates an unnecessary dependency, and because it is not hwmon's > >>> > responsibility to provide infrastructure for other subsystems or drivers. > >>> > >>> hwmon isn't really doing anything, though. The *driver* is doing > >>> something but it doesn't really impact the core that much. Not that I'm > >>> particularly sold on putting the ADC core in here, but total NACK based > >>> on that alone seems rather harsh. > >> > >> Possibly. However, I had suggested the following earlier (to the 1st > >> version of the patch): > >> > >>> I commented on this a couple of times below - the driver mixes generic > >>> ADC reading functions with hwmon functionality. Generic ADC reading > >>> functionality should be moved into another driver, possibly to mfd. > >> > >> Obviously that was ignored. Maybe someone is willing to listen this time > >> around. > >> > > I am sorry for not responding on the generic ADC handling part. Since many > > other ADC drivers are part of hwmon i thought hwmon was the appropriate > > place. However I can surely split the generic ADC handling part in mfd and > > only hardware monitoring part in hwmon as suggested. > > > >> I won't let people break modularity just for convenience in a subsystem > >> I am responsible for. And forcing the hwmon subsystem, and with it a > >> specific hwmon driver, to exist just because the adc functionality it > >> provides is needed by some other (most likely unrelated) subsystem / > >> driver _does_ break modularity. Worse, it is completely unnecessary to > >> do so. Other twl4030 functionality was extracted into generic code. > >> twl-core.c, twl4030-codec.c, twl4030-irq.c, twl4030-power.c are all in > >> mfd. I fail to see the problem with mfd/twl4030-adc.c. > >> > >> Guenter > >> > >> > >> > > > > Hello Samuel, > > > > Is it ok to have the generic ADC functionality in mfd as a separate file? > > > > Regards, > > Keerthy > > > > Hello Samuel, > > We need your valuable inputs. Can generic ADC functionality can be in > mfd as a separate file? If it's really generic and doesn't mix hwmon stuff in the middle, then yes. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
