Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 07:34:03PM -0700, Christopher Hall wrote: > I hope this is helpful. Thanks. So the DSP does not produce or consume system time stamps. Fine. Still I fail to understand why you need the system time. Thomas seems to say that there are *other* applications that will want to

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 06:57:33PM -0700, Christopher Hall wrote: > >>+#define SHADOW_HISTORY_DEPTH 7 > > > >And that number is 7 because? > > Due to power of 2 it will be 8 instead. As above the useful history is 8-2*1 > ms (1 ms is the minimum jiffy length). Array size 4 would not be enough >

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 13, 2015 at 09:51:02AM +0200, Thomas Gleixner wrote: > > You are restricting the problem space to this particular use > case. There are other use cases where PTP is not available or not the > relevant reference, but you still want to correlate time domains to > ART. They may well be

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

Now that I am starting to understand what this code is trying to achieve... On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > The modification to the original patch accomodates these > slow devices by adding the option of providing an ART value outside > of the retry loop and

Re: [PATCH v4 3/4] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping

On Mon, Oct 12, 2015 at 11:45:21AM -0700, Christopher S. Hall wrote: > > +struct ptp_sys_offset_precise { > + unsigned int rsv[4];/* Reserved for future use. */ > + struct ptp_clock_time dev; > + struct ptp_clock_time sys; > +}; > + Please put the reserved field at the bottom.

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 13, 2015 at 09:15:51PM +0200, Thomas Gleixner wrote: > That's not working. The firmware is not going to change, no matter > what. Can we at least have a explanation of how the firmware operates? How are (ART,sys) pairs are generated, and how they are supposed to get into the DSP?

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > Another representative use case of time sync and the correlated > clocksource (in addition to PTP noted above) is PTP synchronized > audio. The added explanations of the audio use case do help. However, you did not address my

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote: > +int get_correlated_timestamp(struct correlated_ts *crt, > + struct correlated_cs *crs) > +{ > + struct timekeeper *tk = _core.timekeeper; > + unsigned long seq; > + cycles_t cycles,

Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info:

On Mon, Jul 06, 2015 at 03:44:58PM -0500, Josh Cartwright wrote: It's difficult to make too many judgements without seeing how a driver might implement this; is there another patchset that shows how a driver implements this? The interface is certainly clear enough to me. The details of

Re: [PATCH v3] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

() callback provided by the driver. The cross-timestamp is best effort where the latency between the capture of system time (getnstimeofday()) and the device time (driver callback) may be significant. The interface looks okay to me. Now all we need is a user of it... Acked-by: Richard Cochran

Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info:

On Wed, Jul 08, 2015 at 07:17:37AM -0500, Josh Cartwright wrote: It's unusual to see interfaces added like this without also seeing users at the same time to see how the pieces fit together. Should I have assumed this was a PATCH RFC for just the API? Chris, any idea when we might see a

Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

On Mon, Aug 24, 2015 at 08:16:51PM +, Hall, Christopher S wrote: This means: remove code changes from the PTP_SYS_OFFSET ioctl and call getsynctime64() from a new ioctl PTP_SYS_OFFSET_PRECISE. Right? Yes. And use the same type (struct ptp_sys_offset) for the new ioctl? Or should a

Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource

On Fri, Sep 04, 2015 at 05:10:21PM +0200, Peter Zijlstra wrote: > I think what they're getting at is asking if there's a rate limit to > time adjustments, without that, saving the last n transition points will > still not cover any given length of history. As if the ntp code isn't complex enough

Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource

On Fri, Sep 04, 2015 at 03:02:19PM +0200, Thomas Gleixner wrote: > No. This function is explicitely for the precise timestamp usecase, > which is required by PTP and other sane use cases. Right. The audio department only needs to know the (ART, ptp) offset. The kernel and user space never need

Re: [PATCH v3 1/4] Add correlated clocksource deriving system time from an auxiliary clocksource

On Thu, Sep 03, 2015 at 11:20:37PM +, Hall, Christopher S wrote: > In addition to the network interface, ART will be used in the audio interface > as well. > We need to support the case where an audio co-processor will control the > audio device. > In this case, the get_ts() function

Re: [PATCH 01/12] net: fec: avoid timespec use

ns_to_timespec64 can still be better as the > implementation can be hand-optimized in the future. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-ker

Re: [PATCH 02/12] net: stmmac: avoid using timespec

64() instead. > > Because of hardware limitations, there is still an overflow > in year 2106, which we cannot really avoid, but this documents > the overflow. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To

Re: [PATCH 03/12] net: igb: avoid using timespec

Arnd As author of these snippets, I went ahead and reviewed. I have one comment, below. Reviewed-by: Richard Cochran <richardcoch...@gmail.com> On Wed, Sep 30, 2015 at 01:26:33PM +0200, Arnd Bergmann wrote: > diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c > b/drivers/net/et

Re: [PATCH 03/12] net: igb: avoid using timespec

On Thu, Oct 01, 2015 at 10:01:57PM +0200, Arnd Bergmann wrote: > I tried to use this pattern whenever I convert the 64-bit 'long long' > tv_sec member of 'struct timespec64' into a 32-bit number, to annotate > the loss of range. Sounds reasonable to me. > I have thought about defining separate

Re: [PATCH 0/5] y2038 conversion for ntp/pps and sfc driver

ubsystems, so I'm also looking for the right person > to merge them. > > Please review. (Series was "lightly reviewed" ;) Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [PATCH 4/6] net: freescale: Fix module autoload for OF platform driver

ubject line should have been: net: gianfar_ptp: ... Acked-by: Richard Cochran <richardcoch...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.ker

Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC

On Mon, Sep 21, 2015 at 11:19:32PM +0530, Harini Katakam wrote: > Ping 1) trim your replies 2) put the PTP maintainer on PTP patches for review Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH] time: verify time values in adjtimex ADJ_SETOFFSET to avoid overflow

