On Wed, 21 Jun 2023 at 01:13, Rahul Rameshbabu <rrameshb...@nvidia.com> wrote:
> Hi Erez, > > On Wed, 21 Jun, 2023 00:33:28 +0200 Erez <erezge...@gmail.com> wrote: > > Hi, > > > > You already submitted the patch seria. > > Has it changed? > > Yes, I took feedback from the RFC (request for comments) I sent out and > applied it in this submission. In the git notes field in the first patch > of the series, I document the change made since the RFC. Since the first > submission was an RFC, I did not treat it as a formal submission, so I > did not consider it a v1 but rather a draft. I submitted as an RFC due > to pending kernel side changes. > > > If so, please mark it with version 2. "git format-patch -v 2". > > I agree with this if a formal v1 was submitted. However since my > previous submission was an RFC, is the practice still to increment the > official submission as v2? > Rahul, all patches are for review. Do not make our life too much sophisticated. Just add a version tag, please. Whether you add an RFC or not. If you really must , you can add a note in the cover letter for Richard. Linux works with several groups. Linuxptp has only one developer group, it is not that big :-) Thanks Erez > > > If not, why do you send it again? > > Ignoring the fact that I applied changes based on feedback from the RFC > submission, isn't the normal practice to submit an RFC as a normal > submission to the mailing list to indicate readiness for applying the > patches onto the target? > > > I think Richard wanted to close version 4 first. > > Sure, that makes sense. I am hoping RFC patches are not considered for > merging into releases or the default branch of the project. At the time, > the needed kernel side changes were not merged into net-next of the > linux netdev tree. > > Apologize in advance if we are implementing the practice of closing > submissions during release windows (similar to what net-next does in the > linux netdev tree). I did not see a mention of that on the mailing list. > Might have missed it. > > Thanks, > > Rahul Rameshbabu > > > > > Erez > > > > On Tue, 20 Jun 2023 at 19:39, Rahul Rameshbabu via Linuxptp-devel < > linuxptp-devel@lists.sourceforge.net> wrote: > > > > The main focus of this submission is adding support for testing > ADJ_OFFSET with > > phc_ctl and querying the maximum supported ADJ_OFFSET adjustment that a > device > > is capable of. Some other minor cleanups are also included in the > submission. > > > > That patch the introduces support for querying the maximum offset > supported by > > ADJ_OFFSET depends on a kernel patch series (linked below) that is > targeted for > > kernel 6.5. Previously, sent this series out as an RFC to inquire > feedback early > > on. Have incorporated that feedback into this submission. > > > > Link: https://sourceforge.net/p/linuxptp/mailman/message/37854603/ > > Link: > https://lore.kernel.org/netdev/20230612211500.309075-1-rrameshb...@nvidia.com/ > > > > Rahul Rameshbabu (5): > > Rename NSEC2SEC as NSEC_PER_SEC and refactor to util.h > > phc_ctl: Add phase command to support ADJ_OFFSET > > phc_ctl: Add maximum offset capability > > phc_ctl: Use pr_notice instead of pr_err for displaying adjusted > > frequency > > phc_ctl: Handle errors returned by various clockadj helpers > > > > missing.h | 9 +++--- > > phc_ctl.8 | 4 +++ > > phc_ctl.c | 77 ++++++++++++++++++++++++++++++++++++++------------ > > port.c | 14 ++++----- > > port_private.h | 3 +- > > servo.c | 3 +- > > tc.c | 6 ++-- > > util.h | 2 ++ > > 8 files changed, 82 insertions(+), 36 deletions(-) > > > > -- > > 2.40.1 > > > > _______________________________________________ > > Linuxptp-devel mailing list > > Linuxptp-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
