From: Andrew Lunn <andrew@lunn.ch>
To: Vincent Cheng <vincent.cheng.xh@renesas.com>
Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"richardcochran@gmail.com" <richardcochran@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] ptp: Add a ptp clock driver for IDT ClockMatrix.
Date: Fri, 27 Sep 2019 16:56:32 +0200 [thread overview]
Message-ID: <20190927145632.GI20927@lunn.ch> (raw)
In-Reply-To: <20190927141215.GA24424@renesas.com>
> >> +static void set_default_function_pointers(struct idtcm *idtcm)
> >> +{
> >> + idtcm->_idtcm_gettime = _idtcm_gettime;
> >> + idtcm->_idtcm_settime = _idtcm_settime;
> >> + idtcm->_idtcm_rdwr = idtcm_rdwr;
> >> + idtcm->_sync_pll_output = sync_pll_output;
> >> +}
> >
> >Why does this indirection? Are the SPI versions of the silicon?
>
> The indirection is to enable us to replace those functions in
> our unit tests with mocked functions.
Due to Spectra/meltdown etc, indirection is now expensive. But i guess
the I2C operations are a lot more expensive.
But in general, we try to keep the code KISS. Have you tried other
ways of doing this. Have your unit test framework implement
i2c_transfer()?
> I read somewhere that I should leave a week between sending a
> revised patch series. Is this a good rule to follow?
There are different 'timers'. One is how long to wait for review
comments, and reposting when you don't receiver any comments. netdev
for example is fast, a couple of days. Other subsystems, you need to
wait two weeks. Another 'timer' is how often to post new versions. In
general, never more than once per day. And the slower the subsystem is
for making reviews, the longer you should wait for additional review
comments.
What also plays a role is that the merge window is currently open. So
most subsystems won't accept patches at the moment. You need to wait
until it closes before submitting patches you expect to be good enough
to be accepted.
Andrew
prev parent reply other threads:[~2019-09-27 14:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 3:48 [PATCH v2 1/2] dt-bindings: ptp: Add bindings doc for IDT ClockMatrix based PTP clock vincent.cheng.xh
2019-09-27 3:48 ` [PATCH v2 2/2] ptp: Add a ptp clock driver for IDT ClockMatrix vincent.cheng.xh
2019-09-27 12:25 ` Andrew Lunn
2019-09-27 14:12 ` Vincent Cheng
2019-09-27 14:56 ` Andrew Lunn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190927145632.GI20927@lunn.ch \
--to=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=robh+dt@kernel.org \
--cc=vincent.cheng.xh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).