Messages in this thread Patch in this message | | | From | <> | Subject | Re: [RFC Patch net-next 0/6] net: dsa: microchip: add gPTP support for LAN937x switch | Date | Tue, 18 Oct 2022 13:42:41 +0000 |
| |
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
| |