netdev - Re: [PATCH v2 net-next 01/14] dt-bindings: ptp: add NETC Timer PTP clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aHkRbNu61h4tgByd@lizhi-Precision-Tower-5810>
Date: Thu, 17 Jul 2025 11:06:20 -0400
From: Frank Li <Frank.li@....com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Wei Fang <wei.fang@....com>, Krzysztof Kozlowski <krzk@...nel.org>,
	"robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"richardcochran@...il.com" <richardcochran@...il.com>,
	Claudiu Manoil <claudiu.manoil@....com>,
	Clark Wang <xiaoning.wang@....com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"festevam@...il.com" <festevam@...il.com>,
	"F.S. Peng" <fushi.peng@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: Re: [PATCH v2 net-next 01/14] dt-bindings: ptp: add NETC Timer PTP
 clock

On Thu, Jul 17, 2025 at 03:42:41PM +0300, Vladimir Oltean wrote:
> On Thu, Jul 17, 2025 at 12:55:27PM +0300, Wei Fang wrote:
> > > > "system" is the system clock of the NETC subsystem, we can explicitly specify
> > > > this clock as the PTP reference clock of the Timer in the DT node. Or do not
> > > > add clock properties to the DT node, it implicitly indicates that the reference
> > > > clock of the Timer is the "system" clock.
> > >
> > > It's unusual to name the clock after the source rather than after the
> > > destination. When "clock-names" takes any of the above 3 values, it's
> > > still the same single IP clock, just taken from 3 different sources.
> > >
> > > I see you need to update TMR_CTRL[CK_SEL] depending on where the IP
> > > clock is sourced from. You use the "clock-names" for that. Whereas the
> > > very similar ptp-qoriq uses a separate "fsl,cksel" property. Was that
> > > not an acceptable solution, do we need a new way of achieving the same
> > > thing?
> >
> > This an option, as I also mentioned in v1, either we have to parse the
> > clock-names or we need to add a new property.
>
> I think a new property like "fsl,cksel" is preferable, due to the
> arguments above: already used for ptp_qoriq, and the alternative of
> parsing the clock-names implies going against the established convention
> that the clock name should be from the perspective of this IP, not from
> the perspective of the provider.

The similar problem already was discussed at
https://lore.kernel.org/imx/20250403103346.3064895-2-ciprianmarian.costea@oss.nxp.com/

Actually there are clock mux inside IP, which have some inputs. Only one
was chosen. Rob prefer use clock-names to distingish which one is used.

discuss thread in https://lore.kernel.org/imx/59261ba0-2086-4520-8429-6e3f08107077@oss.nxp.com/

Frank

>
> > > Also, why are "clocks" and "clock-names" not required properties? The
> > > Linux implementation fails probing if they are absent.
> >
> > The current ptp_netc driver will not fail if they are absent, and it will always
> > use the NETC system clock by default, because the system clock of NETC is
> > always available to the Timer.
>
> Ok, sorry`, I misinterpreted the code.