[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF2d9jgRwSF426u9jgYZeVd5+Cd3B21m-bT_FcSzW83riJvhhw@mail.gmail.com>
Date: Thu, 5 Oct 2023 16:09:50 -0700
From: Mahesh Bandewar (महेश बंडेवार)
<maheshb@...gle.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: Netdev <netdev@...r.kernel.org>,
Linux <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Jonathan Corbet <corbet@....net>,
John Stultz <jstultz@...gle.com>,
Don Hatchett <hatch@...gle.com>,
Yuliang Li <yuliangli@...gle.com>,
Mahesh Bandewar <mahesh@...dewar.net>,
Rahul Rameshbabu <rrameshbabu@...dia.com>
Subject: Re: [PATCHv2 next 2/3] ptp: add ioctl interface for ptp_gettimex64any()
On Tue, Oct 3, 2023 at 9:30 PM Richard Cochran <richardcochran@...il.com> wrote:
>
> On Mon, Oct 02, 2023 at 09:17:04PM -0700, Mahesh Bandewar wrote:
> > add an ioctl op PTP_SYS_OFFSET_ANY2 to support ptp_gettimex64any() method
>
> NAK.
>
Could you elaborate?
> > + case PTP_SYS_OFFSET_ANY2:
>
> 2?
>
> What happended to 1?
My reading from the commit 415606588c61 ("PTP: introduce new versions
of IOCTLs") is that we have an issue with the version 1 and hence we
added ver 2 of the existing ops. Since it's a new implementation, I
can skip the old part and just implement ver 2.
However, I can do something like
#define PTP_SYS_OFFSET_ANY PTP_OFFSET_ANY2
is that something inline with the mix of ver 1 and ver 2 expectation?
Powered by blists - more mailing lists