On Sun, Dec 06, 2015 at 10:07:01AM +0100, Thomas Gleixner wrote: > On Sat, 5 Dec 2015, Sasha Levin wrote: > > On 12/05/2015 12:10 PM, Thomas Gleixner wrote: > > > That's not a canonical timeval. timeval_valid() is what you want to > > > check it. Or has adjtimex some magic exception here? You

Re: [PATCH v3] net/macb: add support for resetting PHY using GPIO

On Wed, Dec 16, 2015 at 07:31:30PM +0100, Gregory CLEMENT wrote: > +Optional properties for PHY child node: > +- reset-gpios : Should specify the gpio for phy reset reset-gpios plural or reset-gpio singular? > + > Examples: > > macb0: ethernet@fffc4000 { > @@ -29,4 +32,8 @@ Examples: >

Re: [RFC v5 5/6] Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping

On Mon, Jan 04, 2016 at 04:45:22AM -0800, Christopher S. Hall wrote: > @@ -138,6 +142,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, > unsigned long arg) > caps.n_per_out = ptp->info->n_per_out; > caps.pps = ptp->info->pps; > caps.n_pins =

[PATCH] posix-clock: fix return code on the poll method's error path

to Markus Elfring for pointing out the suspicious signed/unsigned mismatch. Signed-off-by: Richard Cochran <richardcoch...@gmail.com> --- kernel/time/posix-clock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c index c

Re: posix-clock: Use an unsigned data type for a variable

On Mon, Dec 21, 2015 at 10:30:27AM +0100, SF Markus Elfring wrote: > > In this case, there is indeed a problem. However, just changing the > > type won't fix it. > > Would you like to explain your view on the handling of potential > data type mismatches a bit more? Yes, I will explain in the

Re: [PATCH] posix-clock: Use an unsigned data type for a variable

On Sun, Dec 20, 2015 at 09:19:20AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 20 Dec 2015 09:09:34 +0100 > > The data type "int" was used by the variable "result" in the > function "posix_clock_poll" even though the type "uint" will usually

Re: [PATCH 18/28] ptp: pch: allow build on MIPS platforms

On Mon, Nov 30, 2015 at 04:21:43PM +, Paul Burton wrote: > Allow the ptp_pch driver to be built on MIPS platforms in preparation > for use on the MIPS Boston board. > > Signed-off-by: Paul Burton <paul.bur...@imgtec.com> Acked-by: Richard Cochran <richardcoch...@gmail.c

