On Fri, Jan 07, 2011 at 07:12:13AM -0500, J, KEERTHY 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. > Other drivers don't _export_ that functionality. Key difference. Sure, the lis3 driver does, but that should not be in hwmon in the first place and is on the way out (if I ever get to do it), and max1111 is just setting a bad example. Guenter -- 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
