From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: linux-pm@vger.kernel.org,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jiri Pirko <jiri@resnulli.us>,
Johannes Berg <johannes@sipsolutions.net>,
Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org
Subject: Re: [PATCH v4 3/3] thermal: intel: hfi: Enable interface only when required
Date: Thu, 22 Feb 2024 17:53:21 +0100 [thread overview]
Message-ID: <Zdd8AT5+6oLX4eCk@linux.intel.com> (raw)
In-Reply-To: <CAJZ5v0jr4Z=ffm9E+eR7p7rQwbCWEP=YHxNbR9VAEwb8-3e3GA@mail.gmail.com>
On Tue, Feb 13, 2024 at 02:59:10PM +0100, Rafael J. Wysocki wrote:
> > -static void hfi_do_enable(void)
> > +/*
> > + * HFI enable/disable run in non-concurrent manner on boot CPU in syscore
> > + * callbacks or under protection of hfi_instance_lock.
> > + */
>
> In the comment above I would say "If concurrency is not prevented by
> other means, the HFI enable/disable routines must be called under
> hfi_instance_lock."
Ok. Will reword this way.
> and I would retain the comments below (they don't
> hurt IMO).
I found those comments somewhat confusing. FWICT at worst
what can happen when enable/resume race CPU online and
disable/suspend race with CPU offline is enable twice
or disable twice. What I think is fine, though plan to
check this (see below).
> > +static void hfi_do_enable(void *ptr)
>
> I would call this hfi_enable_instance().
>
> > +{
> > + struct hfi_instance *hfi_instance = ptr;
>
> Why is this variable needed ro even useful? prt can be passed
> directly to hfi_set_hw_table().
Ok, will remove it.
> > +
> > + hfi_set_hw_table(hfi_instance);
> > + hfi_enable();
> > +}
> > +
> > +static void hfi_do_disable(void *ptr)
>
> And I'd call this hfi_disable_instance().
Ok.
> > +static int hfi_thermal_notify(struct notifier_block *nb, unsigned long state,
> > + void *_notify)
> > +{
> > + struct thermal_genl_notify *notify = _notify;
> > + struct hfi_instance *hfi_instance;
> > + smp_call_func_t func;
> > + unsigned int cpu;
> > + int i;
> > +
> > + if (notify->mcgrp != THERMAL_GENL_EVENT_GROUP)
> > + return NOTIFY_DONE;
> > +
> > + if (state != THERMAL_NOTIFY_BIND && state != THERMAL_NOTIFY_UNBIND)
> > + return NOTIFY_DONE;
> > +
> > + mutex_lock(&hfi_instance_lock);
> > +
> > + switch (state) {
> > + case THERMAL_NOTIFY_BIND:
> > + hfi_thermal_clients_num++;
> > + break;
> > +
> > + case THERMAL_NOTIFY_UNBIND:
> > + hfi_thermal_clients_num--;
> > + break;
> > + }
> > +
> > + if (hfi_thermal_clients_num > 0)
> > + func = hfi_do_enable;
> > + else
> > + func = hfi_do_disable;
> > +
> > + for (i = 0; i < max_hfi_instances; i++) {
> > + hfi_instance = &hfi_instances[i];
> > + if (cpumask_empty(hfi_instance->cpus))
> > + continue;
> > +
> > + cpu = cpumask_any(hfi_instance->cpus);
> > + smp_call_function_single(cpu, func, hfi_instance, true);
> > + }
> > +
> > + mutex_unlock(&hfi_instance_lock);
>
> So AFAICS, one instance can be enabled multiple times because of this.
> I guess that's OK? In any case, it would be kind of nice to leave a
> note regarding it somewhere here.
It's write the same values to the same registers. So I think this
should be fine. However after your comment I start to think there
perhaps could be some side-effect of writing the registers.
I'll double check (previously I verified that double enable works,
but only on MTL) or eventually rearrange code to do not enable already
enabled interface.
> > +
> > + return NOTIFY_OK;
> > +}
> > +
> > +static struct notifier_block hfi_thermal_nb = {
> > + .notifier_call = hfi_thermal_notify,
> > };
> >
> > void __init intel_hfi_init(void)
> > @@ -628,10 +697,16 @@ void __init intel_hfi_init(void)
> > if (!hfi_updates_wq)
> > goto err_nomem;
> >
> > + if (thermal_genl_register_notifier(&hfi_thermal_nb))
> > + goto err_nl_notif;
>
> Is it possible for any clients to be there before the notifier is
> registered? If not, it would be good to add a comment about it.
HFI is build-in so it's started before any user space. I added note about that
in the cover letter but indeed it should be comment in the code. Will fix.
Regards
Stanislaw
next prev parent reply other threads:[~2024-02-22 16:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 16:16 [PATCH v4 0/3] thermal/netlink/intel_hfi: Enable HFI feature only when required Stanislaw Gruszka
2024-02-12 16:16 ` [PATCH v4 1/3] genetlink: Add per family bind/unbind callbacks Stanislaw Gruszka
2024-02-13 1:07 ` Jakub Kicinski
2024-02-13 1:52 ` srinivas pandruvada
2024-02-13 9:11 ` Jiri Pirko
2024-02-12 16:16 ` [PATCH v4 2/3] thermal: netlink: Add genetlink bind/unbind notifications Stanislaw Gruszka
2024-02-13 13:24 ` Rafael J. Wysocki
2024-02-22 15:47 ` Stanislaw Gruszka
2024-02-22 15:55 ` Rafael J. Wysocki
2024-02-12 16:16 ` [PATCH v4 3/3] thermal: intel: hfi: Enable interface only when required Stanislaw Gruszka
2024-02-13 13:59 ` Rafael J. Wysocki
2024-02-22 16:53 ` Stanislaw Gruszka [this message]
2024-02-16 5:29 ` [PATCH v4 0/3] thermal/netlink/intel_hfi: Enable HFI feature " Jakub Kicinski
2024-02-23 15:44 ` Stanislaw Gruszka
2024-02-16 5:30 ` patchwork-bot+netdevbpf
2024-02-29 15:18 ` Rafael J. Wysocki
2024-02-29 16:13 ` Stanislaw Gruszka
2024-02-29 16:24 ` Rafael J. Wysocki
2024-03-27 13:53 ` Rafael J. Wysocki
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=Zdd8AT5+6oLX4eCk@linux.intel.com \
--to=stanislaw.gruszka@linux.intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rafael@kernel.org \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
/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).