Re: [RFC Patch net-next v2 3/8] net: dsa: microchip: Initial hardware time stamping support

[Arun.Ramadoss]

Hi Vladimir,

On Thu, 2022-11-24 at 16:14 +0200, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On Thu, Nov 24, 2022 at 10:52:46AM +0000, Arun.Ramadoss@xxxxxxxxxxxxx
>  wrote:
> > Mistake here. It is carried forwarded from Christian Eggers patch.
> 
> Still taken from sja1105_hwtstamp_set(). Anyway, doesn't matter where
> it's taken from, as long as it has a justification for being there.
> 
> > > Why do you need to call hwtstamp_set_state anyway?
> > 
> > In tag_ksz.c, xmit function query this state, to determine whether
> > to
> > allocate the 4 PTP timestamp bytes in the skb_buffer or not. Using
> > this
> > tagger_data set state, ptp enable and disable is communicated
> > between
> > ksz_ptp.c and tag_ksz.c
> 
> Why do you need to query this state in particular, considering that
> the
> skb goes first through the port_txtstamp() dsa_switch_ops function?
> Can't you just check there if TX timestamping is enabled, and leave a
> mark in KSZ_SKB_CB()?
KSZ switches need a additional 4 bytes in tail tag if the PTP is
enabled in hardware. If the PTP is enabled and if we didn't add 4
additional bytes in the tail tag then packets are corrupted.

Tristram explained this in the patch conversation

https://lore.kernel.org/netdev/20201118203013.5077-1-ceggers@xxxxxxx/T/#mb3eba4918bda351a405168e7a2140d29262f4c63

I did the follwing experiment today, 
* Removed the ptp time stamp check in tag_ksz.c. In the ksz_xmit
function, 4 additional bytes are added only if KSZ_SKB_CB->ts_en bit is
set.
* Setup the board, ping two boards. Ping is successful.
* Run the ptpl in the background
* Now if I run the ping, ping is not successful. And also in the ptp4l
log message it shows as bad message received.

We need a mechanism to inform tag_ksz.c to add 4 additional bytes in
tail_tag for all the packets if the ptp is enabled in the hardware.