On Fri, Oct 12, 2018 at 03:42:57PM -0500, Rob Herring wrote:
> On Sun, Oct 07, 2018 at 10:38:23AM -0700, Richard Cochran wrote:
> > +
> > +Required properties of the control node:
> > +
> > +- compatible: "ines,ptp-ctrl"
>
> ines is not r
The 1588 standard defines one step operation for both Sync and
PDelay_Resp messages. Up until now, hardware with P2P one step has
been rare, and kernel support was lacking. This patch adds support of
the mode in anticipation of new hardware developments.
Signed-off-by: Richard Cochran
The InES at the ZHAW offers a PTP time stamping IP core. The FPGA
logic recognizes and time stamps PTP frames on the MII bus. This
patch adds a driver for the core along with a device tree binding to
allow hooking the driver to MII buses.
Signed-off-by: Richard Cochran
---
drivers/ptp/Kconfig
,
Richard
Changed in v3:
~~
- Simplify the device tree binding and document the time stamping
phandle by itself.
Changed in v2:
~~
- Per the v1 review, changed the modeling of MII time stamping
devices. They are no longer a kind of mdio device.
Richard Cochran (6
. The controller device will be associated
with one or more time stamping channels, each of which snoops on a MII
bus.
This patch provides a glue layer that will enable time stamping
channels to find their controlling device.
Signed-off-by: Richard Cochran
---
drivers/net/phy/Makefile
This patch add a new binding that allows non-PHY MII time stamping
devices to find their buses. The new documentation covers both the
generic binding and one upcoming user.
Signed-off-by: Richard Cochran
---
Documentation/devicetree/bindings/ptp/ptp-ines.txt | 35
only user of the old PHY time stamping API is
converted to the new interface.
Signed-off-by: Richard Cochran
---
drivers/net/phy/dp83640.c | 47 +
drivers/net/phy/phy.c | 4 ++--
drivers/net/phy/phy_device.c| 2 ++
include/linux
When parsing a PHY node, register its time stamper, if any, and attach
the instance to the PHY device.
Signed-off-by: Richard Cochran
---
drivers/net/phy/phy_device.c | 3 +++
drivers/of/of_mdio.c | 24
2 files changed, 27 insertions(+)
diff --git a/drivers
On Wed, May 22, 2019 at 02:58:23AM +0200, Andrew Lunn wrote:
> > -static int dp83640_hwtstamp(struct phy_device *phydev, struct ifreq *ifr)
> > +static int dp83640_hwtstamp(struct mii_timestamper *mii_ts, struct ifreq
> > *ifr)
> > {
> > - struct dp83640_private *dp83640 = phydev->priv;
> > +
On Wed, May 22, 2019 at 03:08:52AM +0200, Andrew Lunn wrote:
> probe_channel returns an PTR_ERR. So if (mii_ts) should probably be
> if (IS_ERR(mii_ts))
Nice catch. Thanks for the careful review!
Richard
On Wed, May 22, 2019 at 03:22:27AM +0200, Andrew Lunn wrote:
> Shouldn't unregister_mii_timestamper() be called on error?
Yes.
Thanks,
Richard
On Wed, May 22, 2019 at 03:42:20AM +0200, Andrew Lunn wrote:
> I don't know about the PTP subsystem, but in general, forward
> declarations are frowned upon, and it is generally requested to
> reorder the functions to remove them.
I am not aware of any general coding style rule or even defacto
pra
. The controller device will be associated
with one or more time stamping channels, each of which sits snoops in
on a MII bus.
This patch provides a glue layer that will enable time stamping
channels to find their controlling device.
Signed-off-by: Richard Cochran
---
drivers/net/phy/Makefile
only user of the old PHY time stamping API is
converted to the new interface.
Signed-off-by: Richard Cochran
---
drivers/net/phy/dp83640.c | 47 +++---
drivers/net/phy/phy.c | 4 +--
drivers/net/phy/phy_device.c| 2 ++
include/linux
le by itself.
Changed in v2:
~~
- Per the v1 review, changed the modeling of MII time stamping
devices. They are no longer a kind of mdio device.
Richard Cochran (6):
net: Introduce peer to peer one step PTP time stamping.
net: Introduce a new MII time stamping interface.
net:
The 1588 standard defines one step operation for both Sync and
PDelay_Resp messages. Up until now, hardware with P2P one step has
been rare, and kernel support was lacking. This patch adds support of
the mode in anticipation of new hardware developments.
Signed-off-by: Richard Cochran
The InES at the ZHAW offers a PTP time stamping IP core. The FPGA
logic recognizes and time stamps PTP frames on the MII bus. This
patch adds a driver for the core along with a device tree binding to
allow hooking the driver to MII buses.
Signed-off-by: Richard Cochran
---
drivers/ptp/Kconfig
When parsing a PHY node, register its time stamper, if any, and attach
the instance to the PHY device.
Signed-off-by: Richard Cochran
---
drivers/net/phy/phy_device.c | 3 +++
drivers/of/of_mdio.c | 30 +-
2 files changed, 32 insertions(+), 1 deletion
This patch add a new binding that allows non-PHY MII time stamping
devices to find their buses. The new documentation covers both the
generic binding and one upcoming user.
Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
---
Documentation/devicetree/bindings/ptp/ptp-ines.txt | 35
On Thu, May 30, 2019 at 12:58:33PM -0700, David Miller wrote:
> I had to revert, this doesn't build.
Sorry I missed macvlan, and thanks for the 'uninitialized' warning.
It was a real latent bug. I wonder why my linaro 7.4 gcc didn't flag
that...
Anyhow, I rebased v5 of my series to latest net-ne
eview tag.
Changed in v3:
~~
- Simplify the device tree binding and document the time stamping
phandle by itself.
Changed in v2:
~~
- Per the v1 review, changed the modeling of MII time stamping
devices. They are no longer a kind of mdio device.
Richard Cochr
When parsing a PHY node, register its time stamper, if any, and attach
the instance to the PHY device.
Signed-off-by: Richard Cochran
---
drivers/net/phy/phy_device.c | 3 +++
drivers/of/of_mdio.c | 30 +-
2 files changed, 32 insertions(+), 1 deletion
The 1588 standard defines one step operation for both Sync and
PDelay_Resp messages. Up until now, hardware with P2P one step has
been rare, and kernel support was lacking. This patch adds support of
the mode in anticipation of new hardware developments.
Signed-off-by: Richard Cochran
. The controller device will be associated
with one or more time stamping channels, each of which sits snoops in
on a MII bus.
This patch provides a glue layer that will enable time stamping
channels to find their controlling device.
Signed-off-by: Richard Cochran
---
drivers/net/phy/Makefile
only user of the old PHY time stamping API is
converted to the new interface.
Signed-off-by: Richard Cochran
---
drivers/net/macvlan.c | 4 +--
drivers/net/phy/dp83640.c | 47 +++---
drivers/net/phy/phy.c | 4 +--
drivers/net/phy/phy_device.c
This patch add a new binding that allows non-PHY MII time stamping
devices to find their buses. The new documentation covers both the
generic binding and one upcoming user.
Signed-off-by: Richard Cochran
Reviewed-by: Andrew Lunn
---
Documentation/devicetree/bindings/ptp/ptp-ines.txt | 35
The InES at the ZHAW offers a PTP time stamping IP core. The FPGA
logic recognizes and time stamps PTP frames on the MII bus. This
patch adds a driver for the core along with a device tree binding to
allow hooking the driver to MII buses.
Signed-off-by: Richard Cochran
---
drivers/ptp/Kconfig
On Fri, May 31, 2019 at 05:13:09PM -0700, David Miller wrote:
> This also does not build.
>
> Please do an allmodconfig build and save me from having to do this
> another time.
(Dons paper bag over head.)
I have a good excuse... it was the bay area fog that made me do it!
Sorry,
Richard
On Mon, Jun 03, 2019 at 03:12:39PM +0300, Ido Schimmel wrote:
> From: Shalom Toledo
>
> The MTUTC register configures the HW UTC counter.
Why is this called the "UTC" counter?
The PTP time scale is TAI. Is this counter intended to reflect the
Linux CLOCK_REALTIME system time?
> +/* MTUTC - Ma
On Mon, Jun 03, 2019 at 03:12:41PM +0300, Ido Schimmel wrote:
> From: Shalom Toledo
>
> Publish scaled_ppm_to_ppb to allow drivers to use it.
But why?
> @@ -63,7 +63,7 @@ static void enqueue_external_timestamp(struct
> timestamp_event_queue *queue,
> spin_unlock_irqrestore(&queue->lock,
On Mon, Jun 03, 2019 at 03:12:42PM +0300, Ido Schimmel wrote:
> +static int
> +mlxsw_sp1_ptp_update_phc_settime(struct mlxsw_sp_ptp_clock *clock, u64 nsec)
Six words ^^^
What is wrong with "mlxsw_phc_settime" ?
> +{
> + struct mlxsw_core *mlxsw_core = clock->core;
> + char mtutc_pl[MLXS
On Mon, Jun 03, 2019 at 03:12:42PM +0300, Ido Schimmel wrote:
> +struct mlxsw_sp_ptp_clock *
> +mlxsw_sp1_ptp_clock_init(struct mlxsw_sp *mlxsw_sp, struct device *dev)
> +{
> + u64 overflow_cycles, nsec, frac = 0;
> + struct mlxsw_sp_ptp_clock *clock;
> + int err;
> +
> + clock = kz
est
> * "adjtime" test
> * "adjfreq" test
This looks useful!
Acked-by: Richard Cochran
On Wed, Jun 05, 2019 at 11:30:06AM +, Shalom Toledo wrote:
> On 04/06/2019 17:17, Richard Cochran wrote:
> > On Mon, Jun 03, 2019 at 03:12:39PM +0300, Ido Schimmel wrote:
> >> From: Shalom Toledo
> >>
> >> The MTUTC register configures the HW UTC counter.
On Wed, Jun 05, 2019 at 08:30:21AM +0200, Jiri Pirko wrote:
> Tue, Jun 04, 2019 at 04:28:19PM CEST, richardcoch...@gmail.com wrote:
> >On Mon, Jun 03, 2019 at 03:12:42PM +0300, Ido Schimmel wrote:
> >
> >> +static int
> >> +mlxsw_sp1_ptp_update_phc_settime(struct mlxsw_sp_ptp_clock *clock, u64
> >
On Wed, Jun 05, 2019 at 09:00:09AM +, Petr Machata wrote:
> We don't build the PTP module at all unless CONFIG_PTP_1588_CLOCK is
> enabled, and fall back to inline stubs unless it IS_REACHABLE. I believe
> this should be OK.
Please use "imply PTP_1588_CLOCK" in your kconfig, just like the othe
On Wed, Jun 05, 2019 at 11:44:21AM +, Shalom Toledo wrote:
> On 04/06/2019 17:28, Richard Cochran wrote:
> > Now I see why you did this. Nice try.
>
> I didn't try anything.
>
> The reason is that the hardware units is in ppb and not in scaled_ppm(or ppm),
>
On Wed, Jun 05, 2019 at 06:55:18PM +, Shalom Toledo wrote:
> On 05/06/2019 20:23, Richard Cochran wrote:
> > On Wed, Jun 05, 2019 at 11:30:06AM +, Shalom Toledo wrote:
> >> On 04/06/2019 17:17, Richard Cochran wrote:
> >>> On Mon, Jun 03, 2019 at 03:12:
On Wed, Jun 05, 2019 at 07:28:38PM +, Shalom Toledo wrote:
> So, there is an HW machine which responsible for adding UTC timestamp on
> R-SPAN mirror packets and there is no connection to the HW free running
> counter.
If there is no connection, then the frequency adjustments to the HW
clock w
On Wed, Jun 05, 2019 at 01:23:49PM -0700, Jeff Kirsher wrote:
> + * It calculates when the system time will be on an exact second, and then
> + * aligns the start of the PPS signal to that value.
> + *
> + * This works by using the cycle counter shift and mult values in reverse,
> and
> + * assume
On Thu, Jun 06, 2019 at 08:37:59PM +, Keller, Jacob E wrote:
> No. We use the timecounter to track the time offset, not the
> frequency. That is, our hardware can't represent 64bits of time, but
> it can adjust frequency. The time counter is used to track the
> adjustments from adjtime and set
On Wed, Jul 24, 2019 at 10:17:15AM +0200, Antoine Tenart wrote:
> This patch adds support for PTP Hardware Clock (PHC) to the Ocelot
> switch for both PTP 1-step and 2-step modes.
>
> Signed-off-by: Antoine Tenart
Acked-by: Richard Cochran
On Sun, Jan 10, 2021 at 11:13:44AM +, Russell King wrote:
> This allows network drivers such as mvpp2 to use their more accurate
> timestamping implementation than using a less accurate implementation
> in the PHY. Network drivers can opt to defer to phylib by returning
> -EOPNOTSUPP.
My expec
On Thu, Jan 14, 2021 at 01:32:35PM +, Russell King - ARM Linux admin wrote:
> > We had already discussed this patch last year, and you agreed with it
> > then. What has changed?
>
> See the discussion in this sub-thread:
>
> https://lore.kernel.org/netdev/20200729105807.gz1...@shell.armlinux.
d-by: Tariq Toukan
Acked-by: Richard Cochran
The mv88e6xxx is a DSA driver, and it implements DSA style time
stamping of PTP frames. It has no need of the expensive option to
enable PHY time stamping. Remove the bogus dependency.
Signed-off-by: Richard Cochran
Fixes: 2fa8d3af4bad ("net: dsa: mv88e6xxx: expose switch time as
specialized embedded systems.
Unfortunately two unrelated drivers depend on this option, and two
defconfigs enable it. It is probably my fault for not paying enough
attention in reviews.
This series corrects the gratuitous use of NETWORK_PHY_TIMESTAMPING.
Richard Cochran (4):
net: dsa
on Chip, least ways not the socfpga SoC, includes
such a PHY time stamping device. Disable the unneeded option by
default.
The diff includes a bit of extra churn caused by "make savedefconfig",
but the generated defconfig is now in the canonical form.
Signed-off-by: Richard Cochran
---
The mvpp2 is an Ethernet driver, and it implements MAC style time
stamping of PTP frames. It has no need of the expensive option to
enable PHY time stamping. Remove the incorrect dependency.
Signed-off-by: Richard Cochran
Fixes: 91dd71950bd7 ("net: mvpp2: ptp: add TAI support")
--
on Chip, least ways not the axm55xx SoC, includes
such a PHY time stamping device. Disable the unneeded option by
default.
Signed-off-by: Richard Cochran
---
arch/arm/configs/axm55xx_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/axm55xx_defconfig
b/arch/arm
On Thu, Jan 14, 2021 at 10:38:00PM +, Russell King - ARM Linux admin wrote:
> So, I think the only way to prevent a regression with the code as
> it is today is that we _never_ support PTP on Marvell PHYs - because
> doing so _will_ break the existing MVPP2 driver's implementation and
> cause
On Thu, Jan 21, 2021 at 10:27:38AM +, Russell King - ARM Linux admin wrote:
> As I already explained to you, you can *NOT* use kernel configuration
> to make the choice. ARM is a multi-platform kernel, and we will not
> stand for platform choices dictated by kernel configuration options.
This
On Thu, Jan 21, 2021 at 10:27:54AM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 20, 2021 at 08:06:01PM -0800, Richard Cochran wrote:
> > The mvpp2 is an Ethernet driver, and it implements MAC style time
> > stamping of PTP frames. It has no need of the expensive optio
On Wed, Jan 20, 2021 at 08:05:59PM -0800, Richard Cochran wrote:
> The NETWORK_PHY_TIMESTAMPING configuration option adds additional
> checks into the networking hot path, and it is only needed by two
> rather esoteric devices,
Correction: there are three legitimate users of PHY time
On Thu, Jan 21, 2021 at 05:22:37PM +0100, Andrew Lunn wrote:
> There is a growing interesting in PTP, the number of drivers keeps
> going up. The likelihood of MAC/PHY combination having two
> timestamping sources is growing all the time. So the stack needs to
> change to support the selection of
On Wed, Dec 16, 2020 at 05:13:34PM -0800, Jakub Kicinski wrote:
> On Wed, 16 Dec 2020 12:32:38 +0100 Holger Assmann wrote:
> > As it is, valid SIOCSHWTSTAMP ioctl calls - i.e. enable/disable time
> > stamping or changing filter settings - lead to synchronization of the
> > NIC's hardware clock with
On Thu, Dec 17, 2020 at 06:11:50PM +0530, Divya Koppera wrote:
> +struct lan8814_ptphdr {
> + u8 tsmt; /* transportSpecific | messageType */
> + u8 ver; /* reserved0 | versionPTP */
> + __be16 msglen;
> + u8 domain;
> + u8 rsrvd1;
> + __be16 flags;
> + __be64 correctio
On Mon, Nov 30, 2020 at 09:01:25PM +, tristram...@microchip.com wrote:
> The 1588 PTP engine in the KSZ switches was designed to be controlled closely
> by
> a PTP stack, so it is a little difficult to use when there is a layer of
> kernel support
> between the application and the driver.
Ar
On Thu, Dec 03, 2020 at 11:21:17AM +0100, Christian Eggers wrote:
> The KSZ9563 has a Trigger Output Unit (TOU) which can be used to
> generate periodic signals.
>
> The pulse length can be altered via a device attribute.
Device tree is the wrong place for that.
Aren't you using PTP_PEROUT_DUTY_
On Thu, Dec 03, 2020 at 04:36:26PM +0100, Christian Eggers wrote:
> Should ptp_sysfs be extended with a "pulse" attribute with calls
> enable() with only PTP_PEROUT_DUTY_CYCLE set?
Yes, that would make sense. It would bring sysfs back to feature
parity with the ioctls.
Thanks,
Richard
On Thu, Dec 03, 2020 at 10:29:25AM -0800, Jonathan Lemon wrote:
> The OpenCompute time card is an atomic clock along with
> a GPS receiver that provides a Grandmaster clock source
> for a PTP enabled network.
>
> More information is available at http://www.timingcard.com/
>
> Signed-off-by: Jonat
On Fri, Dec 04, 2020 at 03:00:50AM +0200, Vladimir Oltean wrote:
> On Thu, Dec 03, 2020 at 04:45:56PM -0800, Richard Cochran wrote:
> > Yes, that would make sense. It would bring sysfs back to feature
> > parity with the ioctls.
>
> Which is a good thing?
Yes, of cours
On Thu, Dec 03, 2020 at 06:00:37PM -0800, Jonathan Lemon wrote:
> On Thu, Dec 03, 2020 at 04:56:24PM -0800, Richard Cochran wrote:
> > The name here is a bit confusing since "timex" has a special meaning
> > in the NTP/PTP API.
>
> The .gettimex64 call is used her
;
> Signed-off-by: Jonathan Lemon
Acked-by: Richard Cochran
On Sat, Dec 05, 2020 at 03:49:27AM +0200, Vladimir Oltean wrote:
> So there you go, it just says "the reference plane marking the boundary
> between the PTP node and the network". So it depends on how you draw the
> borders.
It depends on the physical link technology. You can't just "draw the
bor
On Sun, Dec 06, 2020 at 03:37:47PM +0200, Eran Ben Elisha wrote:
> Adding new enum to the ioctl means we have add
> (HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY for example) all the way - drivers,
> kernel ptp, user space ptp, ethtool.
>
> My concerns are:
> 1. Timestamp applications (like ptp4l or similar)
On Mon, Dec 07, 2020 at 12:37:45AM -0800, Saeed Mahameed wrote:
> we are not adding any new mechanism.
Sorry, I didn't catch the beginning of this thread. Are you proposing
adding HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY to net_tstamp.h ?
If so, then ...
> Our driver feature is and internal enhanceme
On Mon, Dec 07, 2020 at 12:42:33PM -0800, Jakub Kicinski wrote:
> The behavior is not entirely dissimilar to the time stamps on
> multi-layered devices (e.g. DSA switches). The time stamp can either
> be generated when the packet enters the device (current mlx5 behavior)
> or when it actually egr
ect warnings from strict checkpatch
Next time, please put "v2" in the Subject line. That helps reviewers
keep track.
> Signed-off-by: Min Li
Acked-by: Richard Cochran
On Tue, Nov 17, 2020 at 05:21:48PM -0800, Vinicius Costa Gomes wrote:
> Agreed that would be easiest/simplest. But what I have in hand seems to
> not like it, i.e. I have an earlier series implementing this "one shot" way
> and it's not reliable over long periods of time or against having the
> sys
tion.
>
> Signed-off-by: Ahmad Fatoum
Thanks!
Acked-by: Richard Cochran
On Tue, Nov 17, 2020 at 08:31:21PM +0100, Christian Eggers wrote:
> Using a PTP wide enum will obsolete different driver internal defines
> and uses of magic numbers.
I like the general idea, but ...
> +enum ptp_msg_type {
> + PTP_MSGTYPE_SYNC= 0x0,
> + PTP_MSGTYPE_DELAY_REQ = 0
On Fri, Nov 20, 2020 at 09:41:03AM +0100, Christian Eggers wrote:
> This series introduces commen defines for PTP event messages. Driver
> internal defines are removed and some uses of magic numbers are replaced
> by the new defines.
Nice cleanup!
Reviewed-by: Richard Cochran
Thanks,
Richard
On Wed, Nov 18, 2020 at 04:22:37PM -0800, Vinicius Costa Gomes wrote:
> Talking with the hardware folks, they recommended using the periodic
> method, the one shot method was implemented as a debug/evaluation aid.
I'm guessing ...
The HW generates pairs of time stamps, right?
And these land in
On Sat, Nov 21, 2020 at 03:26:11AM +0200, Vladimir Oltean wrote:
> On Thu, Nov 19, 2020 at 06:51:15PM +, tristram...@microchip.com wrote:
> > The receive and transmit latencies are different for different connected
> > speed. So the
> > driver needs to change them when the link changes. For
On Sat, Nov 21, 2020 at 03:26:11AM +0200, Vladimir Oltean wrote:
> On Thu, Nov 19, 2020 at 06:51:15PM +, tristram...@microchip.com wrote:
> > I think the right implementation is for the driver to remember this receive
> > timestamp
> > of Pdelay_Req and puts it in the tail tag when it sees a
On Mon, Nov 23, 2020 at 03:20:06PM -0500, min.li...@renesas.com wrote:
> From: Min Li
>
> Feed kstrtou8 with NULL terminated string.
>
> Changes since v1:
> -Use strscpy instead of strncpy for safety.
>
> Signed-off-by: Min Li
> ---
> drivers/ptp/ptp_clockmatrix.c | 60
>
by: Antoine Tenart
> - [3/3] removed dead email addresses from Cc:
>
>
> This series replaces further driver internal enumeration / uses of magic
> numbers with the newly introduced PTP_MSGTYPE_* defines.
For the series:
Acked-by: Richard Cochran
On Tue, Nov 24, 2020 at 11:01:26AM -0500, min.li...@renesas.com wrote:
> From: Min Li
>
> Feed kstrtou8 with NULL terminated string.
>
> Changes since v1:
> -Use sscanf to get rid of adhoc string parse.
This is much nicer. Small issue remains...
> + u8 ver1[3], ver2[3];
> + int i;
> +
On Wed, Nov 11, 2020 at 05:24:41PM +0800, Wang Qing wrote:
> We always have to update the value of ret, otherwise the error value
> may be the previous one. And ptp_clock_register() never return NULL
> when PTP_1588_CLOCK enable.
NAK.
Your code must handle the possibility that ptp_clock_registe
On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote:
>
> Following Richard's comments v1 of the patch has to be applied [1].
> I've also added my Reviewed-by there.
>
> [1] https://lore.kernel.org/patchwork/patch/1334067/
+1
Jakub, can you please take the original v1 of this patch
On Thu, Nov 12, 2020 at 12:05:25PM +0200, Grygorii Strashko wrote:
> But, as Richard mentioned [1], ptp_clock_register() may return NULL even if
> PTP_1588_CLOCK=y
> (which I can't confirm neither deny - from the fast look at
> ptp_clock_register()
> code it seems should not return NULL)
This w
On Thu, Nov 12, 2020 at 09:25:12AM +0100, Arnd Bergmann wrote:
> This is not really getting any better. If Richard is worried about
> Kconfig getting changed here, I would suggest handling the
> case of PTP being disabled by returning an error early on in the
> function, like
>
> struct am65_cpts
On Thu, Nov 12, 2020 at 10:21:21PM +0100, Arnd Bergmann wrote:
> I agree that the 'imply' keyword in Kconfig is what made this a
> lot worse, and it would be best to replace that with normal
> dependencies.
IIRC, this all started with tinification and wanting dynamic posix
clocks to be optional at
On Thu, Nov 12, 2020 at 03:46:12PM -0800, Vinicius Costa Gomes wrote:
> I wanted it so using PCIe PTM was transparent to applications, so adding
> another API wouldn't be my preference.
>
> That being said, having a trigger from the application to start/stop the
> PTM cycles doesn't sound too bad
On Fri, Nov 13, 2020 at 04:40:20AM +0200, Vladimir Oltean wrote:
> > @@ -103,6 +108,10 @@ static int ksz9477_ptp_adjtime(struct ptp_clock_info
> > *ptp, s64 delta)
> > if (ret)
> > goto error_return;
> >
> > + spin_lock_irqsave(&dev->ptp_clock_lock, flags);
>
> I believe that sp
On Fri, Nov 13, 2020 at 04:53:11AM +0200, Vladimir Oltean wrote:
> Richard, do you think we can clarify the intended usage of PTP_CLK_REQ_PPS
> in the documentation? It doesn't appear to be written anywhere that
> PTP_ENABLE_PPS is supposed to enable event generation for the drivers/pps
> subsyste
On Fri, Nov 13, 2020 at 11:10:58AM -0800, Vinicius Costa Gomes wrote:
> I am proposing a series that adds support for PCIe PTM (for the igc
> driver), exporting the values via the PTP_SYS_OFFSET_PRECISE ioctl().
>
> The way PTM works in the NIC I have, kind of forces me to start the PTM
> dialogs
On Fri, Nov 13, 2020 at 05:21:43PM +0100, Arnd Bergmann wrote:
> I've prototyped a patch that I think makes this more sensible
> again: https://pastebin.com/AQ5nWS9e
I like the behavior described in the text.
Instead of this ...
- if a built-in driver calls PTP interface functions but fails
On Mon, Nov 16, 2020 at 05:06:30PM -0800, Vinicius Costa Gomes wrote:
> The PTM dialogs are a pair of messages: a Request from the endpoint (in
> my case, the NIC) to the PCIe root (or switch), and a Response from the
> other side (this message includes the Master Root Time, and the
> calculated pr
On Mon, Nov 16, 2020 at 05:07:37PM -0800, Jakub Kicinski wrote:
> On Fri, 13 Nov 2020 16:10:54 -0800 Tony Nguyen wrote:
> > +/* get PTP pins for ioctl */
> > +#define SIOCGPINS (SIOCDEVPRIVATE + 0)
> > +/* set PTP pins for ioctl */
> > +#define SIOCSPINS (SIOCDEVPRIVATE + 1)
>
> This is unexpec
ialization/deinitialization")
> Signed-off-by: Grygorii Strashko
Acked-by: Richard Cochran
On Mon, Dec 28, 2020 at 07:57:20PM -0500, Willem de Bruijn wrote:
> There is a well understood method for synchronizing guest and host
> clock in KVM using ptp_kvm. For virtual environments without NIC
> hardware offload, the when host timestamps in software, this suffices.
>
> Syncing host with N
On Mon, Dec 28, 2020 at 11:22:33AM -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Add optional delivery time (SO_TXTIME) offload for virtio-net.
>
> The Linux TCP/IP stack tries to avoid bursty transmission and network
> congestion through pacing: computing an skb delivery time base
27;
>
> Fixes: 539e44d26855 ("dp83640: Include hash in timestamp/packet matching")
> Signed-off-by: Arnd Bergmann
Acked-by: Richard Cochran
-linux-ld: drivers/ptp/ptp_ines.o: in function `ines_ptp_ctrl_probe':
> ptp_ines.c:(.text+0x17e6): undefined reference to
> `devm_platform_ioremap_resource'
>
> Prevent builds of ptp_ines.c when HAS_IOMEM is not set.
Acked-by: Richard Cochran
On Sun, Jan 10, 2021 at 09:49:03PM +0900, Vincent Mailhol wrote:
> * The hardware rx timestamp of a local loopback message is the
> hardware tx timestamp. This means that there are no needs to
> implement SOF_TIMESTAMPING_TX_HARDWARE for CAN sockets.
I can't agree with that statement. T
On Tue, Jan 12, 2021 at 09:00:33AM +0900, Vincent MAILHOL wrote:
> Out of curiosity, which programs do you use? I guess wireshark
> but please let me know if you use any other programs (I just use
> to write a small C program to do the stuff).
I was thinking of PTP over DeviceNET (which, in turn,
On Mon, Jan 11, 2021 at 08:17:48PM +0200, Eran Ben Elisha wrote:
> Add support for parsing PTP L2 packet header. Such packet consists
> of an L2 header (with ethertype of ETH_P_1588), PTP header, body
> and an optional suffix.
>
> Signed-off-by: Eran Ben Elisha
> Reviewed-by: Tariq Toukan
> ---
I'm just catching up with this.
Really. Truly. Please -- Include the maintainer on CC for such patches!
In case you don't know who that is, you can always consult the MAINTAINERS file.
There you will find the following entry.
PTP HARDWARE CLOCK SUPPORT
M: Richard Coch
1 - 100 of 770 matches
Mail list logo
