Re: [PATCH 1/2] net: ethernet: ti: cpts: convert to use kthread_worker

On Fri, Jul 21, 2017 at 06:49:42PM -0500, Grygorii Strashko wrote: > There could be significant delay in CPTS work schedule under high system > load and on -RT which could cause CPTS misbehavior due to internal counter > overflow. Usage of own kthread_worker allows to avoid such kind of issues >

Re: [PATCH V3 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

On Sat, Jul 22, 2017 at 11:38:26PM +, Salil Mehta wrote: > > On Sat, Jun 17, 2017 at 06:24:28PM +0100, Salil Mehta wrote: > > > + > > > +int hclge_tm_schd_init(struct hclge_dev *hdev); > > > +int hclge_tm_setup_tc(struct hclge_dev *hdev); > > > > The definition of this function DNE. > Sorry,

Re: [PATCH V4 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

On Sat, Jul 22, 2017 at 11:09:39PM +0100, Salil Mehta wrote: > +int hclge_tm_setup_tc(struct hclge_dev *hdev); Like I said before, this function DNE. Thanks, Richard

Re: [PATCH 1/2] net: ethernet: ti: cpts: convert to use kthread_worker

On Mon, Jul 24, 2017 at 07:34:38PM -0500, Grygorii Strashko wrote: > Below if pure TBD/RFC version of patch which add kthread worker to PTP core. > I'm sending it to get you opinion about implementation in general, before > continue with more changes. Pls, take a look if you have time? > - are

Re: [PATCH v3 1/3] ptp: introduce ptp auxiliary worker

On Wed, Jul 26, 2017 at 05:11:36PM -0500, Grygorii Strashko wrote: > @@ -217,6 +231,19 @@ struct ptp_clock *ptp_clock_register(struct > ptp_clock_info *info, > mutex_init(>pincfg_mux); > init_waitqueue_head(>tsev_wq); > > + if (ptp->info->do_aux_work) { > + char

Re: [PATCH v2 1/3] ptp: introduce ptp auxiliary worker

Thanks for coding this up. I'd like to get some broader review. On the next round, please include lkml, John Stultz, and Thomas Gleixner. On Tue, Jul 25, 2017 at 03:24:18PM -0500, Grygorii Strashko wrote: > @@ -217,6 +231,19 @@ struct ptp_clock *ptp_clock_register(struct > ptp_clock_info

Re: [PATCH v2 1/3] ptp: introduce ptp auxiliary worker

On Wed, Jul 26, 2017 at 06:24:39AM +0200, Richard Cochran wrote: > Thanks for coding this up. I'd like to get some broader review. On > the next round, please include lkml, John Stultz, and Thomas Gleixner. I just noticed that you already have lkml. Thanks, Richard

Re: [PATCH RESEND 0/2] enable hires timer to timeout datagram socket

On Fri, Aug 18, 2017 at 06:44:08PM +, Vallish Vaidyeshwara wrote: > There has been a behavior change in 4.9 kernel with refactoring of Kernel > timer wheel in 4.8. We have a use case wherein our datagram socket > application is sensitive to socket timeout including long timeouts. > > One of

Re: [PATCH RESEND 0/2] enable hires timer to timeout datagram socket

On Fri, Aug 18, 2017 at 10:27:56PM +, Vallish Vaidyeshwara wrote: > We have a on-demand application that uses long timeouts and needs to react to > events within milliseconds. Huh? The test program you posted does not react to any event. Thanks, Richard

Re: [PATCH RFC 0/3] Improve stability of system clock

On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote: > On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar > wrote: > > Is there a better way to run the timekeeping code in an userspace > > application? I suspect it would need something like the Linux Kernel > >

Re: [PATCH 1/4] net: macb: Add support for PTP timestamps in DMA descriptors

On Tue, May 09, 2017 at 10:24:45AM +0100, Rafal Ozieblo wrote: > This patch adds support for PTP timestamps in > DMA buffer descriptors. It checks capability at runtime > and uses appropriate buffer descriptor. > > Signed-off-by: Rafal Ozieblo You posted this series once

Re: [patch 05/26] posix-clocks: Remove interval timer facility and mmap/fasync callbacks

ble extension. For now keep just what ptp_clock > needs. > > Signed-off-by: Thomas Gleixner <t...@linutronix.de> Acked-by: Richard Cochran <richardcoch...@gmail.com> For the record, recently someone did try to implement this interface for the i210 card. Although there were i

Re: [PATCH v2 4/4] net: macb: Add hardware PTP support

On Fri, Jun 02, 2017 at 03:28:10PM +0100, Rafal Ozieblo wrote: > +int gem_get_hwtst(struct net_device *dev, struct ifreq *rq) > +{ > + struct macb *bp = netdev_priv(dev); > + struct hwtstamp_config *tstamp_config = >tstamp_config; > + > + if ((bp->hw_dma_cap & HW_DMA_CAP_PTP) == 0) >

Re: [PATCH v2 4/4] net: macb: Add hardware PTP support

On Wed, Jun 07, 2017 at 11:13:36AM +, Rafal Ozieblo wrote: > Please look at following call-stack: > > 1. macb_interrupt() // spin_lock(>lock) is taken > 2. macb_tx_interrupt() > 3. macb_handle_txtstamp() > 4. skb_tstamp_tx() > 5. __skb_tstamp_tx() > 6. skb_may_tx_timestamp() > 7.

Re: [PATCH V3 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

On Sat, Jun 17, 2017 at 06:24:28PM +0100, Salil Mehta wrote: > + > +int hclge_tm_schd_init(struct hclge_dev *hdev); > +int hclge_tm_setup_tc(struct hclge_dev *hdev); The definition of this function DNE. > +int hclge_pause_setup_hw(struct hclge_dev *hdev); > + > +#endif > -- > 2.7.4 Thanks,

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote: > +Example: > + > +ptp_dte: ptp_dte@180af650 { > + compatible = "brcm,ptp-dte"; > + reg = <0x180af650 0x10>; > + status = "okay"; > +}; This patch set looks okay, as far as it goes, but how does one actually use the

Re: [PATCH 3/4] net: macb: Add hardware PTP support

On Tue, May 02, 2017 at 01:57:15PM +, Rafal Ozieblo wrote: > > What is the point of this wrapper function anyhow? Please remove it. > gem_ptp_gettime() is assigned in ptp_clock_info and it has to have > ptp_clock_info pointer as first parameter. gem_tsu_get_time() is used in > the source

Re: [PATCH v2 4/4] net: macb: Add hardware PTP support

On Tue, Jun 06, 2017 at 08:54:50AM +, Rafal Ozieblo wrote: > Would "ENOTSUP" be sufficient ? You mean EOPNOTSUPP? Yes, sounds ok to me. EFAULT is surely wrong. Thanks, Richard

Re: [PATCH v2 4/4] net: macb: Add hardware PTP support

On Fri, Jun 02, 2017 at 03:28:10PM +0100, Rafal Ozieblo wrote: > +static s32 gem_get_ptp_max_adj(void) > +{ > + return 64E6; > +} This is a floating point constant. Please use integer instead. > + > +static int gem_get_ts_info(struct net_device *dev, > +struct

Re: [PATCH v2 3/4] net: macb: macb.c changed to macb_main.c

On Fri, Jun 02, 2017 at 03:27:41PM +0100, Rafal Ozieblo wrote: > drivers/net/ethernet/cadence/macb.c | 3568 > -- > drivers/net/ethernet/cadence/macb_main.c | 3568 > ++ You deleted macb.c, and so ... > diff --git

Re: [PATCH v2 3/4] net: macb: macb.c changed to macb_main.c

On Tue, Jun 06, 2017 at 03:00:15PM -0400, David Miller wrote: > He's adjusting the Makefile so that it build macb_main.c into macb.o Duh, sorry, brain shutting down... Thanks, Richard

Re: [PATCH RFC V1 net-next 1/6] net: Add a new socket option for a future transmit time.

On Mon, Sep 18, 2017 at 09:41:16AM +0200, Richard Cochran wrote: > diff --git a/arch/powerpc/include/uapi/asm/socket.h > b/arch/powerpc/include/uapi/asm/socket.h > index 3c590c7c42c0..55718129ab06 100644 > --- a/arch/powerpc/include/uapi/asm/socket.h > +++ b/arch/powerpc/include/ua

Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission

On Wed, Sep 20, 2017 at 11:35:33AM -0600, levipear...@gmail.com wrote: > Anyway, I am wholly in favor of this proposal--in fact, it is very similar to > a patch set I shared with Eric Mann and others at Intel in early Dec 2016 with > the intention to get some early feedback before submitting here.

[PATCH RFC V1 net-next 2/6] net: skbuff: Add a field to support time based transmission.

Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- include/linux/skbuff.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 72299ef00061..bc7f7dcbb413 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@

[PATCH RFC V1 net-next 1/6] net: Add a new socket option for a future transmit time.

This patch introduces SO_TXTIME. User space enables this option in order to pass a desired future transmit time in a CMSG when calling sendmsg(2). Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- arch/alpha/include/uapi/asm/socket.h | 3 +++ arch/frv/include/uapi/asm/so

[PATCH RFC V1 net-next 4/6] net: ipv4: udp: Hook into time based transmission.

For udp packets, copy the desired future transmit time from the CMSG cookie into the skb. Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- net/ipv4/udp.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index ef29df

[PATCH RFC V1 net-next 0/6] Time based packet transmission

on the i210 cards. The test program is appended, below. If anyone is interested in reproducing this test, I can provide helper scripts. Thanks, Richard Richard Cochran (6): net: Add a new socket option for a future transmit time. net: skbuff: Add a field to support time based transmission

[PATCH RFC V1 net-next 6/6] net: igb: Implement time based transmission.

This patch configures the i210 transmit queues to reserve the first queue for time based transmit arbitration, placing all other traffic into the second queue. This configuration is hard coded and does not make use of the two spare queues. Signed-off-by: Richard Cochran <rcoch...@linutronix

[PATCH RFC V1 net-next 5/6] net: packet: Hook into time based transmission.

For raw layer-2 packets, copy the desired future transmit time from the CMSG cookie into the skb. Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- net/packet/af_packet.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c

[PATCH RFC V1 net-next 3/6] net: ipv4: raw: Hook into time based transmission.

For raw packets, copy the desired future transmit time from the CMSG cookie into the skb. Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- net/ipv4/raw.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c index 33b70bfd1122..f6805973629b

Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission

On Tue, Sep 19, 2017 at 04:43:02PM +0200, Miroslav Lichvar wrote: > If I understand it correctly, this also allows us to make a PTP/NTP > "one-step" clock with HW that doesn't support it directly. Cool, yeah, I hadn't thought of that, but it would work... Thanks, Richard

Re: [PATCH net-next RFC 5/9] net: dsa: forward hardware timestamping ioctls to switch driver

On Thu, Sep 28, 2017 at 10:25:34AM -0700, Florian Fainelli wrote: > This echoes back to Andrew's comments in patch 2, but we may have to > prefer PHY timestamping over MAC timestamping if both are available? > Richard, is that usually how the preference should be made? No, if the MAC supports

Re: [PATCH net-next RFC 2/9] net: dsa: mv88e6xxx: expose switch time as a PTP hardware clock

On Fri, Sep 29, 2017 at 03:17:02PM +, Brandon Streiff wrote: > > Although now that I'm looking it over again, I'm also not certain of > the need. Even if we're called more frequently than we expect, that > doesn't seem to be harmful with regard to timekeeping. Hmm. Just keep it simple and

Re: [PATCH net-next RFC 1/9] net: dsa: mv88e6xxx: add accessors for PTP/TAI registers

On Thu, Sep 28, 2017 at 10:25:33AM -0500, Brandon Streiff wrote: > This patch implements support for accessing PTP/TAI registers through To avoid confusion, it would be helpful to mention what TAI stands for here and also in the source code comments! Thanks, Richard

Re: [PATCH net-next RFC 2/9] net: dsa: mv88e6xxx: expose switch time as a PTP hardware clock

On Fri, Sep 29, 2017 at 03:28:02PM +, Brandon Streiff wrote: > > NETWORK_PHY_TIMESTAMPING implies NET_PTP_CLASSIFY (which I do use) > and net/core/timestamping.c (which I didn't). It probably makes more > sense to just depend on NET_PTP_CLASSIFY directly. Yes, that makes sense to do, if you

Re: [PATCH net-next RFC 2/9] net: dsa: mv88e6xxx: expose switch time as a PTP hardware clock

On Thu, Sep 28, 2017 at 10:25:34AM -0500, Brandon Streiff wrote: > +static int mv88e6xxx_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm) > +{ > + if (scaled_ppm == 0) > + return 0; > + > + return -EOPNOTSUPP; > +} We really want to have an adjustable clock here. More

Re: [PATCH net-next RFC 8/9] net: dsa: mv88e6xxx: add rx/tx timestamping support

On Thu, Sep 28, 2017 at 10:25:40AM -0500, Brandon Streiff wrote: > +static bool mv88e6xxx_should_tstamp(struct mv88e6xxx_chip *chip, int port, > + struct sk_buff *skb, unsigned int type) > +{ > + struct mv88e6xxx_port_hwtstamp *ps = >port_hwtstamp[port]; > +

Re: [PATCH net-next RFC 4/9] net: dsa: mv88e6xxx: add support for event capture

There are some issues here. On Thu, Sep 28, 2017 at 10:25:36AM -0500, Brandon Streiff wrote: > +static int mv88e6xxx_config_periodic_trig(struct mv88e6xxx_chip *chip, > + u32 ns, u16 picos) > +{ > + int err; > + u16 global_config; > + > + if

Re: [PATCH net-next RFC 8/9] net: dsa: mv88e6xxx: add rx/tx timestamping support

On Thu, Sep 28, 2017 at 10:25:40AM -0500, Brandon Streiff wrote: > We also utilize a feature of the "generation 3" PTP hardware that lets > us to embed the timestamp value into one of the reserved fields in the > PTP header. This lets us extract the timestamp out of the header and > avoid an SMI

Re: [PATCH net-next RFC 8/9] net: dsa: mv88e6xxx: add rx/tx timestamping support

On Thu, Sep 28, 2017 at 10:25:40AM -0500, Brandon Streiff wrote: > +void mv88e6xxx_port_txtstamp(struct dsa_switch *ds, int port, > + struct sk_buff *clone, unsigned int type) > +{ > + struct mv88e6xxx_chip *chip = ds->priv; > + struct mv88e6xxx_port_hwtstamp *ps =

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Fri, Sep 29, 2017 at 05:43:23AM -0400, Richard Cochran wrote: > I happy to see this series. I just finished porting an out-of-tree > PHC driver for the Marvell mv88e635x, and I want to mainline it, but I > also have a few uglies. This series looks really good. I won't even pos

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

Brandon, On Thu, Sep 28, 2017 at 10:25:32AM -0500, Brandon Streiff wrote: > - Patch #2: We expose the switch time as a PTP clock but don't support > adjustment (max_adj=0). The driver should implement a cyclecounter/timecounter. > Our platform adjusted a systemwide oscillator > from

Re: [PATCH RESEND 0/2] enable hires timer to timeout datagram socket

On Mon, Aug 21, 2017 at 06:22:10PM +, Vallish Vaidyeshwara wrote: > AWS Lambda is affected by this change in behavior in > system call. Following links has more information: > https://en.wikipedia.org/wiki/AWS_Lambda Quote: Unlike Amazon EC2, which is priced by the hour, AWS Lambda is

Re: [PATCH] ptp: make ptp_clock_info const

On Tue, Aug 22, 2017 at 12:06:23PM +0530, Bhumika Goyal wrote: > By testing I meant that they have been checked by the compiler. I > haven't run the code on a hardware or some test data. Yes, compiling is good enough for this change. Thanks, Richard > > Acked-by: Richard Cochran

Re: [PATCH] ptp: make ptp_clock_info const

On Mon, Aug 21, 2017 at 11:01:12PM +0530, Bhumika Goyal wrote: > File ptp_ixp46x.c is not tested as I could not find any architecture > to cross compile it. No problem. Thanks for test compiling the other drivers. Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH] net: ethernet: make ptp_clock_info const

On Mon, Aug 21, 2017 at 10:36:50PM +0530, Bhumika Goyal wrote: > Make these const as they are only used in a copy operation. > Done using Coccinelle. Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH net-next RFC 4/9] net: dsa: mv88e6xxx: add support for event capture

On Mon, Oct 09, 2017 at 04:08:50PM -0600, Levi Pearson wrote: > Another issue related to this is that while the free-running counter > in the hardware can't be easily adjusted, the periodic event generator > *can* be finely adjusted (via picosecond and sub-picosecond > accumulators) to correct for

Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission

On Wed, Oct 18, 2017 at 03:18:55PM -0700, Jesus Sanchez-Palencia wrote: > This is great. Just out of curiosity, were you using vlans on your tests? No, just raw packets. VLAN tags could be added trivially (in the program), but that naturally avoids the kernel's VLAN code. > I might try to

Re: [PATCH net-next v5 1/2] net: add support for Cavium PTP coprocessor

On Tue, Dec 12, 2017 at 12:41:35PM +0300, Aleksey Makarov wrote: > If ptp_clock_register() returns NULL, the device is still paired with the > driver, > but the driver is not registered in the PTP core. When ethernet driver needs > the reference to this cavium PTP driver, it calls

Re: [PATCH] ptp: make PTP a menuconfig to ease disabling it all

On Wed, Dec 13, 2017 at 10:01:15AM +0100, Vincent Legoll wrote: > I don't think there are alternatives available in Kconfig to achieve > the goal of easing the management of a .config with menuconfig. > > Do you have any idea about how to do it without using menuconfig ? scripts/config HTH,

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

On Mon, Dec 18, 2017 at 08:19:42PM +0100, Michael Kerrisk (man-pages) wrote: > > Let me try to come up with a text over the (USA) holiday weekend. > > Might you have a chance to look at this still? Sorry for forgetting this. I will have another chance over the upcoming international holiday...

Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface

On Fri, Dec 15, 2017 at 12:10:47PM +0100, Takashi Iwai wrote: > > - struct cyclecounter *cc = _dev->tc.cc; > > - cc->read = azx_cc_read; > > - cc->mask = CLOCKSOURCE_MASK(32); > > - cc->mult = 125; /* saturation after 195 years */ > > - cc->shift = 0; I want to get away from this

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

On Mon, Nov 20, 2017 at 11:53:02PM +0100, Arnd Bergmann wrote: > .B EINVAL > +The > +.I clk_id > +specified is not supported on this system. We return EINVAL when the clockid is not valid. That can mean two things. Either the SYS-V style hard coded positive clockid is out of range, or the

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

On Tue, Nov 21, 2017 at 09:06:37AM +0100, Arnd Bergmann wrote: > > I copied that line from clock_gettime() man page. I suppose we want to > fix change this in both pages, right? Any suggestions for a good way to > express your explanation in the man page? I suppose we don't want to > go into

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Wed, Nov 08, 2017 at 04:02:26AM +0100, Andrew Lunn wrote: > So i did a quick test. If the application joins 224.0.1.129 on the > slave interface, the switch will pass the packets to the host and to > the application. The application does join that group on the external (slave) interface. I'll

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Mon, Nov 06, 2017 at 06:55:46AM -0800, Richard Cochran wrote: > When I run with Layer2 transport and the switch as master, it seems to > work. Any other combination of role + transport fails. Oops, I had "slaveOnly" set in my PC's configuration. So layer2 seems to work as exp

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Mon, Nov 06, 2017 at 04:04:22PM +0100, Andrew Lunn wrote: > I assume you have tested basic networking? You can ping the other > machines in the network? Yes, I ssh into the device via the external switch port interface. Thanks, Richard

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Sun, Oct 08, 2017 at 11:38:21AM -0400, Richard Cochran wrote: > I will try to get my hands on some HW, perhaps by the end of October, > in order to test and complete your driver... I now have a 88E6352 to test your series on. Unfortunately, it doesn't really work. Here is what I did. 1

Re: [PATCH net-next v4 0/2] net: thunderx: add support for PTP clock

On Fri, Dec 08, 2017 at 01:34:38PM +0300, Aleksey Makarov wrote: > This series adds support for IEEE 1588 Precision Time Protocol > to Cavium ethernet driver. > > The first patch adds support for the Precision Time Protocol Clocks and > Timestamping coprocessor (PTP) found on Cavium processors. >

Re: [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

On Fri, Dec 01, 2017 at 01:17:34PM +0530, Sagar Arun Kamble wrote: > There is no real need for the users of timecounters to define cyclecounter > and timecounter variables separately. Since timecounter will always be > based on cyclecounter, have cyclecounter struct as member of timecounter >

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Tue, Nov 07, 2017 at 07:23:27PM -0800, Richard Cochran wrote: > The application does join that group on the external (slave) > interface. I'll find out why the delay request mechanism isn't > working... Looking back, I now recall that the series lets the HW embed the ti

Re: [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

On Sat, Dec 02, 2017 at 10:01:35AM +0530, Sagar Arun Kamble wrote: > There is no real need for the users of timecounters to define cyclecounter > and timecounter variables separately. Since timecounter will always be > based on cyclecounter, have cyclecounter struct as member of timecounter >

Re: [PATCH] ptp: make PTP a menuconfig to ease disabling it all

On Sat, Dec 09, 2017 at 04:07:15PM +0100, Vincent Legoll wrote: > No need to get into the submenu to disable all PTP-related > config entries. > > This makes it easier to disable all PTP config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from

Re: [PATCH net-next v5 2/2] net: thunderx: add timestamping support

On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote: > @@ -880,6 +889,46 @@ static void nic_pause_frame(struct nicpf *nic, int vf, > struct pfc *cfg) > } > } > > +/* Enable or disable HW timestamping by BGX for pkts received on a LMAC */ > +static void

Re: [PATCH net-next v5 1/2] net: add support for Cavium PTP coprocessor

Sorry I didn't finish reviewing before... On Mon, Dec 11, 2017 at 05:14:30PM +0300, Aleksey Makarov wrote: > +/** > + * cavium_ptp_adjfreq() - Adjust ptp frequency > + * @ptp: PTP clock info > + * @ppb: how much to adjust by, in parts-per-billion > + */ > +static int cavium_ptp_adjfreq(struct

Re: [PATCH net-next v5 2/2] net: thunderx: add timestamping support

On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote: > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h > b/drivers/net/ethernet/cavium/thunder/nic.h > index 4a02e618e318..204b234beb9d 100644 > --- a/drivers/net/ethernet/cavium/thunder/nic.h > +++

Re: [PATCH] ptp_pch: use helpers function for converting between ns and timespec

On Fri, Apr 27, 2018 at 03:36:18PM +0800, YueHaibing wrote: > use ns_to_timespec64() and timespec64_to_ns() instead of open coding Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH 09/18] ptp: Remove pr_fmt duplicate logging prefixes

On Thu, May 10, 2018 at 08:45:35AM -0700, Joe Perches wrote: > Converting pr_fmt from a simple define to use KBUILD_MODNAME added > some duplicate logging prefixes to existing uses. > > Remove them. > > Signed-off-by: Joe Perches <j...@perches.com> Acked-by: Rich

Re: PTP clock driver for FSL DPAA

On Tue, May 22, 2018 at 10:07:20AM +, Y.b. Lu wrote: > I'm going to make a PTP clock driver patch for FSL DPAA ethernet controller. > (drivers/net/ethernet/freescale/dpaa/) > Actually the 1588 timer module on FSL DPAA is same with the one on FSL eTSEC > in hardware.(whose PTP clock driver is

Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping

On Mon, Jun 04, 2018 at 03:08:36PM +0800, Yangbo Lu wrote: > +if FSL_DPAA_ETH > +config FSL_DPAA_ETH_TS > + bool "DPAA hardware timestamping support" > + select PTP_1588_CLOCK_QORIQ > + default n > + help > + Enable DPAA hardware timestamping support. > + This option

Re: [PATCH 1/5] ptp: rework gianfar_ptp as QorIQ common PTP driver

es. > > Signed-off-by: Yangbo Lu <yangbo...@nxp.com> For the series: Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH v2 0/8] gnss: add new GNSS subsystem

On Wed, May 30, 2018 at 12:32:34PM +0200, Johan Hovold wrote: > Another possible extension is to add generic 1PPS support. There are two possibilities to consider. 1. If the PPS causes an interrupt, then it should hook into the PPS subsystem. 2. If the PPS is a HW signal routed for example

Re: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware timestamping

On Wed, Apr 25, 2018 at 05:17:49PM +0800, Yangbo Lu wrote: > +/* PTP nominal frequency 1GHz */ > +#define DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS 1 Nit: Frequency is the inverse of the period. It can be one or the other, not both. Why not call it simply DPAA2_PTP_CLK_PERIOD_NS? You haven't

Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters

On Fri, Oct 27, 2017 at 02:50:05PM +0100, Jose Abreu wrote: > Ok, I will drop this documentation patch and the DT parsing and > send a new version. Please put me and the other interested parties (see the TSN threads on LKML) onto CC. Thanks, Richard

Re: [PATCH] net: gianfar_ptp: move set_fipers() to spinlock protecting area

On Mon, Jan 08, 2018 at 10:53:40AM -0200, Fabio Estevam wrote: > On Mon, Jan 8, 2018 at 8:13 AM, Yangbo Lu wrote: > > set_fipers() calling should be protected by spinlock. > > This patch is to move set_fipers() to spinlock protecting > > area in ptp_gianfar_adjtime() function.

Re: [v2] net: gianfar_ptp: move set_fipers() to spinlock protecting area

nfar_adjtime(). > > Signed-off-by: Yangbo Lu <yangbo...@nxp.com> Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH] igb: Fix a test with HWTSTAMP_TX_ON

On Tue, Feb 06, 2018 at 08:47:59PM +0100, Christophe JAILLET wrote: > 'HWTSTAMP_TX_ON' should be handled as a value, not as a bit mask. > The modified code should behave the same, because HWTSTAMP_TX_ON is 1 > and no other possible values of 'tx_type' would match the test. > However, this is more

Re: [PATCH v2] net: dsa: mv88e6xxx: hwtstamp: fix potential negative array index read

On Thu, Feb 15, 2018 at 12:31:39PM -0600, Gustavo A. R. Silva wrote: > _port_ is being used as index to array port_hwtstamp before verifying > it is a non-negative number and a valid index at line 209 and 258: > > if (port < 0 || port >= mv88e6xxx_num_ports(chip)) > > Fix this by checking _port_

Re: [PATCH v2] net: dsa: mv88e6xxx: hwtstamp: fix potential negative array index read

On Fri, Feb 16, 2018 at 07:48:46AM -0800, Richard Cochran wrote: > On Thu, Feb 15, 2018 at 12:31:39PM -0600, Gustavo A. R. Silva wrote: > > _port_ is being used as index to array port_hwtstamp before verifying > > it is a non-negative number and a valid index at line 209 and 258: &g

Re: [PATCH][next] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

On Thu, Feb 15, 2018 at 09:27:57PM +0100, Andrew Lunn wrote: > Do you prefer this, or making timehi and timelo a u64? The latter. While you are at it, please move the definition of 'ns' to the start of the function. Thanks, Richard

[PATCH net-next] net: phylink: Remove redundant netdev.phydev assignment

assignments, restricting manipulation of the netdev.phydev field to phy_attach_direct() and phy_detach(). Signed-off-by: Richard Cochran <richardcoch...@gmail.com> --- drivers/net/phy/phylink.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/phy/phylink.c b/drivers/net/ph

Re: [PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

On Mon, Feb 19, 2018 at 12:19:16PM +, David Laight wrote: > This seems to be somewhat excessive 64bit maths on a 32bit system. > It is more than enough to make timelo/timehi 'unsigned int'. Do you see a difference in the generated code? Thanks, Richard

Re: [PATCH] dsa: ptp; mark dummy helpers as 'inline'

On Thu, Feb 22, 2018 at 12:44:40PM +0100, Arnd Bergmann wrote: > Declaring a static function in a header leads to a warning every > time that header gets included without the function being used: Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface

On Tue, Dec 26, 2017 at 01:07:35PM +0530, Sagar Arun Kamble wrote: > > Or can we provide simpler versions for covering some defaults? At > > least reducing the number of arguments would make things easier. > Thought about specifying 1. cyclecounter read func 2. frequency 3. width of > counter as

Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface

On Tue, Jan 02, 2018 at 11:15:45AM -0600, Pierre-Louis Bossart wrote: > I wrote the code for HDaudio and I remember wasting time trying to figure > out the gory details of the cycle counter stuff when all I wanted was a > conversion from a 24MHz counter to ns values using a 125/3 operation in the

[PATCH man-pages 2/2] adjtimex.2: document clock_adjtime

mented. Before I do any changes to it, this tries to document what I understand it currently does. [ RC: Add better explanations of the usage and error codes and correct some typographical mistakes. ] Signed-off-by: Arnd Bergmann <a...@arndb.de> Signed-off-by: Richard Cochran <richardco

[PATCH man-pages 1/2] clock_getres.2: Explain dynamic clocks.

Linux has allowed passing open file descriptors to clock_gettime() and friends since v2.6.39. This patch documents these "dynamic" clocks and adds a brief example of how to use them. Signed-off-by: Richard Cochran <richardcoch...@gmail.com> --- man2/clo

Re: [PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

On Mon, Apr 02, 2018 at 03:28:47PM +0530, sricha...@codeaurora.org wrote: > Yes, i will post another series for ipq806[2/4] updates and the > corresponding > boards after this. I tried mainline on the ap148 using qcom_defconfig and the qcom-ipq8064-ap148.dtb, and it doesn't boot FYI. Thanks,

Re: [PATCH net] net: dsa: mv88e6xxx: Fix receive time stamp race condition.

On Mon, Apr 09, 2018 at 07:19:31AM -0700, Richard Cochran wrote: > Dave, please hold off on this patch. I am seeing new problems in my > testing with this applied. I still need to get to the bottom of > this. Looks like the new problems are a HW/board glitch. The patch is good to go.

[PATCH net] net: dsa: mv88e6xxx: Fix receive time stamp race condition.

on the stack before reading out the latched time stamp value. Fixes: c6fe0ad2c3499 ("net: dsa: mv88e6xxx: add rx/tx timestamping support") Signed-off-by: Richard Cochran <richardcoch...@gmail.com> --- drivers/net/dsa/mv88e6xxx/hwtstamp.c | 12 ++-- 1 file changed, 10 insertions

Re: [PATCH net] net: dsa: mv88e6xxx: Fix receive time stamp race condition.

On Mon, Apr 09, 2018 at 12:03:14AM -0700, Richard Cochran wrote: > This patch fixes the race by moving the queue onto a list on the stack > before reading out the latched time stamp value. > > Fixes: c6fe0ad2c3499 ("net: dsa: mv88e6xxx: add rx/tx timestamping support")

Re: [PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

On Fri, Apr 06, 2018 at 06:35:49PM +0530, sricha...@codeaurora.org wrote: > I tried booting mainline built with qcom_defconfig on ap148 and > did boot. Not sure if your bootloader's bootarg is this, > 'console=ttyMSM0,115200n8' ? Yes, I think so. I'll double check it. Do you have any

Re: [PATCH RFC net-next] igb: adjust SYSTIM register using TIMADJ register

On Fri, Apr 20, 2018 at 02:56:36PM -0500, Kshitiz Gupta wrote: > Currently the driver adjusts time by reading the current time and then > modifying it before writing to SYSTIM register. This can introduce > inaccuracies in SYSTIM. With a PREEMPT_RT kernel, spinlocks may be > interrupted, which in

Re: [BUG] igb: reconnecting of cable not always detected

On Tue, Apr 24, 2018 at 11:09:02AM -0700, Alexander Duyck wrote: > On Tue, Apr 24, 2018 at 8:14 AM, Holger Schurig > wrote: > > Sometimes, plugging the cable back in is detected ... > > > > [ 43.736922] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps > >

Re: [PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

On Thu, Mar 29, 2018 at 09:37:15AM -0500, Andy Gross wrote: > > Feel free to send your own contributions where you are adding the things that > are important to you. You can count on it. I am really happy that ipq4019 at least boots mainline. BTW is there any hope of getting a working mainline

Re: [PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

On Thu, Mar 29, 2018 at 09:37:15AM -0500, Andy Gross wrote: > > If you aren't actually testing/validating this specific board, how can you > make > a statement like this? Unless you have tested these specifically on this > board, > I'd appreciate not getting false information about what is or

Re: [PATCH v5 00/13] ARM: dts: ipq: updates to enable a few peripherals

On Sat, Mar 24, 2018 at 11:42:32AM +0530, sricha...@codeaurora.org wrote: > Can i take that as a Tested-by: Richard Cochran <richardcoch...@gmail.com> > on DK07 ? I wouldn't go that far, because I only booted to the console. I didn't test any peripherals beside the UART! I am plan

Re: [PATCH v5 00/13] ARM: dts: ipq: updates to enable a few peripherals

On Fri, Mar 23, 2018 at 03:48:43PM +0530, Sricharan R wrote: > [v5] > * Fixed a minor comment that i missed earlier. I tried booting this series with qcom_defconfig on my custom, dk07-like board. It works! Thanks a bunch, Richard

Re: [PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

On Tue, Mar 20, 2018 at 09:28:47AM +0530, Sricharan R wrote: > Reviewed-by: Abhishek Sahu > Adds missing memory, reserved-memory nodes. > > Signed-off-by: Sricharan R > --- > arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 28 >

Re: [PATCH v3 05/13] ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi

On Tue, Mar 20, 2018 at 09:28:48AM +0530, Sricharan R wrote: > Add the common parts for the dk04 boards. Does this board even boot with mainline linux? Thanks, Richard

<    2   3   4   5   6   7   8   9   10   11   >