as an optional part of that spec. In the
> meantime, this driver supports the simple ACPI form of the device which
> is being shipped in certain commercial hypervisors (and submitted for
> inclusion in QEMU).
>
> Signed-off-by: David Woodhouse
Acked-by: Richard Cochran
On Tue, Jun 25, 2024 at 11:34:24PM +0200, Thomas Gleixner wrote:
> There is effort underway to expose PTP clocks to user space via
> VDSO.
That sounds interesting. Has anything been posted?
Thanks,
Richard
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
On Wed, Apr 14, 2021 at 03:04:49AM +, Chen Jun wrote:
> the correct error is covered by put_old_timex32.
>
> Fixes: 3a4d44b61625 ("ntp: Move adjtimex related compat syscalls to native
> counterparts")
> Signed-off-by: Chen Jun
Reviewed-by: Richard Cochran
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 02:52:11PM +, chenjun (AM) wrote:
> 在 2021/4/12 22:20, Richard Cochran 写道:
> > On Mon, Apr 12, 2021 at 12:45:51PM +, Chen Jun wrote:
> >> the correct error is covered by put_old_timex32.
> >
> > Well, the non-negative return co
On Mon, Apr 12, 2021 at 12:45:51PM +, Chen Jun wrote:
> the correct error is covered by put_old_timex32.
Well, the non-negative return code (TIME_OK, TIME_INS, etc) is
clobbered by put_old_timex32().
> Fixes: f1f1d5ebd10f ("posix-timers: Introduce a syscall for clock tuning.")
This is not th
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 Mon, Mar 29, 2021 at 04:57:55PM +0200, Thomas Gleixner wrote:
> I think adjtimex is the right place and not yet another random file
> somewhere. Something like the below.
Perfect.
Acked-by: Richard Cochran
> ---
> include/uapi/linux/timex.h |7 +--
> ke
On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote:
> There are at least two issues with handling a zero offset as a special
> value. One is that zero could potentially be a valid value in distant
> future.
I not losing sleep over that, but
> The other is that the kernel updates the
On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote:
> On Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote:
> > Using ntpd on Debian, the service will set the offset, but only after
> > synchronization with the upstream server has been established, and
>
On Mon, Mar 29, 2021 at 11:56:31AM +0200, Daphne Preston-Kendal wrote:
> > The other is that the kernel updates the offset when a leap
> > second is inserted/deleted even if the original offset is zero, so
> > checking for zero (in the kernel or an application) works only until
> > the first leap s
On Fri, Mar 26, 2021 at 12:13:43PM +0100, Thomas Gleixner wrote:
> On Sat, Mar 13 2021 at 17:44, bugzilla-daemon wrote:
> > Unfortunately, although the majority of distributions ship with a leap
> > second file from the zoneinfo database, many or most of them (I have
> > Arch here) do not configure
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 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
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 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
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
---
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
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
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
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 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 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 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 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 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 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
amping tool is still useful for sanity testing of PTP drivers
> > HW timestamping capabilities it's reasonable to upstate it to support
> > PTPv2. This patch adds corresponding support which can be enabled by using
> > new parameter "PTPV2".
> >
> &g
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
On Wed, Oct 28, 2020 at 03:23:18PM +0100, Mauro Carvalho Chehab wrote:
> diff --git a/Documentation/ABI/testing/sysfs-uevent
> b/Documentation/ABI/testing/sysfs-uevent
> index aa39f8d7bcdf..d0893dad3f38 100644
> --- a/Documentation/ABI/testing/sysfs-uevent
> +++ b/Documentation/ABI/testing/sysfs-
On Thu, Oct 22, 2020 at 02:32:43PM +0300, Vladimir Oltean wrote:
> On Thu, Oct 22, 2020 at 01:11:40PM +0200, Christian Eggers wrote:
>
> > it seems that "moving" the timestamp back to the tail tag on TX is not
> > required anymore. Keeping the RX timestamp simply in the correction
> > field (negat
On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote:
> So how _does_ that work for TI PHYTER?
>
> As far as we understand, the PHYTER appears to autonomously mangle PTP packets
> in the following way:
> - subtracting t2 on RX from the correctionField of the Pdelay_Req
> - adding t3 on
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
On Fri, Oct 16, 2020 at 09:04:38AM +0200, Christian Eggers wrote:
> IPV4_HLEN() is only used for PTP. Is there any way to use "normal"
> infrastructure as in the rest of the network stack?
You answered your own question...
> It looks like PTP code
> typically has to look into multiple network lay
On Thu, Oct 15, 2020 at 07:30:38PM +, Min Li wrote:
> When you have time, can you take a look at this change? Thanks
Min,
I think your series was posted during a time when net-next was closed.
Please report the series.
Thanks,
Richard
On Wed, Oct 14, 2020 at 01:58:05PM +0200, Christian Eggers wrote:
> Both macros are already marked for removal.
I'm not sure what Daniel Borkmann meant by that comment, but ...
> switch (type & PTP_CLASS_PMASK) {
> case PTP_CLASS_IPV4:
> - ptr += IPV4_HLEN(ptr) + UDP_HLEN;
On Mon, Oct 12, 2020 at 09:07:30PM -0700, Tom Rix wrote:
> calling function is a print information only function that returns void.
That is fine.
> I do think not adding error handling is worth it.
>
> I could change the return and then the calls if if you like.
How about printing the version s
On Sun, Oct 11, 2020 at 01:09:55PM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> Clang static analysis reports this representative problem
>
> ptp_clockmatrix.c:1852:2: warning: 5th function call argument
> is an uninitialized value
> snprintf(idtcm->version, sizeof(idtcm->version)
On Fri, Sep 18, 2020 at 06:09:43PM +0800, Herrington wrote:
> diff --git a/include/linux/ptp_clock_kernel.h
> b/include/linux/ptp_clock_kernel.h
> index d3e8ba5c7125..5db4b8891b22 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -307,4 +307,13 @@ static
On Wed, Aug 26, 2020 at 03:12:51AM +, Xu Wang wrote:
> Because kfree_skb already checked NULL skb parameter,
> so the additional check is unnecessary, just remove it.
>
> Signed-off-by: Xu Wang
Acked-by: Richard Cochran
;
> Signed-off-by: Min Li
Acked-by: Richard Cochran
Other minor changes includes:
> adding more debug logs, increasing snap accuracy for pre 4.8.7 firmware
> and supporting new tcs2bin format.
>
> Signed-off-by: Min Li
Acked-by: Richard Cochran
On Mon, Jul 27, 2020 at 05:21:55PM +0800, Ooi, Joyce wrote:
> +/* ioctl to configure timestamping */
> +static int tse_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> +{
> + struct altera_tse_private *priv = netdev_priv(dev);
> + struct hwtstamp_config config;
> +
> + if
uct passed when we upscale the requested time
> stamping mode.
>
> Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National
> Semiconductor PHYTER.")
> Signed-off-by: Sergey Organov
Acked-by: Richard Cochran
ov
> ---
>
> v2:
> - Extracted from larger patch series
> - Description/comments updated according to discussions
> - Added Fixes: tag
Acked-by: Richard Cochran
On Sat, Jul 11, 2020 at 06:38:06PM +0200, Andrew Lunn wrote:
> But configuration does not belong in debugfs. It would be good to
> explain what is being configured by these parameters, then we can
> maybe make a suggestion about the correct API to use.
Can we at least enumerate the possibilities?
On Fri, Jul 10, 2020 at 01:58:44PM -0700, Jakub Kicinski wrote:
> On Fri, 10 Jul 2020 11:41:25 -0400 min.li...@renesas.com wrote:
> > From: Min Li
> >
> > This patch is to add debugfs support for ptp_clockmatrix and ptp_idt82p33.
> > It will create a debugfs directory called idtptp{x} and x is th
On Wed, Jul 08, 2020 at 03:23:59PM +0800, Ooi, Joyce wrote:
> @@ -222,6 +223,32 @@ static void tse_get_regs(struct net_device *dev, struct
> ethtool_regs *regs,
> buf[i] = csrrd32(priv->mac_dev, i * 4);
> }
>
> +static int tse_get_ts_info(struct net_device *dev,
> +
On Wed, Jul 08, 2020 at 03:37:29PM +0300, Sergey Organov wrote:
> Richard Cochran writes:
>
> > On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:
> >> There's no correct answer, I'm afraid. Whatever the default value of the
> >> clock may
On Tue, Jul 07, 2020 at 08:56:41PM +0300, Sergey Organov wrote:
> It won't. Supposedly it'd force clock (that doesn't tick by default and
> stays at 0) to start ticking.
No existing clockid_t has this behavior. Consider CLOCK_REALTIME or
CLOCK_MONOTONIC.
The PHC must act the same as the other P
On Tue, Jul 07, 2020 at 07:43:29PM +0300, Vladimir Oltean wrote:
> And overall, my argument is: you are making a user-visible change, for
> basically no strong reason, other than the fact that you like zero
> better. You're trying to reduce confusion, not increase it, right?
;^)
> I agree with t
On Mon, Jul 06, 2020 at 06:27:21PM +0300, Vladimir Oltean wrote:
> There's no correct answer, I'm afraid. Whatever the default value of the
> clock may be, it's bound to be confusing for some reason, _if_ the
> reason why you're investigating it in the first place is a driver bug.
> Also, I don't r
On Tue, Jul 07, 2020 at 10:04:37AM +0300, Vladimir Oltean wrote:
> > > We do it like this:
> > > - DSA: If there is a timestamping switch stacked on top of a
> > > timestamping Ethernet MAC, the switch hijacks the .ndo_do_ioctl of the
> > > host port, and you are supposed to use the PTP clock o
On Mon, Jul 06, 2020 at 09:33:30PM +0300, Sergey Organov wrote:
> Vladimir Oltean writes:
>
> > On Mon, Jul 06, 2020 at 06:21:59PM +0300, Sergey Organov wrote:
> > Both are finicky in their own ways. There is no real way for the user to
> > select which PHC they want to use. The assumption is tha
On Tue, Jun 23, 2020 at 04:30:12PM +0200, Antoine Tenart wrote:
> @@ -978,9 +1483,32 @@ static int __vsc8584_init_ptp(struct phy_device *phydev)
>
> vsc85xx_ts_eth_cmp1_sig(phydev);
>
> + vsc8531->mii_ts.rxtstamp = vsc85xx_rxtstamp;
> + vsc8531->mii_ts.txtstamp = vsc85xx_txtstamp;
1 - 100 of 911 matches
Mail list logo
