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

[<Arun.Ramadoss@microchip.com>]

On Tue, 2022-10-18 at 13:29 +0300, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> 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.

Thanks Vladimir. I will wait for Christian feedback.

Hi Christian,
To test this patch on KSZ9563, we need to increase the number of
interrupts port_nirqs in KSZ9893 from 2 to 3. Since the chip id of
KSZ9893 and KSZ9563 are same, I had reused the ksz_chip_data same for
both chips. But this chip differ with number of port interrupts. So we
need to update it. We are generating a new patch for adding the new
element in the ksz_chip_data for KSZ9563.
For now, you can update the code as below for testing the patch

-- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -1266,7 +1266,7 @@ const struct ksz_chip_data ksz_switch_chips[] =
{         
                 .num_statics = 16,
                 .cpu_ports = 0x07,      /* can be configured as cpu
port */
                 .port_cnt = 3,          /* total port count */
 -               .port_nirqs = 2,
 +               .port_nirqs = 3,
                 .ops = &ksz9477_dev_ops,
                 .mib_names = ksz9477_mib_names,
                 .mib_cnt = ARRAY_SIZE(ksz9477_mib_names),

--
Arun