netdev - Re: [net-next] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN

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: <CAMuHMdXt8z-fD7XQ74nfu=jSL8MT-1tauZk0iRzieyNUB4cyRQ@mail.gmail.com>
Date: Fri, 19 Apr 2024 10:16:01 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Niklas Söderlund <niklas.soderlund+renesas@...natech.se>, 
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	netdev@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Subject: Re: [net-next] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN

Hi Andrew,

On Tue, Apr 16, 2024 at 3:05 PM Andrew Lunn <andrew@...n.ch> wrote:
> > > > + if (!of_property_read_u32(np, "rx-internal-delay-ps", &delay))
> > > > +         if (delay)
> > > > +                 val |= GPOUT_RDM;
> > > > +
> > > > + /* Valid values are 0 and 2000, according to DT bindings */
> > > > + if (!of_property_read_u32(np, "tx-internal-delay-ps", &delay))
> > > > +         if (delay)
> > > > +                 val |= GPOUT_TDM;
> > > > +
> > > > + rtsn_write(priv, GPOUT, val);
> > >
> > > So you seem to be using it as bool?
> >
> > Yes.
> >
> > > That is wrong. It is a number of pico seconds!
> >
> > The issue is that the hardware only supports no delay or a fixed delay
> > that can depend on electric properties of the board.
>
> The general convention is that the MAC does not add delays, it leaves
> it to the PHY. Probably 95% of boards are like this, and many MAC
> drivers don't even add support for configuring their hardware delays,
> it is not needed. Those that do, it is generally for fine tuning the
> delays, being able to add/remove 100s of pico seconds, not the full
> 2us. This hardware cannot do that.
>
> So i suggest you drop all this code, and just hard code the delay to
> 0ps.

IIRC (from users of RAVB, which have similar delay bits), the issue
is that some boards require a larger delay than the maximum delay
supported by the Micrel KSZ9031 PHY (960 ps).  Hence these
boards need to enable the MAC delay.

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