From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "jdelvare@suse.com" <jdelvare@suse.com>,
"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 4/4] hwmon: (adt7470) Use standard update_interval property
Date: Mon, 30 Aug 2021 20:59:24 +0000 [thread overview]
Message-ID: <dace3f40-8038-2867-dc20-596f8bc0ebe2@alliedtelesis.co.nz> (raw)
In-Reply-To: <e467a3b2-d7c7-0920-9287-fb3e7abd5fae@roeck-us.net>
On 31/08/21 3:36 am, Guenter Roeck wrote:
> On 8/29/21 2:09 PM, Chris Packham wrote:
>>
>> On 28/08/21 9:29 am, Guenter Roeck wrote:
>>> On Thu, Aug 26, 2021 at 02:41:21PM +1200, Chris Packham wrote:
>>>> Instead of the non-standard auto_update_interval make use of the
>>>> update_interval property that is supported by the hwmon core.
>>>>
>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>>> ---
>>>>
>>>> Notes:
>>>> I kind of anticipate a NAK on this because it affects the
>>>> ABI. But I figured
>>>> I'd run it past the ML to see if moving towards the hwmon
>>>> core is worth the hit
>>>> in ABI compatibility.
>>> I personally don't mind (most likely no one is using it anyway), but
>>> let's
>>> wait until after the upcoming commit window closes to give people
>>> time to
>>> complain.
>>
>> I know of one application using this sysfs entry. But it's our in-house
>> environmental monitoring code so if this gets merged I'll just update it
>> to use the new path.
>>
>> One thought I had was we could do both. i.e. have an entry that conforms
>> to the hwmon core and a backwards compatible entry that just aliases the
>> new path.
>>
> Now you almost convinced me to indeed reject this patch. The idea of
> the new API
> is to simplify driver code, not to make it more complicated. If we
> can't simplify
> the code, it is better to leave it alone.
Sold. I agree what I've just suggested is adding more complexity without
much gain. If something does start to care about having a standard
update_interval property we could resurrect this.
>
> Guenter
prev parent reply other threads:[~2021-08-30 20:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-26 2:41 [PATCH v2 0/4] hwmon: (adt7470) Clean up Chris Packham
2021-08-26 2:41 ` [PATCH v2 1/4] hwmon: (adt7470) Fix some style issues Chris Packham
2021-08-27 21:15 ` Guenter Roeck
2021-08-26 2:41 ` [PATCH v2 2/4] hwmon: (adt7470) Convert to use regmap Chris Packham
2021-08-27 21:17 ` Guenter Roeck
2021-08-26 2:41 ` [PATCH v2 3/4] hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API Chris Packham
2021-08-27 21:26 ` Guenter Roeck
2021-08-26 2:41 ` [PATCH v2 4/4] hwmon: (adt7470) Use standard update_interval property Chris Packham
2021-08-27 21:29 ` Guenter Roeck
2021-08-29 21:09 ` Chris Packham
2021-08-30 15:36 ` Guenter Roeck
2021-08-30 20:59 ` Chris Packham [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dace3f40-8038-2867-dc20-596f8bc0ebe2@alliedtelesis.co.nz \
--to=chris.packham@alliedtelesis.co.nz \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).