[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8459511785de2f6d503341ce5f87c6e6064d7b5.camel@microchip.com>
Date: Tue, 18 Oct 2022 13:42:41 +0000
From: <Arun.Ramadoss@...rochip.com>
To: <olteanv@...il.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, 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@...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.
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
Powered by blists - more mailing lists