Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 18 Oct 2022 13:29:24 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Arun.Ramadoss@microchip.com
Cc:     andrew@lunn.ch, linux-kernel@vger.kernel.org,
        UNGLinuxDriver@microchip.com, vivien.didelot@gmail.com,
        linux@armlinux.org.uk, ceggers@arri.de, Tristram.Ha@microchip.com,
        f.fainelli@gmail.com, kuba@kernel.org, edumazet@google.com,
        pabeni@redhat.com, richardcochran@gmail.com,
        netdev@vger.kernel.org, Woojung.Huh@microchip.com,
        davem@davemloft.net, b.hutchman@gmail.com
Subject: Re: [RFC Patch net-next 0/6] net: dsa: microchip: add gPTP support
 for LAN937x switch
Message-ID: <20221018102924.g2houe3fz6wxlril@skbuf>
References: <20221014152857.32645-1-arun.ramadoss@microchip.com>
 <20221017171916.oszpyxfnblezee6u@skbuf>
 <77959874a88756045ae13e0efede5e697be44a7b.camel@microchip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <77959874a88756045ae13e0efede5e697be44a7b.camel@microchip.com>
Precedence: bulk

On Tue, Oct 18, 2022 at 06:44:04AM +0000, Arun.Ramadoss@microchip.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.