> On May 6, 2019, at 7:30 AM, Richard Cochran <[email protected]> wrote:
>
> On Fri, May 03, 2019 at 09:14:21PM -0700, Richard Cochran wrote:
>> On Thu, Mar 28, 2019 at 08:32:28PM -0700, Vedang Patel wrote:
>>> +int port_tx_interval_request(struct port *p,
>>> + Integer8 announceInterval,
>>> + Integer8 timeSyncInterval,
>>> + Integer8 linkDelayInterval)
>>> +{
>>> + struct msg_interval_req_tlv *mir;
>>> + struct PortIdentity tpid;
>>> + struct ptp_message *msg;
>>> + struct tlv_extra *extra;
>>> + int err;
>>> +
>>> + if (!port_capable(p)) {
>>> + return 0;
>>> + }
>>> +
>>> + memset(&tpid.clockIdentity, 0, sizeof(tpid.clockIdentity));
>>> + tpid.portNumber = 0xFF;
>>
>> Shouldn't that memset() be to all 0xff ?
>>
>> I'm looking at IEEE 1588 Clause 13.12.1.
>>
>> Or maybe the Automotive Profile says something different?
>
> I see where you got this. In 802.1AS-2011 we have:
>
> 10.5.4.2.1 targetPortIdentity (PortIdentity)
>
> The value is 0xFF.
>
> That is clearly (yet another) case of sloppiness in 802.1AS. Here is
> how the type "PortIdentity" is defined:
>
> 6.3.3.7 PortIdentity
>
> The PortIdentity type identifies a port of a time-aware system.
>
> struct PortIdentity
> {
> ClockIdentity clockIdentity;
> UInteger16 portNumber;
> };
>
> You can not assign the value 0xFF to a structure. That does not make
> any sense. What they really meant was to set all 1s.
>
> I'll fix up the memset() call and apply the series.
>
I agree with this. I was also confused by the wording of this section. Thanks
for fixing it and merging the series.
-Vedang
> Thanks,
> Richard
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
