lkml.org 
[lkml]   [2022]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: [RFC Patch net-next 0/6] net: dsa: microchip: add gPTP support for LAN937x switch
Date
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
\
 
 \ /
  Last update: 2022-10-18 15:43    [W:0.149 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site