linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	Vadim Fedorenko <vadfed@meta.com>,
	Jonathan Lemon <jonathan.lemon@gmail.com>,
	Paolo Abeni <pabeni@redhat.com>, poros <poros@redhat.com>,
	mschmidt <mschmidt@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"Olech, Milena" <milena.olech@intel.com>,
	"Michalik, Michal" <michal.michalik@intel.com>
Subject: Re: [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions
Date: Wed, 3 May 2023 19:16:43 -0700	[thread overview]
Message-ID: <20230503191643.12a6e559@kernel.org> (raw)
In-Reply-To: <ZFITyWvVcqgRtN+Q@nanopsycho>

On Wed, 3 May 2023 09:56:57 +0200 Jiri Pirko wrote:
> >Yup, non-deterministic, just a cyclic ID allocated by the core starting
> >from 1. Finding the right device / pin needs to be done via
> >informational attributes not making assumptions about the ID.  
> 
> Okay.
> 
> When netdev will have pin ID in the RT netlink message (as it is done
> in RFCv7), it is easy to get the pin/dpll for netdev. No problem there.
> 
> However, for non-SyncE usecase, how do you imagine scripts to work?
> I mean, the script have to obtain dpll/pin ID by deterministic
> module_name/clock_id/idx tuple.

No scoped idx.

> There are 2 options to do that:
> 1) dump all dplls/pins and do lookup in userspace
> 2) get a dpll/pin according to given module_name/clock_id/idx tuple
> 
> The first approach is not very nice.
> The currently pushed RFCv7 of the patchset does not support 2)
> 
> Now if we add support for 2), we basically use module_name/clock_id/idx
> as a handle for "get cmd". My point is, why can't we use it for "set
> cmd" as well and avoid the ID entirely?

Sure, we don't _have_ to have an ID, but it seems go against normal
data normalization rules. And I don't see any harm in it.

But you're asking for per-device "idx" and that's a no-go for me,
given already cited experience.

