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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

Regards and Thanks,
Keerthy
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux