linux-kernel - RE: [PATCH net-next 01/12] dt-bindings: ptp: add bindings for NETC Timer

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] [day] [month] [year] [list]

Message-ID:
 <PAXPR04MB8510633DE93F043A0CD09F5B8857A@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Tue, 15 Jul 2025 07:11:39 +0000
From: Wei Fang <wei.fang@....com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: Krzysztof Kozlowski <krzk@...nel.org>, "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>, "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>
Subject: RE: [PATCH net-next 01/12] dt-bindings: ptp: add bindings for NETC
 Timer

> On Tue, Jul 15, 2025 at 05:52:33AM +0300, Wei Fang wrote:
> > > You seem to imply that the "nxp,pps-channel" property affects the
> > > function of the SoC pads, which may be connected to the NETC 1588 timer
> > > block or to some other IP. Nothing in the code I saw suggested this
> > > would be the case, and I still don't see how this is the case - but
> > > anyway, my bad.
> > >
> > > In this case, echoing Krzysztof's comments: How come it isn't the system
> > > pinmux driver the one concerned with connecting the SoC pads to the NETC
> > > 1588 timer or to FlexIO, CAN etc? The pinmux driver controls the pads,
> > > the NETC timer controls its block's pins, regardless of how they are
> > > routed further.
> >
> > pinmux can select which device to use this pin for, but this is the
> > configuration inside SoC. For the outside, depending on the design
> > of the board, for example, pin0 is connected to a CAN-related device,
> > then in fact this pin can only be used by CAN.
> 
> Ok, but I fail to see the relevance here? Do you just mean to say 'there
> are multiple FIPER outputs from the 1588 timer block, and they may not
> all be pinmuxed to SoC pads, so I intended "nxp,pps-channel" as a way
> for the device tree writer to select one of the FIPER outputs which is
> multiplexed to an SoC pad, rather than arbitrarily choosing one of the
> FIPER channels in the driver'? If so, I believe the case is settled and
> this property will disappear in v2.

Yeah, now I'm clear that PTP_CLK_REQ_PPS is not used to output PPS
to external pins, so this property will be dropped.