netdev - Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support

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: <1680734.pGj3N1mgWS@n95hx1g2>
Date:   Thu, 22 Oct 2020 12:17:48 +0200
From:   Christian Eggers <ceggers@...i.de>
To:     Richard Cochran <richardcochran@...il.com>
CC:     Vladimir Oltean <olteanv@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Helmut Grohne <helmut.grohne@...enta.de>,
        Paul Barker <pbarker@...sulko.com>,
        Codrin Ciubotariu <codrin.ciubotariu@...rochip.com>,
        George McCollister <george.mccollister@...il.com>,
        Marek Vasut <marex@...x.de>,
        Tristram Ha <Tristram.Ha@...rochip.com>,
        "David S . Miller" <davem@...emloft.net>,
        Woojung Huh <woojung.huh@...rochip.com>,
        "Microchip Linux Driver Support" <UNGLinuxDriver@...rochip.com>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support

On Thursday, 22 October 2020, 09:30:57 CEST, Christian Eggers wrote:
> On Thursday, 22 October 2020, 04:42:01 CEST, Richard Cochran wrote:
> > On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote:
> > > On Mon, Oct 19, 2020 at 07:24:33PM +0200, Christian Eggers wrote:
> > > > The PTP hardware performs internal detection of PTP frames (likely
> > > > similar as ptp_classify_raw() and ptp_parse_header()). As these
> > > > filters
> > > > cannot be disabled, the current delay mode (E2E/P2P) and the clock
> > > > mode
> > > > (master/slave) must be configured via sysfs attributes.
> > 
> > This is a complete no-go.  NAK.
> 
> I didn't design the hardware nor do I have access to adequate documentation.
> I will try to figure out what functionality is concretely affected by these
> two settings.
I tried to study the effect of setting the ocmode bit on the KSZ either to
master or to slave. The main visible change is, that some PTP message types
are be filtered out on RX:
- in "master" mode, "Sync" messages from other nodes will not be received
(but everything else like "Announce" seem to work)
- in "slave" mode, "Delay_Req" messages from other nodes will not be received

I am not an expert for PTP, so the following is only the idea of a beginner how
this could probably be handled:

As PTP announce messages are received all the time, the BMCA should always
be able to work. The KSZ hardware needs to be set to "master" when a node
is becoming master (in order to be able to receive (and answer) Delay_Req
messages). The setting "slave" is equired when the BCMA decides not being
master anymore (in order to receive Sync messages).

Handling the transition to "master" mode could probably be done easily in the 
driver (when a Sync message is seen in TX direction by the time stamping code).
But transition to slave seems to be difficult, because the tagging driver cannot
see when the node stops being master. For user space (ptp4l), the decision for
master/slave mode could probably be done easier.

If Richard (or somebody else) decides that "mode switching" of the KSZ device
would not be appropriate, I suspect the functionality of the KSZ has to be
limited to "Slave Only Clock".

regards
Christian