All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
	Peter Kaestle <peter@piie.net>, Mark Gross <markgross@kernel.org>,
	"open list:ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER" 
	<platform-driver-x86@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: acerhdf thermal question
Date: Thu, 16 Feb 2023 06:45:48 -0500	[thread overview]
Message-ID: <Y+4XbJR/WxCyN0EK@windriver.com> (raw)
In-Reply-To: <ee826228-3fbb-bf66-b2a1-8e8be2776175@redhat.com>

[Re: acerhdf thermal question] On 16/02/2023 (Thu 10:08) Hans de Goede wrote:

> Hi Daniel,
> 
> On 2/16/23 09:57, Daniel Lezcano wrote:
> > 
> > Hi,
> > 
> > the polling interval is specified and modified via a kernel module parameter [1]
> > 
> > The value is used to change the polling interval of the thermal zone, implying that is accessing the thermal zone device structure internals directly [2]
> > 
> > In real use case, is the interval changed at runtime? Or just when the module is loaded? If the latter, the interval can be passed to the thermal zone at init time without doing a polling change rate after the thermal zone started. In this case, we can remove the polling_delay_jiffies change in the code and fix the structure leakage in this driver.
> 
> I believe this very likely only is used at module load-time.
> So the changes you suggest are fine with me.
> 
> I have added Paul Gortmaker to the Cc, Paul is the last person
> to have done any real (*) work on acerhfd AFAICT.
> 
> Paul any objections against making the acerhdf.interval parameter
> something which only works when set at boot / module load time
> and removing the ability to change it at runtime ?

Not that I have any real authority, beyond "touched it last", but
that aside, I'd say that if it is blocking other subsystem cleanups,
then by all means make it load-time only.

It was already obsolete hardware when I was tinkering with it, and
to my surprise -- that was already five years ago!  There can't be a
large user base out there - and even less tinkering with poll delay.

Paul.
--

> 
> Regards,
> 
> Hans
> 
> 
> *) Real as in not related to keeping it aligned with the thermal
> framework/core
> 
> 

  parent reply	other threads:[~2023-02-16 11:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16  8:57 acerhdf thermal question Daniel Lezcano
2023-02-16  9:08 ` Hans de Goede
2023-02-16  9:11   ` Hans de Goede
2023-02-16 11:45   ` Paul Gortmaker [this message]
2023-02-18  0:18     ` Peter Kästle

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=Y+4XbJR/WxCyN0EK@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=peter@piie.net \
    --cc=platform-driver-x86@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.