[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200724160335.GA30531@hoboy>
Date: Fri, 24 Jul 2020 09:03:35 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Kurt Kanzenbach <kurt@...utronix.de>
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH v1 0/2] ptp: Add generic header parsing function
On Fri, Jul 24, 2020 at 08:25:59AM +0200, Kurt Kanzenbach wrote:
> These three drivers also deal with ptp v1 and they need access to the
> message type. However, the message type is located at a different offset
> depending on the ptp version. They all do:
>
> |if (unlikely(ptp_class & PTP_CLASS_V1))
> | msgtype = data + offset + OFF_PTP_CONTROL;
> |else
> | msgtype = data + offset;
>
> Maybe we can put that in a helper function, too?
Yes, please.
> |static inline u8 ptp_get_msgtype(const struct ptp_header *hdr, unsigned int type)
> |{
> | u8 msg;
> |
> | if (unlikely(type & PTP_CLASS_V1))
> | /* msg type is located @ offset 20 for ptp v1 */
> | msg = hdr->source_port_identity.clock_identity.id[0];
> | else
> | msg = hdr->tsmt & 0x0f;
> |
> | return msg;
> |}
>
> What do you think about it?
Looks good.
I can also test the dp83640. Maybe you could test the cpts on a bbb?
Thanks,
Richard
Powered by blists - more mailing lists