On 3/13/2023 3:03 AM, Chaoyong He wrote: >> On 3/10/2023 6:25 AM, Chaoyong He wrote: >>> + /** >>> + * Shift and mask nn_link_status so that it is effectively the value >>> + * at offset NFP_NET_CFG_STS_NSP_LINK_RATE. >>> + */ >>> + nn_link_status = (nn_link_status >> >> NFP_NET_CFG_STS_LINK_RATE_SHIFT) & >>> + NFP_NET_CFG_STS_LINK_RATE_MASK; >> >> Thanks for extensive commenting, perhaps this is the source of confusion, I >> can't see how above logic makes effectively the value at offset LINK_RATE. >> >> NFP_NET_CFG_STS_LINK_RATE_SHIFT = 1 >> NFP_NET_CFG_STS_LINK_RATE_MASK = 0xF >> >> NFP_NET_CFG_STS = 0x34 >> NFP_NET_CFG_STS_NSP_LINK_RATE = 0x36 >> >> nfp_net_notify_port_speed() >> uint16_t speed; >> *(0x36) = speed >> >> nfp_net_link_update() >> uint16_t val = *(0x34) >> val = (val >> 1) & 0xF; >> >> >> How come 'speed' and 'val' are same value? >> >> Either there is a mistake or FW is making something in the background, I am >> trying to clarify this in past few comments but not able to yet. > > Yes, here FW does do something in the background. > ---------------------------------------------------------------------------- > > 16 bit write only 16 bit read only > > | x x x x x x x x x x x x y y y y | x x x x x x x x x x x y y y y x | > > ^ > ^ > > 0x36 > 0x34 > ------------------------------------------------------------------------------ > The firmware confirm that whatever write into ‘yyyy’ field of 0x36 can be > read from ‘yyyy’ field of 0x34. >
Thanks, I was looking for this, I am progressing with the patch.
