by ARM platforms today if ptp_kvm is not supported.
>
> Fixes: 300bb1fe7671 ("ptp: arm/arm64: Enable ptp_kvm for arm/arm64")
> Signed-off-by: Jon Hunter
Acked-by: Richard Cochran
On Sun, Apr 18, 2021 at 12:18:42PM +0300, Vladimir Oltean wrote:
>
> How about not passing "clone" back to DSA as an argument by reference,
> but instead require the driver to populate DSA_SKB_CB(skb)->clone if it
> needs to do so?
>
> Also, how about changing the return type to void? Returning t
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> @@ -628,9 +620,7 @@ static netdev_tx_t dsa_slave_xmit(struct sk_buff *skb,
> struct net_device *dev)
>
> DSA_SKB_CB(skb)->clone = NULL;
>
> - /* Identify PTP protocol packets, clone them, and pass them to the
> - * swi
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
> drivers should adapt to it.
>
> - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
> port_txtstamp, so that most skbs not requiring tx timest
o the above mentioned feature. Users will be
> able to triggered capturing the time snapshot from user-space using
> application such as testptp or any other applications that uses the
> PTP_EXTTS_REQUEST ioctl request.
>
> Cc: Richard Cochran
> Signed-off-by: Tan Tee Min
> Co-de
On Mon, Apr 12, 2021 at 09:33:29AM -0700, Shannon Nelson wrote:
> If the original patches hadn't already been pulled into net-next, this is
> what I would have done. My understanding is that once the patches have been
> pulled into the repo that we need to do delta patches, not new versions of
> t
On Wed, Apr 07, 2021 at 04:19:53PM -0700, Shannon Nelson wrote:
> A few little changes after review comments and
> additional internal testing.
This series is a delta against the previously posted one. Please
follow the process by re-basing your changes into the original series,
putting a "v2" in
On Sun, Apr 11, 2021 at 10:40:28AM +0800, Wong Vee Khee wrote:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index 60566598d644..60e17fd24aba 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/
32.212364-4-jianyong...@arm.com
>
> Richard, Paolo,
>
> Can I get an Ack on this and patch #7? We're getting pretty close to
> the next merge window, and this series has been going on for a couple
> of years now...
For both patches:
Acked-by: Richard Cochran
On Tue, Apr 06, 2021 at 04:06:09PM -0700, Shannon Nelson wrote:
> Interesting... I doubt that our particular MAC and PHY will ever be
> separate, but it makes sense to watch for this in the general case. I've got
> an update coming for this.
Even if your HW can never support stacked MAC/PHY HW tim
On Tue, Apr 06, 2021 at 04:18:00PM -0700, Shannon Nelson wrote:
> On 4/5/21 11:17 AM, Richard Cochran wrote:
> > On Mon, Apr 05, 2021 at 09:16:39AM -0700, Shannon Nelson wrote:
> > > On 4/4/21 4:05 PM, Richard Cochran wrote:
> > > > This check is unneeded, because the
On Mon, Apr 05, 2021 at 09:33:46AM -0700, Shannon Nelson wrote:
> Yes, I supposed they could have gone together. However, I believe that in a
> bisection this will only slightly confuse the user space tools, but won't
> cause any kernel pain.
Bisection typically involves running tests from user s
On Mon, Apr 05, 2021 at 09:28:44AM -0700, Shannon Nelson wrote:
> On 4/4/21 4:41 PM, Richard Cochran wrote:
> > On Thu, Apr 01, 2021 at 10:56:07AM -0700, Shannon Nelson wrote:
> >
> > > @@ -1150,6 +1232,10 @@ netdev_tx_t ionic_start_xmit(struct sk_buff *skb,
> &g
On Mon, Apr 05, 2021 at 09:16:39AM -0700, Shannon Nelson wrote:
> On 4/4/21 4:05 PM, Richard Cochran wrote:
> > This check is unneeded, because the ioctl layer never passes NULL here.
>
> Yes, the ioctl layer never calls this with NULL, but we call it from within
> the d
On Thu, Apr 01, 2021 at 10:56:10AM -0700, Shannon Nelson wrote:
> Let the network stack know we've got support for timestamping
> the packets.
Actually, you already advertised the support to user space in Patch 10,
so this present patch should go before that one (or together).
Thanks,
Richard
On Thu, Apr 01, 2021 at 10:56:07AM -0700, Shannon Nelson wrote:
> @@ -1150,6 +1232,10 @@ netdev_tx_t ionic_start_xmit(struct sk_buff *skb,
> struct net_device *netdev)
> return NETDEV_TX_OK;
> }
>
> + if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP))
> +
On Thu, Apr 01, 2021 at 10:56:03AM -0700, Shannon Nelson wrote:
> +int ionic_lif_hwstamp_set(struct ionic_lif *lif, struct ifreq *ifr)
> +{
> + struct ionic *ionic = lif->ionic;
> + struct hwtstamp_config config;
> + int tx_mode = 0;
> + u64 rx_filt = 0;
> + int err, err2;
> +
On Thu, Apr 01, 2021 at 10:56:03AM -0700, Shannon Nelson wrote:
> @@ -0,0 +1,589 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright(c) 2017 - 2021 Pensando Systems, Inc */
> +
> +#include
> +#include
> +
> +#include "ionic.h"
> +#include "ionic_bus.h"
> +#include "ionic_lif.h"
> +#include
On Thu, Apr 01, 2021 at 10:56:00AM -0700, Shannon Nelson wrote:
> @@ -1722,11 +1722,15 @@ static void ionic_txrx_free(struct ionic_lif *lif)
>
> static int ionic_txrx_alloc(struct ionic_lif *lif)
> {
> - unsigned int sg_desc_sz;
> + unsigned int num_desc, desc_sz, comp_sz, sg_desc_sz;
>
g mul_u64_u64_div_u64().
>
> Signed-off-by: Yangbo Lu
Acked-by: Richard Cochran
On Tue, Mar 23, 2021 at 10:03:18AM +0100, Thierry Reding wrote:
> I agree. My understanding is the the TSC is basically an SoC-wide clock
> that can be (and is) used by several hardware blocks. There's an
> interface for software to read out the value, but it's part of a block
> called TKE (time-ke
On Mon, Mar 22, 2021 at 08:36:26AM -0700, Vinicius Costa Gomes wrote:
> After a long time, a couple of internal misunderstandings, fixing some
> typos in the delay adjustment constants and better error handling, this
> one shot method is working well.
>
> I will propose a new version, implementing
On Sat, Mar 20, 2021 at 01:44:20PM +0100, Arnd Bergmann wrote:
> Adding Richard Cochran as well, for drivers/ptp/, he may be able to
> identify whether this should be integrated into that framework in some
> form.
I'm not familiar with the GTE, but it sounds like it is a (free
r
x27;pch_ch_control_read()'
> ptp_pch: Move 'pch_*()' prototypes to shared header
> ptp: ptp_clockmatrix: Demote non-kernel-doc header to standard comment
> ptp: ptp_p: Demote non-conformant kernel-doc headers and supply a
> param description
For the series:
Acked-by: Richard Cochran
On Wed, Mar 10, 2021 at 04:50:44PM +0200, Vladimir Oltean wrote:
> As explained in commit 29d98f54a4fe ("net: enetc: allow hardware
> timestamping on TX queues with tc-etf enabled"), hardware TX
> timestamping requires an skb with skb->tstamp = 0. When a packet is sent
> with SO_TXTIME, the skb->sk
gt; - add mutex (thanks to Richard)
>
> v3:
> I did a mistake and did not test properly
> - add parenteses
> - fix the used variable
Acked-by: Richard Cochran
On Thu, Feb 25, 2021 at 03:05:32PM +0100, Heiko Thiery wrote:
> But the explanation why it is currently disabled that way can be found
> in the commit 91c0d987a9788dcc5fe26baafd73bf9242b68900.
Okay, without re-factoring the entire driver, I agree that the gettime
lock up aught to be fixed in a si
On Tue, Feb 23, 2021 at 04:04:16PM +0100, Heiko Thiery wrote:
> It is not only the PHC clock that stops. Rather, it is the entire
> ethernet building block in the SOC that is disabled, including the
> PHC.
Sure, but why does the driver do that?
Thanks,
Richard
On Tue, Feb 23, 2021 at 09:00:32AM +0100, Heiko Thiery wrote:
> HI Jakub,
>
> Am Di., 23. Feb. 2021 um 04:00 Uhr schrieb Jakub Kicinski :
> > Why is the PTP interface registered when it can't be accessed?
> >
> > Perhaps the driver should unregister the PTP clock when it's brought
> > down?
I don
On Thu, Feb 11, 2021 at 11:38:45PM -0500, vincent.cheng...@renesas.com wrote:
> From: Vincent Cheng
>
> When enabling output using PTP_CLK_REQ_PEROUT, need to align the output
> clock to the internal 1 PPS clock.
>
> Signed-off-by: Vincent Cheng
Acked-by: Richard Cochran
_adj[MAX_OUTPUT][4];
> };
Looks like this removal is unrelated to the patch subject, and so it
deserves its own small patch.
Acked-by: Richard Cochran
On Sat, Jan 23, 2021 at 12:12:27PM -0800, Jakub Kicinski wrote:
> I see. The only thing I'm worried about then is the churn in patch 3.
> This would land in Linus's tree shortly before rc6, kinda late to be
> taking chances in the name of minor optimizations :S
;^)
Yeah, by all means, avoid ARM c
On Fri, Jan 22, 2021 at 06:14:44PM -0800, Jakub Kicinski wrote:
> (I would put it in net-next tho, given the above this at most a space
> optimization.)
It isn't just about space but also time. The reason why I targeted
net and not net-next was that NETWORK_PHY_TIMESTAMPING activates a
function
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, 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 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 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 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 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
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 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
---
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
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
d-by: Tariq Toukan
Acked-by: Richard Cochran
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.
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 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
> ---
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 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
-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
27;
>
> Fixes: 539e44d26855 ("dp83640: Include hash in timestamp/packet matching")
> Signed-off-by: Arnd Bergmann
Acked-by: Richard Cochran
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
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
ialization/deinitialization")
> Signed-off-by: Grygorii Strashko
Acked-by: Richard Cochran
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 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
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 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
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 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 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
;
> Signed-off-by: Jonathan Lemon
Acked-by: Richard Cochran
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
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 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 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 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 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 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;
> +
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 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
>
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 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 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 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 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
tion.
>
> Signed-off-by: Ahmad Fatoum
Thanks!
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
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
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 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 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 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 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 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 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 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 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 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 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 Fri, Nov 06, 2020 at 03:56:45PM +0800, Wang Qing wrote:
> We always have to update the value of ret, otherwise the
> error value may be the previous one.
>
> Signed-off-by: Wang Qing
Acked-by: Richard Cochran
> ---
> drivers/net/ethernet/ti/am65-cpts.c | 3 +--
&g
On Fri, Nov 06, 2020 at 01:34:04PM +0200, Grygorii Strashko wrote:
> And ptp_clock_register() can return NULL only if PTP support is disabled.
Not true in general ...
> In which case, we should not even get here.
only because the Kconfig uses "depends on" instead of "implies"
PTP_1588_CLOCK.
>
On Sat, Nov 07, 2020 at 11:38:38AM +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, so we use IS_ERR here.
>
> Signed-off-by: Wang Qing
> ---
> driv
On Sat, Nov 07, 2020 at 11:28:23AM +0800, Wang Qing wrote:
> pcp_clock_register() is checked with IS_ERR(), and will crash if !PTP,
> change return value to ERR_PTR(-EOPNOTSUPP) for the !CONFIG_PTP_1588_CLOCK
> and so question resolved.
NAK.
Drivers must use the documented interface.
Thanks,
Ri
On Wed, Nov 04, 2020 at 03:45:08PM -0800, Jakub Kicinski wrote:
> Also are you sure the last patch is okay? Richard suggested it's not
> worth the risk AFAIU.
I took a look, and I can't find anything wrong with it.
Thanks,
Richard
On Thu, Nov 05, 2020 at 02:35:56AM +0200, Vladimir Oltean wrote:
> On the other hand and with all due respect, saying that it may have been
> 'buggy on some archs back in the day' and then not bringing any evidence
> is a bit of a strange claim to make.
You're right. I made the effort to look bac
On Wed, Nov 04, 2020 at 11:01:49AM -0500, min.li...@renesas.com wrote:
> From: Min Li
>
> Use div_s64 so that the neg_adj is not needed.
Back in the day, I coded the neg_adj because there was some issue with
signed 64 bit division that I can't recall now. Either div_s64 didn't
exist or it was b
On Wed, Nov 04, 2020 at 11:01:48AM -0500, min.li...@renesas.com wrote:
> From: Min Li
>
> Refactor idt82p33_xfer and use i2c_master_send for write operation.
> Because some I2C controllers are only working with single-burst write
> transaction.
>
> Signed-off-by: Min L
On Wed, Nov 04, 2020 at 11:01:47AM -0500, min.li...@renesas.com wrote:
> From: Min Li
>
> Add idt82p33_adjphase() to support PHC write phase mode.
>
> Signed-off-by: Min Li
Acked-by: Richard Cochran
mping.
> >
> > Fixes: e9523a5a32a1 ("net: ethernet: ti: cpsw: enable
> > HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter")
> > Signed-off-by: Grygorii Strashko
>
> CC: Richard
Acked-by: Richard Cochran
1 - 100 of 770 matches
Mail list logo
