From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Naresh Solanki <naresh.solanki@9elements.com>,
broonie@kernel.org, Liam Girdwood <lgirdwood@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] regulator: event: Add netlink command for event mask
Date: Tue, 16 Jan 2024 14:46:41 +0200 [thread overview]
Message-ID: <e3e16af2-7f8d-4776-9726-f6282128a766@gmail.com> (raw)
In-Reply-To: <20240116103131.413205-1-naresh.solanki@9elements.com>
Hi Naresh,
Thanks for working on this! :)
On 1/16/24 12:31, Naresh Solanki wrote:
> Add netlink command to enable perticular event(s) broadcasting instead
> of all regulator events.
I think this mechanism for limiting events being forwarded to the
listener is worthy. My original idea was to utilize the netlink
multicast groups for this so that the regulator core would register
multiple multicast groups for this family. User would then listen only
the groups he is interested, and multiplexing the messages would be done
by netlink/socket code.
Problem(?) of the approach you propose here is that the event filtering
is global for all users. If multicast groups were used, this filtering
would be done per listener socket basis. I'm not sure if that would be
needed though, but somehow I feel it would be more usable for different
user-land appliactions (cost being the increased complexity though).
Eg, I am thinking users could enable receiving multicasts for events
they like using:
setsockopt(..., SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, ..., ...)
Do you think allowing setting the 'filtering' this way per socket would
work or be beneficial?
> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
>
> ...
> Changes in v2:
> - Update attribute to REG_GENL_ATTR_SET_EVENT_MASK
> ---
> drivers/regulator/event.c | 28 ++++++++++++++++++++++++++++
> include/uapi/regulator/regulator.h | 1 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/regulator/event.c b/drivers/regulator/event.c
> index ea3bd49544e8..181d16f54a21 100644
> --- a/drivers/regulator/event.c
> +++ b/drivers/regulator/event.c
> @@ -14,17 +14,41 @@
>
> static atomic_t reg_event_seqnum = ATOMIC_INIT(0);
>
> +static u64 event_mask;
> +
> static const struct genl_multicast_group reg_event_mcgrps[] = {
> { .name = REG_GENL_MCAST_GROUP_NAME, },
> };
>
> +static int reg_genl_cmd_doit(struct sk_buff *skb, struct genl_info *info)
> +{
> + if (info->attrs[REG_GENL_ATTR_SET_EVENT_MASK]) {
> + event_mask = nla_get_u64(info->attrs[REG_GENL_ATTR_SET_EVENT_MASK]);
If we go with just a global event_mask (not per listener) event
filtering, then we might need protection/barrier for this write of a
64bit value(?)
> + pr_info("event_mask -> %llx", event_mask);
I would drop this print, or by very least, make it dbg.
> + return 0;
> + }
> + pr_warn("Unknown attribute.");
I would make this dbg as well.
> + return -EOPNOTSUPP;
> +}
> +
> +static const struct genl_small_ops reg_genl_ops[] = {
> + {
> + .cmd = REG_GENL_CMD_EVENT,
> + .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
> + .doit = reg_genl_cmd_doit,
> + }
> +};
> +
> static struct genl_family reg_event_genl_family __ro_after_init = {
> .module = THIS_MODULE,
> .name = REG_GENL_FAMILY_NAME,
> .version = REG_GENL_VERSION,
> .maxattr = REG_GENL_ATTR_MAX,
> + .small_ops = reg_genl_ops,
> + .n_small_ops = ARRAY_SIZE(reg_genl_ops),
> .mcgrps = reg_event_mcgrps,
> .n_mcgrps = ARRAY_SIZE(reg_event_mcgrps),
> + .resv_start_op = __REG_GENL_CMD_MAX,
> };
>
> int reg_generate_netlink_event(const char *reg_name, u64 event)
> @@ -35,6 +59,9 @@ int reg_generate_netlink_event(const char *reg_name, u64 event)
> void *msg_header;
> int size;
>
Barrier/locking here too?
> + if (!(event_mask & event))
> + return 0; > +
> /* allocate memory */
> size = nla_total_size(sizeof(struct reg_genl_event)) +
> nla_total_size(0);
> @@ -73,6 +100,7 @@ int reg_generate_netlink_event(const char *reg_name, u64 event)
>
> static int __init reg_event_genetlink_init(void)
> {
> + event_mask = 0;
> return genl_register_family(®_event_genl_family);
> }
>
> diff --git a/include/uapi/regulator/regulator.h b/include/uapi/regulator/regulator.h
> index 71bf71a22e7f..2a0af512b61c 100644
> --- a/include/uapi/regulator/regulator.h
> +++ b/include/uapi/regulator/regulator.h
> @@ -69,6 +69,7 @@ struct reg_genl_event {
> enum {
> REG_GENL_ATTR_UNSPEC,
> REG_GENL_ATTR_EVENT, /* reg event info needed by user space */
> + REG_GENL_ATTR_SET_EVENT_MASK, /* reg event mask */
> __REG_GENL_ATTR_MAX,
> };
>
>
> base-commit: 94cc3087aac4103c33c6da84c092301afd783200
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
next prev parent reply other threads:[~2024-01-16 12:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 10:31 Naresh Solanki
2024-01-16 12:46 ` Matti Vaittinen [this message]
2024-01-16 15:18 ` Mark Brown
2024-01-18 14:20 ` Mark Brown
2024-01-18 15:20 ` Naresh Solanki
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=e3e16af2-7f8d-4776-9726-f6282128a766@gmail.com \
--to=mazziesaccount@gmail.com \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=naresh.solanki@9elements.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
all inboxes | Powered by JetHome®