Re: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module

[Samuel Ortiz <sameo@linux.intel.com>]

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@ti.com> wrote:
> > On Fri, Jan 7, 2011 at 3:25 AM, Guenter Roeck
> > <guenter.roeck@ericsson.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html