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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Nov 2023 17:32:10 +0100
From: Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	devicetree@...r.kernel.org, netdev@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: net: renesas,ethertsn: Add bindings for
 Ethernet TSN

Hi Geert,

On 2023-11-21 17:11:52 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Tue, Nov 21, 2023 at 1:44 PM Niklas Söderlund
> <niklas.soderlund+renesas@...natech.se> wrote:
> > On 2023-11-21 13:20:54 +0100, Krzysztof Kozlowski wrote:
> > > On 21/11/2023 13:10, Niklas Söderlund wrote:
> > > >>> +
> > > >>> +  renesas,rx-internal-delay:
> > > >>> +    type: boolean
> > > >>> +    description:
> > > >>> +      Enable internal Rx clock delay, typically 1.8ns.
> > > >>
> > > >> Why this is bool, not delay in ns?
> > > >
> > > > The TSN is only capable of enabling or disable internal delays, not set
> > > > how long the delay is. The documentation states that the delay depends
> > > > on the electronic characteristics of the particular board, but states
> > > > that they typically are 1.8ns for Rx and 2.0ns for Tx.
> > >
> > > I don't understand that part. If you cannot configure the internal
> > > delay, how could it depend on the board characteristics?
> >
> > Each of these two properties reflect a single bit in the device
> > configuration space. If the bit is set the {Rx,Tx} delay mode is active
> > or disabled. The documentation for the bit simply states,
> >
> >     Tx clock internal Delay Mode
> >
> >     This bit can add internal Tx clock delay typ 2.0ns*.
> >
> >     *Refer to Electrical Characteristics for details.
> >
> > Same paragraph for Rx but a typical 1.8ns delay.
> >
> > > > I looked at the generic properties {rx,tx}-internal-delay-ps but they
> > > > are of int type. So I opted for a vendor specific bool property. Do you
> > > > think a better route is to use the generic property and force the value
> > > > to be either 0 or the typical delay?
> 
> This is not dissimilar from EtherAVB, where the hardware also supports
> only a single bit, and whose DT bindings have:
> 
>   rx-internal-delay-ps:
>     enum: [0, 1800]
> 
>   tx-internal-delay-ps:
>     enum: [0, 2000]
> 
> (with additional restrictions depending on the SoC, as on some SoCs
>  the bits cannot be changed).

That is a good point, I will switch to use the standard bindings for 
delay in v2.

> 
> > > >> Why this is property of a board (not SoC)?
> > > >
> > > > I'm sorry I don't understand this question.
> > >
> > > Why setting internal delay is specific to a board, not to a SoC? Why
> > > each board would need to configure it? On which parts of hardware on the
> > > board does this depend?
> >
> > Ahh, I think I understand. It is per board as I understand the
> > documentation. It depends on the electrical characteristics of the
> > board.
> 
> Exactly. These bits (and also similar bits in the PHY) are used to
> adapt signaling to the board trace lengths between MAC (on-SoC) and PHY.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

-- 
Kind Regards,
Niklas Söderlund

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