The user space can look up the ID based on identifying information it
has. IMO it's better to support multiple different intelligible elements
than single integer index into which drivers will start encoding all
sort of info, using locally invented schemes.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-05-04  2:18 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-12  2:28 [PATCH RFC v6 0/6] Create common DPLL/clock configuration API Vadim Fedorenko
2023-03-12  2:28 ` [PATCH RFC v6 1/6] dpll: spec: Add Netlink spec in YAML Vadim Fedorenko
2023-03-14 14:44   ` Jiri Pirko
2023-03-16 13:15     ` Kubalewski, Arkadiusz
2023-03-16 13:45       ` Jiri Pirko
2023-03-16 15:19         ` Jiri Pirko
2023-03-17  0:53           ` Kubalewski, Arkadiusz
2023-03-17 10:07             ` Jiri Pirko
2023-03-17  0:52         ` Kubalewski, Arkadiusz
2023-03-17 10:05           ` Jiri Pirko
2023-03-17 14:29             ` Jiri Pirko
2023-03-17 15:14             ` Kubalewski, Arkadiusz
2023-03-17 16:20               ` Jiri Pirko
2023-03-17 18:22                 ` Kubalewski, Arkadiusz
2023-03-20  8:10                   ` Jiri Pirko
2023-03-21  4:05       ` Jakub Kicinski
2023-03-21  4:13         ` Jakub Kicinski
2023-03-21  4:20           ` Jakub Kicinski
2023-03-17 16:23   ` Jiri Pirko
2023-03-21  4:00     ` Jakub Kicinski
2023-03-17 16:53   ` Jiri Pirko
2023-03-17 18:50     ` Kubalewski, Arkadiusz
2023-03-12  2:28 ` [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions Vadim Fedorenko
2023-03-13 16:21   ` Jiri Pirko
2023-03-13 22:59     ` Vadim Fedorenko
2023-03-14 16:43       ` Kubalewski, Arkadiusz
2023-03-15 12:14         ` Jiri Pirko
     [not found]       ` <ZBA8ofFfKigqZ6M7@nanopsycho>
2023-03-14 17:50         ` Kubalewski, Arkadiusz
2023-03-15  9:22           ` Jiri Pirko
2023-03-16 12:31             ` Jiri Pirko
2023-03-28 15:22             ` Vadim Fedorenko
2023-04-01 12:49               ` Jiri Pirko
2023-04-03 18:18             ` Jakub Kicinski
2023-04-09  7:51               ` Jiri Pirko
     [not found]                 ` <20230410153149.602c6bad@kernel.org>
2023-04-16 16:23                   ` Jiri Pirko
2023-04-17 15:53                     ` Vadim Fedorenko
     [not found]                     ` <20230417124942.4305abfa@kernel.org>
2023-04-27  8:05                       ` Paolo Abeni
2023-04-27 10:20                         ` Vadim Fedorenko
     [not found]                       ` <ZFDPaXlJainSOqmV@nanopsycho>
     [not found]                         ` <20230502083244.19543d26@kernel.org>
2023-05-03  7:56                           ` Jiri Pirko
2023-05-04  2:16                             ` Jakub Kicinski [this message]
2023-05-04 11:00                               ` Jiri Pirko
2023-05-04 11:14                                 ` Jiri Pirko
2023-05-04 16:04                                 ` Jakub Kicinski
2023-05-04 17:51                                   ` Jiri Pirko
2023-05-04 18:44                                     ` Jakub Kicinski
2023-05-05 10:41                                       ` Jiri Pirko
2023-05-05 15:35                                         ` Jakub Kicinski
2023-05-07  7:58                                           ` Jiri Pirko
2023-03-14 15:45   ` Jiri Pirko
2023-03-14 18:35     ` Kubalewski, Arkadiusz
2023-03-15 14:43       ` Jiri Pirko
2023-03-15 15:29   ` Jiri Pirko
2023-03-16 12:20   ` Jiri Pirko
2023-03-16 12:37   ` Jiri Pirko
2023-03-16 13:53   ` Jiri Pirko
2023-03-16 16:16   ` Jiri Pirko
2023-03-17 16:21   ` Jiri Pirko
2023-03-20 10:24   ` Jiri Pirko
2023-03-21 13:34   ` Jiri Pirko
2023-03-23 11:18   ` Jiri Pirko
2023-03-24  9:29   ` Jiri Pirko
2023-03-12  2:28 ` [PATCH RFC v6 3/6] dpll: documentation on DPLL subsystem interface Vadim Fedorenko
2023-03-14 16:14   ` Jiri Pirko
2023-04-03 10:21     ` Kubalewski, Arkadiusz
2023-03-16 13:46   ` Jiri Pirko
2023-04-03 10:23     ` Kubalewski, Arkadiusz
2023-03-12  2:28 ` [PATCH RFC v6 4/6] ice: add admin commands to access cgu configuration Vadim Fedorenko
2023-03-12  2:28 ` [PATCH RFC v6 5/6] ice: implement dpll interface to control cgu Vadim Fedorenko
2023-03-12  2:28 ` [PATCH RFC v6 6/6] ptp_ocp: implement DPLL ops Vadim Fedorenko
     [not found]   ` <ZBBG2xRhLOIPMD0+@nanopsycho>
2023-03-15  0:10     ` Vadim Fedorenko
2023-03-15 12:24       ` Jiri Pirko
2023-03-31 23:28         ` Vadim Fedorenko
2023-04-01 12:53           ` Jiri Pirko
2023-03-15 15:34   ` Jiri Pirko
2023-03-15 15:52     ` Vadim Fedorenko
2023-03-16 12:12   ` Jiri Pirko
2023-03-13 12:20 ` [PATCH RFC v6 0/6] Create common DPLL/clock configuration API Jiri Pirko
2023-03-13 15:33   ` Vadim Fedorenko
2023-03-13 16:22     ` Jiri Pirko
2023-03-13 16:31       ` Vadim Fedorenko
2023-03-17 16:10     ` Jiri Pirko
2023-03-18  5:01       ` Jakub Kicinski
2023-03-23 11:21 ` Jiri Pirko
2023-03-23 18:00   ` Vadim Fedorenko
2023-03-26 17:00 ` [patch dpll-rfc 0/7] dpll: initial patchset extension by mlx5 implementation Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 1/7] dpll: make ops function args const Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 2/7] dpll: allow to call device register multiple times Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 3/7] dpll: introduce a helper to get first dpll ref and use it Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 4/7] dpll: allow to call pin register multiple times Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 5/7] dpll: export dpll_pin_notify() Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 6/7] netdev: expose DPLL pin handle for netdevice Jiri Pirko
2023-03-26 17:00   ` [patch dpll-rfc 7/7] mlx5: Implement SyncE support using DPLL infrastructure Jiri Pirko
2023-03-28 16:36   ` [patch dpll-rfc 0/7] dpll: initial patchset extension by mlx5 implementation Vadim Fedorenko
2023-04-01 12:54     ` Jiri Pirko

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=20230503191643.12a6e559@kernel.org \
    --to=kuba@kernel.org \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=jiri@resnulli.us \
    --cc=jonathan.lemon@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=michal.michalik@intel.com \
    --cc=milena.olech@intel.com \
    --cc=mschmidt@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=poros@redhat.com \
    --cc=vadfed@meta.com \
    --cc=vadim.fedorenko@linux.dev \
    /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).