Re: [patch 18/20] timer: Forward wheel clock whenever possible

Thomas, On Mon, Jun 13, 2016 at 08:41:04AM -, Thomas Gleixner wrote: > @@ -498,23 +500,27 @@ static void internal_add_timer(struct ti > __internal_add_timer(base, timer); > > /* > - * Check whether the other CPU is in dynticks mode and needs > - * to be triggered to

Re: [patch 13/20] timer: Switch to a non cascading wheel

On Mon, Jun 13, 2016 at 08:41:00AM -, Thomas Gleixner wrote: > +static inline struct timer_base *get_timer_base(u32 tflags) > +{ > + return get_timer_cpu_base(tflags, tflags & TIMER_BASEMASK); > +} This should rather be (tflags & TIMER_CPUMASK) to avoid using per_cpu_ptr() with the

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 11:30:00AM +0200, Henrik Austad wrote: > So loop data from kernel -> userspace -> kernelspace and finally back to > userspace and the media application? Huh? I wonder where you got that idea. Let me show an example of what I mean. void listener() {

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 12:18:44PM +0100, One Thousand Gnomes wrote: > On Mon, 13 Jun 2016 21:51:36 +0200 > Richard Cochran <richardcoch...@gmail.com> wrote: > > > > Actually, we already have support for tunable clock-like HW elements, > > namely the dynamic p

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > Whereas I want to do > > aplay some_song.wav Can you please explain how your patches accomplish this? Thanks, Richard

Re: [very-RFC 0/8] TSN driver for the kernel

On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote: > > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > >> I have seen audio PLL/multiplier chips that will take, for example, a > >> 10 kHz input and produce your 48 kHz media clock. With

Re: [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > Where is your media-application in this? Um, that *is* a media application. It plays music on the sound card. > You only loop the audio from > network to the dsp, is the media-application attached to the dsp-device? Sorry, I

Re: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

On Wed, Jun 15, 2016 at 02:13:03PM +0200, Henrik Austad wrote: > On Wed, Jun 15, 2016 at 01:49:08PM +0200, Richard Cochran wrote: > And how would v4l2 benefit from this being in alsalib? Should we require > both V4L and ALSA to implement the same, or should we place it in a common

Re: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

Now that I understand better... On Sun, Jun 12, 2016 at 01:01:35AM +0200, Henrik Austad wrote: > Userspace is supposed to reserve bandwidth, find StreamID etc. > > To use as a Talker: > > mkdir /config/tsn/test/eth0/talker > cd /config/tsn/test/eth0/talker > echo 65535 > buffer_size > echo

Re: [very-RFC 0/8] TSN driver for the kernel

On Wed, Jun 15, 2016 at 09:04:41AM +0200, Richard Cochran wrote: > On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote: > > Whereas I want to do > > > > aplay some_song.wav > > Can you please explain how your patches accomplish this? Never mind. Looking b

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 03:00:59PM +0200, Henrik Austad wrote: > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > > People have been asking me about TSN and Linux, and we've made some > > thoughts about it. The interest is there, and so I am glad to see

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 03:00:59PM +0200, Henrik Austad wrote: > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > > Which driver is that? > > drivers/net/ethernet/renesas/ That driver is merely a PTP capable MAC driver, nothing more. Although AVB is in

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's >DA clock must match that of the Talker and the other Listeners. >Either you adjust it in HW using a VCO or similar, or you do >adaptive

Re: [very-RFC 0/8] TSN driver for the kernel

Henrik, On Sun, Jun 12, 2016 at 01:01:28AM +0200, Henrik Austad wrote: > There are at least one AVB-driver (the AV-part of TSN) in the kernel > already, Which driver is that? > however this driver aims to solve a wider scope as TSN can do > much more than just audio. A very basic ALSA-driver is

Re: [PATCH] posix-clock: remove unneeded posix_clock_compat_ioctl()

On Wed, Jun 01, 2016 at 05:54:41PM +0900, Jungseung Lee wrote: > posix_clock_compat_ioctl() is identical to posix_clock_ioctl(). > We don't need additional compat_ioctl in this time. > Remove posix_clock_compat_ioctl() and let posix_clock_ioctl() is in charge. Did you test this patch? Did you

Re: [PATCH] net: tilegx: use correct timespec64 type

bit machines. > > However, using 'struct timespec64' directly is obviously the right > thing to do, and will help us remove 'struct timespec' in the future. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> > Fixes: b9acf24f779c ("ptp: tilegx: convert to the 64 bit get/

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote: > The ALSA API provides support for 'audio' timestamps (playback/capture rate > defined by audio subsystem) and 'system' timestamps (typically linked to > TSC/ART) with one option to take synchronized timestamps should the

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote: > Where is this "audio_time" program of which you speak? Never mind, found it in alsa-lib. I still would appreciate an answer to my other questions, though... Thanks, Richard

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: > You can experiment with the 'dma' and 'link' timestamps today on any > HDaudio-based device. Like I said the synchronized part has not been > upstreamed yet (delays + dependency on ART-to-TSC conversions that made it > in the

Re: [very-RFC 0/8] TSN driver for the kernel

On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote: > edit: this turned out to be a somewhat lengthy answer. I have tried to > shorten it down somewhere. it is getting late and I'm getting increasingly > incoherent (Richard probably knows what I'm talking about ;) so I'll stop > for

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Thu, Jun 23, 2016 at 12:38:48PM +0200, Henrik Austad wrote: > Richard: is it fair to assume that if ptp4l is running and is part of a PTP > domain, ktime_get() will return PTP-adjusted time for the system? No. > Or do I also need to run phc2sys in order to sync the system-time > to PTP-time?

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: > Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1 Where is this "audio_time" pro

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote: > > I still would appreciate an answer to my other questions, though... > > Currently HD-audio (both ASoC and legacy ones) are the only drivers > providing the link timestamp. In the recent code, it's PCM > get_time_info ops, so you

Re: [patch V3 19/22] timer: Forward wheel clock whenever possible

On Fri, Jun 24, 2016 at 02:32:19PM -, Thomas Gleixner wrote: > @@ -809,6 +815,12 @@ static void tick_nohz_restart_sched_tick > tick_do_update_jiffies64(now); > cpu_load_update_nohz_stop(); > > + /* > + * Clear the timer idle flag, so we avoid IPIs on remote queueing and

Re: [PATCH] ptp: ixp46x: use helpers for converting ns to timespec

+- > 1 file changed, 2 insertions(+), 5 deletions(-) Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH v7 5/8] time: Add history to cross timestamp interface supporting slower devices

On Fri, Feb 12, 2016 at 12:25:26PM -0800, Christopher S. Hall wrote: > /** > * get_device_system_crosststamp - Synchronously capture system/device > timestamp > - * @sync_devicetime: Callback to get simultaneous device time and > + * @get_time_fn: Callback to get simultaneous device time

Re: [PATCH v7 3/8] time: Remove duplicated code in ktime_get_raw_and_real()

On Fri, Feb 12, 2016 at 12:25:24PM -0800, Christopher S. Hall wrote: > The code in ktime_get_snapshot() is a superset of the code in > ktime_get_raw_and_real() code. Further, ktime_get_raw_and_real() is > called only by the PPS code, pps_get_ts(). Consolidate the > pps_get_ts() code into a single

Re: [PATCH v7 4/8] time: Add driver cross timestamp interface for higher precision time synchronization

On Fri, Feb 12, 2016 at 12:25:25PM -0800, Christopher S. Hall wrote: > /** > + * get_device_system_crosststamp - Synchronously capture system/device > timestamp > + * @sync_devicetime: Callback to get simultaneous device time and > + * system counter from the device driver > + * @xtstamp:

[PATCH] cpufreq: Make cpufreq_quick_get() safe to call.

accessing the data structure. Cc: Dirk Brandewie <dirk.brande...@gmail.com> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Cc: Viresh Kumar <viresh.ku...@linaro.org> Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/cpufreq/cpufreq.c | 10 +- 1 fi

[PATCH v2] cpufreq: Make cpufreq_quick_get() safe to call.

accessing the data structure. Cc: Dirk Brandewie <dirk.brande...@gmail.com> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Cc: Viresh Kumar <viresh.ku...@linaro.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- driver

[PATCH 1/5] mm: memcontrol: Remove redundant hot plug notifier test.

..@vger.kernel.org Cc: linux...@kvack.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- mm/memcontrol.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index d06cae2..993a261 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1916

[PATCH 4/5] oprofile: nmi-timer: Handle the FROZEN hot plug notifier actions.

t;r...@kernel.org> Cc: oprofile-l...@lists.sf.net Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/oprofile/nmi_timer_int.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/oprofile/nmi_timer_int.c b/drivers/oprofile/nmi_timer_int.c index 9559

[PATCH 5/5] cpufreq: acpi-cpufreq: Clean up hot plug notifier callback.

c: Viresh Kumar <viresh.ku...@linaro.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/cpufreq/acpi-cpufreq.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-c

[PATCH 3/5] thermal: x86_pkg_temp: Handle the FROZEN hot plug notifier actions.

: Zhang Rui <rui.zh...@intel.com> Cc: Eduardo Valentin <edubez...@gmail.com> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/thermal/x86_pkg_temp_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/5] watchdog: octeon: Handle the FROZEN hot plug notifier actions.

state is no longer a special case that leaves the watchdog active. Cc: Wim Van Sebroeck <w...@iguana.be> Cc: Guenter Roeck <li...@roeck-us.net> Cc: linux-watch...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/watchdog/octeon-wdt-main.c | 2 +-

Re: [patch 18/20] cpu/hotplug: Let upcoming cpu bring itself fully up

On Fri, Feb 26, 2016 at 06:43:41PM -, Thomas Gleixner wrote: > @@ -1204,7 +1212,7 @@ static bool cpuhp_is_ap_state(enum cpuhp > { > if (state >= CPUHP_AP_OFFLINE && state <= CPUHP_AP_ONLINE) > return true; FWIW, this test is superfluous after this change, because

[PATCH RFC] padata: Removed unused code.

teffen Klassert <steffen.klass...@secunet.com> Cc: linux-cry...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- include/linux/padata.h | 5 --- kernel/padata.c| 99 -- 2 files changed, 104 deletions(-) di

[PATCH RFC] lib: proportions: Remove unused code.

By accident I stumbled across code that is no longer used. According to git grep, the global functions in lib/proportions.c are not used anywhere. This patch removes the old, unused code. Cc: Ingo Molnar <mi...@kernel.org> Cc: Peter Zijlstra <pet...@infradead.org> Signed-off-by: Ric

Re: [PATCH] Implement leftpad syscall

On Fri, Apr 01, 2016 at 12:33:32AM +0200, Richard Weinberger wrote: > From: David Gstir > > Implement the leftpad() system call such that userspace, > especially node.js applications, can in the near future directly > use it and no longer depend on fragile npm packages. > >

[PATCH 06/10] intel_idle: Avoid a double free of the per-CPU data.

that actually need to free the per-CPU data. Cc: Len Brown <l...@kernel.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/idle/intel_idle.c b/

[PATCH 10/10] intel_idle: Clean up all registered devices on exit.

registrations on exit, even those from CPUs that are offline. Cc: Len Brown <l...@kernel.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/

[PATCH 09/10] intel_idle: Propagate hot plug errors.

ed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 4418cfa..8420ba1 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/

[PATCH 03/10] intel_idle: Remove redundant initialization calls.

removes the redundant code. Cc: Len Brown <l...@kernel.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_

[PATCH 05/10] intel_idle: Fix dangling registration on error path.

linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 4a1de3d..5dd741f 100644 --- a/drivers/idle/intel_

[PATCH 01/10] intel_idle: remove useless return from void function.

Cc: Len Brown <l...@kernel.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index ba947df..9d5ed32 100644 -

[PATCH 00/10] intel_idle: Fix hot plug handling.

, still this patch series cleans up the exit path in order to make the resource allocations clear. Richard Cochran (10): intel_idle: remove useless return from void function. intel_idle: Fix a helper function's return value. intel_idle: Remove redundant initialization calls. intel_idle: Fix

[PATCH 07/10] intel_idle: Setup the timer broadcast only on successful driver load.

el.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 0b56872..ab34cd8 100644 --- a/drivers/idle/intel_idle.c +

[PATCH 04/10] intel_idle: Fix deallocation order on the driver exit path.

by unregistering first on the exit path while holding the hot plug lock. Cc: Len Brown <l...@kernel.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> --- drivers/idle/intel_idle.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --g

[PATCH 08/10] intel_idle: Don't overreact to a cpuidle registration failure.

plug notifier callback. This patch moves the call to intel_idle_cpuidle_devices_uninit() outside of the helper function to the one call site that actually needs to perform the de-registrations. Cc: Len Brown <l...@kernel.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran

[PATCH 02/10] intel_idle: Fix a helper function's return value.

The function, intel_idle_cpuidle_driver_init, delivers no error codes at all. This patch changes the function to return 'void' instead of returning zero. Cc: Len Brown <l...@kernel.org> Cc: linux...@vger.kernel.org Signed-off-by: Richard Cochran <rcoch...@linutronix.de> ---

Re: [PATCH] ptp: use memdup_user().

On Fri, May 20, 2016 at 05:51:02PM +0530, Muhammad Falak R Wani wrote: > Use memdup_user to duplicate a memory region from user-space to > kernel-space, instead of open coding using kmalloc & copy_from_user. > > Signed-off-by: Muhammad Falak R Wani <falakre...@gmail.com&

Re: e1000e: can TIMINCA register be zero?

On Tue, Apr 19, 2016 at 12:44:08PM +0200, Denys Vlasenko wrote: > User says it happens on hotplug. This sounds familiar. http://lists.openwall.net/netdev/2016/02/07/90 It also only ever happends in a VM, right? > In 1000e_config_hwtstamp(), it is initialized before timecounter_init(): ...

get_nohz_timer_target?

Looking at kernel/sched/core.c:get_nohz_timer_target(), I don't understand the change made in: commit 9642d18eee2cd169b60c6ac0f20bda745b5a3d1e Author: Vatika Harlalka Date: Tue Sep 1 16:50:59 2015 +0200 nohz: Affine unpinned timers to housekeepers

[PATCH] timers/core: Correct callback order during CPU hot plug.

fixes the order within the hot plug state machine. Signed-off-by: Richard Cochran <rcoch...@linutronix.de> Fixes: 24f73b99716a ("timers/core: Convert to hotplug state machine") Cc: John Stultz <john.stu...@linaro.org> Cc: Jon Hunter <jonath...@nvidia.com> Cc: Li

Re: rc5+tip/master: Marking clocksource 'tsc' as unstable because the skew is too large:

Thomas, On Thu, Jun 30, 2016 at 03:43:34PM +0200, Thomas Gleixner wrote: > Patch below should fix the issue - the timer one, not yours :) This patch also fixes the occasionally delayed timers I reported on the r...@linutronix.de list. Thanks, Richard

Re: [patch 4 14/22] timer: Switch to a non cascading wheel

On Fri, Aug 12, 2016 at 01:50:16PM -0400, Rik van Riel wrote: > Could that cause the new timer wheel code to skip over > timer buckets occasionally, or is this hypothesis bunk? The new wheel is not different from the old one in this respect. Each base keeps its own jiffies counter. When

Re: [patch 4 14/22] timer: Switch to a non cascading wheel

On Fri, Aug 12, 2016 at 12:14:11PM -0700, Paul E. McKenney wrote: > FWIW, I do appear to be seeing more lost wakeups on current mainline > than on v4.7, but not enough of a difference to get a reliable bisction > in reasonable time. We are seeing reproducible hangs* when running Steven's

Re: [PREEMPT-RT] [patch 4 14/22] timer: Switch to a non cascading wheel

Jouni, If I understand the test correctly, then the slightly different kernel timer behavior is ok, but the test isn't quite right. Let explain what I mean. First off, reading test_ap_wps.py, the point of the test is to see if ten simultaneous connections are possible. I guess the server

Re: [patch 4/4] PTP: add kvm PTP driver

ollowing line to its configuration file: > > refclock PHC /dev/ptpX poll 3 dpoll -2 offset 0 > > Where /dev/ptpX is the kvmclock PTP clock. > > Signed-off-by: Marcelo Tosatti <mtosa...@redhat.com> Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure

On Mon, Jan 23, 2017 at 08:44:53PM +0100, Paolo Bonzini wrote: > If you just implement getclock64 the PTP_SYS_OFFSET output: > > device clock | |sample2| |sample4| |sample6| ... > - > realtime clock |sample1|

Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure

On Mon, Jan 23, 2017 at 09:06:20PM -0200, Marcelo Tosatti wrote: > Can you please describe what problem exists with this scheme? This new kernel code exists just because chrony doesn't implement the PRECISE ioctl. Instead of adding new "fake" modes, just teach chrony about the better method. I

Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure

On Tue, Jan 24, 2017 at 09:23:29AM -0200, Marcelo Tosatti wrote: > I'm resending v5 with native support for ->gettime and > ->getcrosststamps. And can you please drop the "fake" PTP_SYS_OFFSET stuff? Here is another reason why this is illogical. The application can choose how many samples to

Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure

On Fri, Jan 20, 2017 at 10:20:29AM -0200, Marcelo Tosatti wrote: > Emulate PTP_SYS_OFFSET by using an arithmetic mean of the > realtime samples from ->getcrosststamp callback. This change log is not very informative. Yes, I can see that the new code calculates a mean. But WHY is this needed?

Re: [PATCH 3/4] ptp: use is_visible method to hide unused attributes

On Tue, Feb 14, 2017 at 10:07:47AM -0800, Dmitry Torokhov wrote: > > At first glance, this patch and the next look like nice improvements. > > I don't futz around with sysfs code very often, and so may I ask how > > or whether you tested it? > > I used the hack below. OK, thats fine. I'll be

Re: [PATCH 3/4] ptp: use is_visible method to hide unused attributes

On Mon, Feb 13, 2017 at 07:51:07PM -0800, Dmitry Torokhov wrote: > Instead of creating selected attributes after the device is created (and > after userspace potentially seen uevent), lets use attribute group > is_visible() method to control which attributes are shown. This will allow > us to

Re: [PATCH 2/4] ptp: use kcalloc/kmallco_array when allocating arrays

On Mon, Feb 13, 2017 at 07:51:06PM -0800, Dmitry Torokhov wrote: > @@ -269,13 +269,13 @@ static int ptp_populate_pins(struct ptp_clock *ptp) > struct ptp_clock_info *info = ptp->info; > int err = -ENOMEM, i, n_pins = info->n_pins; > > - ptp->pin_dev_attr = kzalloc(n_pins *

Re: [PATCH 1/4] ptp: do not explicitly set drvdata in ptp_clock_register()

Dmitry, Be sure to put davem onto CC next time, as he merges any PTP work. On Mon, Feb 13, 2017 at 07:51:05PM -0800, Dmitry Torokhov wrote: > We do not need explicitly call dev_set_drvdata(), as it is done for us by > device_create(). Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [PATCH v2 0/4] PTP attribute handling cleanup

On Wed, Feb 15, 2017 at 12:22:15PM -0500, David Miller wrote: > Richard, please review. Ok, I am testing this today or tomorrow. I'll report back as soon as I can. Thanks, Richard

Re: [PATCH v2 0/4] PTP attribute handling cleanup

etions(-) Nice reduction in sysfs code! I gave this some light testing on the coldfire/phyter (which has 12 pins), and nothing exploded. For the series: Acked-by: Richard Cochran <richardcoch...@gmail.com>

Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure

On Mon, Jan 23, 2017 at 11:19:17AM -0200, Marcelo Tosatti wrote: > This is needed to generate the PTP_SYS_OFFSET data: a table with read > from realtime clock, read from device clock, read from realtime clock, > ... : > > time -> > device clock | |sample2| |sample4| |sample6|

Re: [PATCH] ptp: ixp46x: remove NO_IRQ handling

it's better to return a proper failure > code for consistency, and we should remove NO_IRQ from the kernel > entirely. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Richard Cochran <richardcoch...@gmail.com>

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