From: Jiri Pirko <jiri@resnulli.us>
To: Grzegorz Nitka <grzegorz.nitka@intel.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, poros@redhat.com,
richardcochran@gmail.com, andrew+netdev@lunn.ch,
przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com,
Prathosh.Satish@microchip.com, ivecera@redhat.com,
arkadiusz.kubalewski@intel.com, vadim.fedorenko@linux.dev,
donald.hunter@gmail.com, horms@kernel.org, pabeni@redhat.com,
kuba@kernel.org, davem@davemloft.net, edumazet@google.com,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Subject: Re: [PATCH v11 net-next 1/8] dpll: add generic DPLL type
Date: Tue, 26 May 2026 15:28:38 +0200 [thread overview]
Message-ID: <ahWgAPoysfluToIf@FV6GYCPJ69> (raw)
In-Reply-To: <20260526093419.639220-2-grzegorz.nitka@intel.com>
Tue, May 26, 2026 at 11:34:12AM +0200, grzegorz.nitka@intel.com wrote:
>Add DPLL_TYPE_GENERIC to represent DPLL devices which do not fit the
>existing PPS or EEC classes.
>
>The UAPI type is intentionally generic. During netdev discussion,
>maintainers pointed out that introducing identifiers tied to a specific
>placement or single design does not scale across ASICs and vendors.
>The role of a DPLL is already inferable from the spawning driver,
>bus device, and pin topology, without encoding additional
>purpose-specific taxonomy in the type name.
>
>Using a generic type keeps the UAPI extensible and avoids premature
>naming that may become incorrect as new hardware topologies are
>exposed through the DPLL subsystem.
>
>Expose the new type through UAPI and netlink specification as "generic".
>
>Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us>
To: Grzegorz Nitka <grzegorz.nitka@intel.com>
Cc: ivecera@redhat.com,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
kuba@kernel.org, vadim.fedorenko@linux.dev, edumazet@google.com,
netdev@vger.kernel.org, richardcochran@gmail.com,
donald.hunter@gmail.com, linux-kernel@vger.kernel.org,
arkadiusz.kubalewski@intel.com, Prathosh.Satish@microchip.com,
andrew+netdev@lunn.ch, intel-wired-lan@lists.osuosl.org,
horms@kernel.org, przemyslaw.kitszel@intel.com,
anthony.l.nguyen@intel.com, pabeni@redhat.com,
davem@davemloft.net
Subject: Re: [Intel-wired-lan] [PATCH v11 net-next 1/8] dpll: add generic DPLL type
Date: Tue, 26 May 2026 15:28:38 +0200 [thread overview]
Message-ID: <ahWgAPoysfluToIf@FV6GYCPJ69> (raw)
In-Reply-To: <20260526093419.639220-2-grzegorz.nitka@intel.com>
Tue, May 26, 2026 at 11:34:12AM +0200, grzegorz.nitka@intel.com wrote:
>Add DPLL_TYPE_GENERIC to represent DPLL devices which do not fit the
>existing PPS or EEC classes.
>
>The UAPI type is intentionally generic. During netdev discussion,
>maintainers pointed out that introducing identifiers tied to a specific
>placement or single design does not scale across ASICs and vendors.
>The role of a DPLL is already inferable from the spawning driver,
>bus device, and pin topology, without encoding additional
>purpose-specific taxonomy in the type name.
>
>Using a generic type keeps the UAPI extensible and avoids premature
>naming that may become incorrect as new hardware topologies are
>exposed through the DPLL subsystem.
>
>Expose the new type through UAPI and netlink specification as "generic".
>
>Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
next prev parent reply other threads:[~2026-05-26 13:28 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 9:34 [PATCH v11 net-next 0/8] dpll/ice: Add generic DPLL type and full TX reference clock control for E825 Grzegorz Nitka
2026-05-26 9:34 ` [Intel-wired-lan] " Grzegorz Nitka
2026-05-26 9:34 ` [PATCH v11 net-next 1/8] dpll: add generic DPLL type Grzegorz Nitka
2026-05-26 9:34 ` [Intel-wired-lan] " Grzegorz Nitka
2026-05-26 13:28 ` Jiri Pirko [this message]
2026-05-26 13:28 ` Jiri Pirko
2026-05-26 9:34 ` [Intel-wired-lan] [PATCH v11 net-next 2/8] dpll: allow registering FW-identified pin with a different DPLL Grzegorz Nitka
2026-05-26 9:34 ` Grzegorz Nitka
2026-05-26 9:34 ` [Intel-wired-lan] [PATCH v11 net-next 3/8] dpll: extend pin notifier with notification source ID Grzegorz Nitka
2026-05-26 9:34 ` Grzegorz Nitka
2026-05-26 13:27 ` [Intel-wired-lan] " Jiri Pirko
2026-05-26 13:27 ` Jiri Pirko
2026-05-26 9:34 ` [Intel-wired-lan] [PATCH v11 net-next 4/8] dpll: allow fwnode pins to attempt state change without capability bit Grzegorz Nitka
2026-05-26 9:34 ` Grzegorz Nitka
2026-05-26 13:27 ` Jiri Pirko
2026-05-26 13:27 ` [Intel-wired-lan] " Jiri Pirko
2026-05-26 9:34 ` [Intel-wired-lan] [PATCH v11 net-next 5/8] ice: introduce TXC DPLL device and TX ref clock pin framework for E825 Grzegorz Nitka
2026-05-26 9:34 ` Grzegorz Nitka
2026-05-28 8:55 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-05-28 8:55 ` Loktionov, Aleksandr
2026-05-26 9:34 ` [Intel-wired-lan] [PATCH v11 net-next 6/8] ice: implement CPI support for E825C Grzegorz Nitka
2026-05-26 9:34 ` Grzegorz Nitka
2026-05-28 8:55 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-05-28 8:55 ` Loktionov, Aleksandr
2026-05-28 12:24 ` Loktionov, Aleksandr
2026-05-28 12:24 ` Loktionov, Aleksandr
2026-05-29 14:35 ` Nitka, Grzegorz
2026-05-29 14:35 ` Nitka, Grzegorz
2026-05-26 9:34 ` [Intel-wired-lan] [PATCH v11 net-next 7/8] ice: add Tx reference clock index handling to AN restart command Grzegorz Nitka
2026-05-26 9:34 ` Grzegorz Nitka
2026-05-26 9:34 ` [Intel-wired-lan] [PATCH v11 net-next 8/8] ice: implement E825 TX ref clock control and TXC hardware sync status Grzegorz Nitka
2026-05-26 9:34 ` Grzegorz Nitka
2026-05-28 12:21 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-05-28 12:21 ` Loktionov, Aleksandr
2026-05-29 15:08 ` Nitka, Grzegorz
2026-05-29 15:08 ` Nitka, Grzegorz
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=ahWgAPoysfluToIf@FV6GYCPJ69 \
--to=jiri@resnulli.us \
--cc=Prathosh.Satish@microchip.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=grzegorz.nitka@intel.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=ivecera@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=poros@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.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 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.