All of lore.kernel.org
 help / color / mirror / Atom feed
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 2/3] thermal: netlink: Add genetlink bind/unbind notifications
Date: Thu, 22 Feb 2024 16:47:18 +0100	[thread overview]
Message-ID: <ZddshlCHwsDTFSYL@linux.intel.com> (raw)
In-Reply-To: <CAJZ5v0hTsXjre_StGizrmUx1JUkzKr9K9KLiHrsvicivMO2Odw@mail.gmail.com>

On Tue, Feb 13, 2024 at 02:24:56PM +0100, Rafael J. Wysocki wrote:
> On Mon, Feb 12, 2024 at 5:16 PM Stanislaw Gruszka
> <stanislaw.gruszka@linux.intel.com> wrote:
> >
> > Introduce a new feature to the thermal netlink framework, enabling the
> > registration of sub drivers to receive events via a notifier mechanism.
> > Specifically, implement genetlink family bind and unbind callbacks to send
> > BIND and UNBIND events.
> >
> > The primary purpose of this enhancement is to facilitate the tracking of
> > user-space consumers by the intel_hif driver.
> 
> This should be intel_hfi.  Or better, Intel HFI.

Will change in next revision.

> > By leveraging these
> > notifications, the driver can determine when consumers are present
> > or absent.
> >
> > Suggested-by: Jakub Kicinski <kuba@kernel.org>
> > Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
> > ---
> >  drivers/thermal/thermal_netlink.c | 40 +++++++++++++++++++++++++++----
> >  drivers/thermal/thermal_netlink.h | 26 ++++++++++++++++++++
> >  2 files changed, 61 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/thermal/thermal_netlink.c b/drivers/thermal/thermal_netlink.c
> > index 76a231a29654..86c7653a9530 100644
> > --- a/drivers/thermal/thermal_netlink.c
> > +++ b/drivers/thermal/thermal_netlink.c
> > @@ -7,17 +7,13 @@
> >   * Generic netlink for thermal management framework
> >   */
> >  #include <linux/module.h>
> > +#include <linux/notifier.h>
> >  #include <linux/kernel.h>
> >  #include <net/genetlink.h>
> >  #include <uapi/linux/thermal.h>
> >
> >  #include "thermal_core.h"
> >
> > -enum thermal_genl_multicast_groups {
> > -       THERMAL_GENL_SAMPLING_GROUP = 0,
> > -       THERMAL_GENL_EVENT_GROUP = 1,
> > -};
> > -
> >  static const struct genl_multicast_group thermal_genl_mcgrps[] = {
> 
> There are enough characters per code line to spell "multicast_groups"
> here (and analogously below).

Not sure what you mean, change thermal_genl_mcgrps to thermal_genl_multicast_groups ?

I could change that, but it's not really related to the changes in this patch,
so perhaps in separate patch.

Additionally "mcgrps" are more consistent with genl_family fields i.e:

      .mcgrps         = thermal_genl_mcgrps,
      .n_mcgrps       = ARRAY_SIZE(thermal_genl_mcgrps), 

> >         [THERMAL_GENL_SAMPLING_GROUP] = { .name = THERMAL_GENL_SAMPLING_GROUP_NAME, },
> >         [THERMAL_GENL_EVENT_GROUP]  = { .name = THERMAL_GENL_EVENT_GROUP_NAME,  },
> > @@ -75,6 +71,7 @@ struct param {
> >  typedef int (*cb_t)(struct param *);
> >
> >  static struct genl_family thermal_gnl_family;
> > +static BLOCKING_NOTIFIER_HEAD(thermal_gnl_chain);
> 
> thermal_genl_chain ?
> 
> It would be more consistent with the rest of the naming.

Ok, will change. Additionally in separate patch thermal_gnl_family for consistency.

> >  static int thermal_group_has_listeners(enum thermal_genl_multicast_groups group)
> >  {
> > @@ -645,6 +642,27 @@ static int thermal_genl_cmd_doit(struct sk_buff *skb,
> >         return ret;
> >  }
> >
> > +static int thermal_genl_bind(int mcgrp)
> > +{
> > +       struct thermal_genl_notify n = { .mcgrp = mcgrp };
> > +
> > +       if (WARN_ON_ONCE(mcgrp > THERMAL_GENL_MAX_GROUP))
> > +               return -EINVAL;
> 
> pr_warn_once() would be better IMO.  At least it would not crash the
> kernel configured with "panic on warn".

"panic on warn" is generic WARN_* issue at any place where WARN_* are used.
And I would say, crash is desired behaviour for those who use the option
to catch bugs. And mcgrp bigger than THERMAL_GENL_MAX_GROUP is definitely
a bug. Additionally pr_warn_once() does not print call trace, so I think
WARN_ON_ONCE() is more proper. But if really you prefer pr_warn_once()
I can change.

Regards
Stanislaw

  reply	other threads:[~2024-02-22 15:47 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 [this message]
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
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=ZddshlCHwsDTFSYL@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 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.