netdev - Re: [RFC Patch net-next 0/6] net: dsa: microchip: add gPTP support for LAN937x switch

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, 18 Oct 2022 13:29:24 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Arun.Ramadoss@...rochip.com
Cc:     andrew@...n.ch, linux-kernel@...r.kernel.org,
        UNGLinuxDriver@...rochip.com, vivien.didelot@...il.com,
        linux@...linux.org.uk, ceggers@...i.de, Tristram.Ha@...rochip.com,
        f.fainelli@...il.com, kuba@...nel.org, edumazet@...gle.com,
        pabeni@...hat.com, richardcochran@...il.com,
        netdev@...r.kernel.org, Woojung.Huh@...rochip.com,
        davem@...emloft.net, b.hutchman@...il.com
Subject: Re: [RFC Patch net-next 0/6] net: dsa: microchip: add gPTP support
 for LAN937x switch

On Tue, Oct 18, 2022 at 06:44:04AM +0000, Arun.Ramadoss@...rochip.com wrote:
> I had developed this patch set to add gPTP support for LAN937x based on
> the Christian eggers patch for KSZ9563. Initially I thought of keeping
> implementation specific to LAN937x through lan937x_ptp.c files. Since
> the register sets are same for LAN937x/KSZ9563, I developed using
> ksz_ptp.c so that in future Christain eggers patch can be merged to it
> to support the 1 step clock support.
> I read the Hardware errata of KSZ95xx on 2 step clock and found that it
> was fixed in LAN937x switches. If this is case, Do I need to move this
> 2 step timestamping specific to LAN937x as LAN937x_ptp.c & not claim
> for ksz9563 or common implementation in ksz_ptp.c & export the
> functionality based on chip-id in get_ts_info dsa hooks.

The high-level visible behavior needs to be that the kernel denies
hardware timestamping from being enabled on the platforms on which it
does not work (this includes platforms on which it is conveniently
"not tested" by Microchip engineers, despite there being published
errata stating it doesn't work). Then, the code organization needs to be
such that if anyone wants to add one step TX timestamping to KSZ9477/KSZ9563
as a workaround later, the code reuse is close to maximal without
further refactoring. And there should be plenty of reuse beyond the TX
timestamping procedure.

I expect that Christian will also be able to find some time to review
this RFC and propose some changes/ask some questions based on his prior
observations, at least so he said privately.