4.8-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Gospodarek
[ Upstream commit fcdefccac976ee51dd6071832b842d8fb41c479c ]
Current bgmac code initializes some DMA settings in the receive control
register for some hardware and then
4.8-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Borkmann
[ Upstream commit 483bed2b0ddd12ec33fc9407e0c6e1088e77a97c ]
Commit a6ed3ea65d98 ("bpf: restore behavior of bpf_map_update_elem")
added an extra per-cpu reserve to the hash
4.8-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 990ff4d84408fc55942ca6644f67e361737b3d8e ]
While fuzzing kernel with syzkaller, Andrey reported a nasty crash
in inet6_bind() caused by DCCP lacking a required
4.8-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 346da62cc186c4b4b1ac59f87f4482b47a047388 ]
Andrey reported following warning while fuzzing with syzkaller
WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83
4.8-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 6706a97fec963d6cb3f7fc2978ec1427b4651214 ]
dccp_v4_err() does not use pskb_may_pull() and might access garbage.
We only need 4 bytes at the beginning of the
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit 0096ac9f47b1a2e851b3165d44065d18e5f13d58 ]
Report the exact number of bytes which have not been successfully
copied when an exception occurs, using the
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit 614da3d9685b67917cab48c8452fd8bf93de0867 ]
All of __ret{,l}_mone{_asi,_fp,_asi_fpu} are now unused.
Signed-off-by: David S. Miller
Signed-off-by: Greg
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit 0fd0ff01d4c3c01e7fe69b762ee1a13236639acc ]
Now that all of the user copy routines are converted to return
accurate residual lengths when an exception
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit a74ad5e660a9ee1d071665e7e8ad822784a2dc7f ]
When the vmalloc area gets fragmented, and because the firmware
mapping area sits between where modules live and
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit e93704e4464fdc191f73fce35129c18de2ebf95d ]
Report the exact number of bytes which have not been successfully
copied when an exception occurs, using the
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Stephen Suryaputra Lin
[ Upstream commit 969447f226b451c453ddc83cac6144eaeac6f2e3 ]
In v2.6, ip_rt_redirect() calls arp_bind_neighbour() which returns 0
and then the state of the neigh for
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 1aa9d1a0e7eefcc61696e147d123453fc0016005 ]
dccp_v6_err() does not use pskb_may_pull() and might access garbage.
We only need 4 bytes at the beginning of the
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit b429ae4d5b565a71dfffd759dfcd4f6c093ced94 ]
When we copy code over to patch another piece of code, we can only use
PC-relative branches that target code
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Kravetz
[ Upstream commit af1b1a9b36b8f9d583d4b4f90dd8946ed0cd4bd0 ]
do_sparc64_fault() calculates both the base and huge page RSS sizes and
uses this information in calls to tsb_grow().
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit 849c498766060a16aad5b0e0d03206726e7d2fa4 ]
If the number of pages we are flushing is more than twice the number
of entries in the TSB, just scan the TSB
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: James Clarke
[ Upstream commit 9d9fa230206a3aea6ef451646c97122f04777983 ]
Additionally, if the offset will overflow the immediate for a ba,pt
instruction, fall back on a standard ba to get an
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Gospodarek
[ Upstream commit fcdefccac976ee51dd6071832b842d8fb41c479c ]
Current bgmac code initializes some DMA settings in the receive control
register for some hardware and then
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 6706a97fec963d6cb3f7fc2978ec1427b4651214 ]
dccp_v4_err() does not use pskb_may_pull() and might access garbage.
We only need 4 bytes at the beginning of the
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Florian Westphal
[ Upstream commit ce6dd23329b1ee6a794acf5f7e40f8e89b8317ee ]
If a congestion control module doesn't provide .undo_cwnd function,
tcp_undo_cwnd_reduction() will set cwnd to
Declare the structure mmu_notifier_ops as const as it is only stored in
the ops field of a mmu_notifier structure. The ops field is of type
const struct mmu_notifier_ops *, so mmu_notifier_ops structures having
this property can be declared as const.
Done using coccinelle:
@r1 disable
Colin King writes:
> From: Colin Ian King
>
> There is a missing whitespace in the dev_err message between
> "will" and "lead". Add the whitespace.
>
> Signed-off-by: Colin Ian King
Acked-by: Robert Jarzmik
Cheers.
--
Robert
Hi Dave,
[Best to CC me when I'm mentioned in the discussion. I only caught
this by chance.]
On 18 November 2016 at 23:17, Dave Chinner wrote:
> On Fri, Nov 18, 2016 at 09:48:21PM +, David Howells wrote:
>> Dave Chinner wrote:
>>
>> > > Btw, can you point me at the manpage that defines the
Hi Linus:
This push fixes the following issues:
- Compiler warning in caam driver that was the last one remaining.
- Do not register aes-xts in caam drivers on unsupported platforms.
- Regression in algif_hash interface that may lead to an oops.
Please pull from
From: Borislav Petkov
So adding thresholding_en et al was a good thing for removing the
per-CPU thresholding callback, i.e., threshold_cpu_callback.
But, in order for it to work and especially that test in
mce_threshold_create_device() so that all thresholding banks get
properly created and not
On Fri, Nov 18, 2016 at 04:54:42PM -0800, Lance Roy wrote:
> On Fri, 18 Nov 2016 15:13:45 -0800
> "Paul E. McKenney" wrote:
> > On Fri, Nov 18, 2016 at 12:33:00PM -0800, Lance Roy wrote:
> > > The trouble is that disabling preemption is not enough to ensure that
> > > there
> > > is at most
>
> On Fri, Nov 18, 2016 at 07:30:25PM +, Winkler, Tomas wrote:
> >
> > >
> > > On Thu, Nov 17, 2016 at 04:22:24PM +, Winkler, Tomas wrote:
> > > > > Just make a new function mei_cldev_recv_async() and then call a
> > > > > local, static function, that does the work with the correct flag
this is odd, I found a bug related to nouveau (modprobe/bind doesn't
return), but that isn't related to your issue at all or maybe it is
exactly this, cause the binding of the device doesn't return and
depending on the kind of driver, it would hang the system... yeah,
maybe it is the same issue.
Commit a98461d79ba5 ("staging: iio: ad9832: add DVDD regulator") and
commit 43a07e48af44 ("staging: iio: ad9832: clean-up regulator 'reg'") add
some dereference of 'st' which is an un-initialized pointer at this point.
Re-order code and tweak error handling in order to allocate memory and have
On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
> On 2016-11-07 22:47, Luis R. Rodriguez wrote:
> > If so
> > why? If this issue is present also on systems that only use ACPI is
> > this possibly due to an ACPI firmware bug or the lack of some semantics
> > in ACPI to express
From: Alexander Usyskin
Enable non-blocking receive for drivers on mei bus, this allows checking
for data availability by mei client drivers. This is most effective for
fixed address clients, that lacks flow control.
This function adds new API function mei_cldev_recv_nonblock(), it
retuns
On 18/11/16 22:28, David Lechner wrote:
> This adds a new driver for TI ADS79XX ADC chips. These communicate using
> SPI and come in 8/10/12-bit and 4/8/12/16 channel varieties.
>
> Signed-off-by: David Lechner
Hi David,
Nice domain name btw ;)
Anyhow pretty good. Various style comments and a
On 19/11/16 11:08, Christophe JAILLET wrote:
> Commit a98461d79ba5 ("staging: iio: ad9832: add DVDD regulator") and
> commit 43a07e48af44 ("staging: iio: ad9832: clean-up regulator 'reg'") add
> some dereference of 'st' which is an un-initialized pointer at this point.
>
> Re-order code and tweak
Lee Jones writes:
> On Wed, 26 Oct 2016, Robert Jarzmik wrote:
>> +config MFD_WM97xx
>> +tristate "Wolfson Microelectronics WM97xx"
>> +select MFD_CORE
>> +select REGMAP_AC97
>> +select AC97_BUS_COMPAT if AC97_BUS_NEW
>> +help
>> +
>
> Surplus '\n' here.
Right, for v2.
>> +
On 16/11/16 15:15, Rob Herring wrote:
> On Tue, Nov 15, 2016 at 04:30:56PM +0100, Fabrice Gasnier wrote:
>> This patch adds documentation of device tree bindings for the STM32 ADC.
>>
>> Signed-off-by: Fabrice Gasnier
>> ---
>> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 83
>>
On Sat, Nov 19, 2016 at 07:14:08AM +, Reshetova, Elena wrote:
> > Well, if you get to tools (cocci script or whatever) to reliably work
> > fork atomic_t, then converting the few atomic_long_t's later should be
> > trivial.
>
> I am using coccinelle to find all occurrences, but I do the
On Sat, Nov 19, 2016 at 12:08:34PM +0100, Christophe JAILLET wrote:
> Commit a98461d79ba5 ("staging: iio: ad9832: add DVDD regulator") and
> commit 43a07e48af44 ("staging: iio: ad9832: clean-up regulator 'reg'") add
> some dereference of 'st' which is an un-initialized pointer at this point.
>
>
On Fri, Nov 18, 2016 at 02:34:07PM -0500, David Miller wrote:
> From: Babu Moger
> Date: Tue, 27 Sep 2016 12:33:26 -0700
>
> > These patches limit the static allocations for lockdep data structures
> > used for debugging locking correctness. For sparc, all the kernel's code,
> > data, and bss,
On 15/11/16 15:30, Fabrice Gasnier wrote:
> Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
> Converter). STM32 ADC can be composed of up to 3 ADCs with shared
> resources like clock prescaler, common interrupt line and analog
> reference voltage.
> This core driver basically
On Sat, Nov 19, 2016 at 02:16:11PM +0200, Tomas Winkler wrote:
> From: Alexander Usyskin
>
> Enable non-blocking receive for drivers on mei bus, this allows checking
> for data availability by mei client drivers. This is most effective for
> fixed address clients, that lacks flow control.
>
>
On 15/11/16 15:30, Fabrice Gasnier wrote:
> This patch adds support for STMicroelectronics STM32 MCU's analog to
> digital converter.
>
> Signed-off-by: Fabrice Gasnier
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Very nice driver!
On 15/11/16 15:30, Fabrice Gasnier wrote:
> Signed-off-by: Fabrice Gasnier
The driver is now on it's way in. I'm assuming this and the two device tree
patches
will go via the relevant route to arm-soc.
Thanks,
Jonathan
> ---
> arch/arm/configs/stm32_defconfig | 3 +++
> 1 file changed, 3
On 14/11/16 23:12, Linus Walleij wrote:
> On Mon, Nov 14, 2016 at 7:53 PM, Lars-Peter Clausen wrote:
>
>> It's about figuring out the setting of a "GPIO" that can't be changed from
>> software.
>>
>> Devices sometimes, instead of a configuration bus like I2C or SPI, use
>> simple input pins,
Hi friend I am a banker in ADB BANK. I want to transfer an abandoned
$25.5Million to your Bank account. 40/percent will be your share.
No risks involved but keep it as secret. Contact me for more details
And also acknowledge receipt of this message in acceptance of my
mutual business Endeavour by
On 16/11/16 09:43, Ooi, Joyce wrote:
> There are 2 usage types (Magnetic Flux and Heading data field) for HID
> compass sensor, thus the values of offset, scale, and sensitivity should
> be separated according to their respective usage type. The changes made
> are as below:
> 1. Hysteresis: A
Signed-off-by: Martin Kaiser
---
drivers/rtc/rtc-imxdi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index 8d8049bd..67b56b8 100644
--- a/drivers/rtc/rtc-imxdi.c
+++ b/drivers/rtc/rtc-imxdi.c
@@ -67,7 +67,7 @@
#define
The DryIce chipset has a dedicated security violation interrupt that is
triggered for security violations (if configured to do so). According to
the publicly available imx258 reference manual, irq 56 is used for this
interrupt.
Install a handler for the security violation interrupt. Move the code
Declare the structure xfs_item_ops as const as it is only passed as an
argument to the function xfs_log_item_init. As this argument is of type
const struct xfs_item_ops *, so xfs_item_ops structures having this
property can be declared as const.
Done using Coccinelle:
@r1 disable
On Fri, Nov 18, 2016 at 06:57:18PM +0100, Sergio Paracuellos wrote:
> Remove incorrect __iomem annotation.
>
> This patch fix the following sparse warnings in slicoss driver:
> warning: incorrect type in assignment (different address spaces)
>
> Signed-off-by: Sergio Paracuellos
> ---
>
From: Alex Hemme
Deselect functionality can be ignored for device-trees with
"i2c-mux-idle-disconnect" entries if no platform_data is available.
By enabling the deselect functionality outside the platform_data
block the logic works as it did in previous kernels.
Fixes: 7fcac9807175 ("i2c:
The art detection uses rdmsrl_safe() to detect the availablity of the
TSC_ADJUST MSR.
That's pointless because we have a feature bit for this. Use it.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/tsc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
---
When entering idle, it's a good oportunity to verify that the TSC_ADJUST
MSR has not been tampered with (BIOS hiding SMM cycles). If tampering is
detected, emit a warning and restore it to the previous value.
This is especially important for machines, which mark the TSC reliable
because there is
Cleaning up the stop marker on the control CPU is wrong when we want to add
retry support. Move the cleanup to the starting CPU.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/tsc_sync.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/kernel/tsc_sync.c
+++
To allow TSC compensation cross nodes its necessary to know in which
direction the TSC warp was observed. Return the maximum observed value on
the calling CPU so the caller can determine the direction later.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/tsc_sync.c |6 --
1 file
If the first CPU of a package comes online, it is necessary to test whether
the TSC is in sync with a CPU on some other package. When a deviation is
observed (time going backward between the two CPUs) the TSC is marked
unstable, which is a problem on large machines as they have to fall back to
the
If the TSC_ADJUST MSR is available all CPUs in a package are forced to the
same value. So TSCs cannot be out of sync when the first CPU in the package
was in sync.
That allows to skip the sync test for all CPUs except the first starting
CPU in a package.
Signed-off-by: Thomas Gleixner
---
The TSC_ADJUST MSR shows whether the TSC has been modified. This is helpful
in a two aspects:
1) It allows to detect BIOS wreckage, where SMM code tries to 'hide' the
cycles spent by storing the TSC value at SMM entry and restoring it at
SMM exit. On affected machines the TSCs run slowly
The TSC_ADJUST MSR shows whether the TSC has been modified. This is helpful
in two aspects:
1) It allows to detect BIOS wreckage, where SMM code tries to 'hide' the
cycles spent by storing the TSC value at SMM entry and restoring it at
SMM exit. On affected machines the TSCs run slowly out
If time warps can be observed then they should only ever be observed on one
CPU. If they are observed on both CPUs then the system is completely hosed.
Add a check for this condition and notify if it happens.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/tsc_sync.c | 13 -
1
On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote:
> For now we are interesting in improving the synopsys QoS driver under
> /nect/ethernet/synopsys. For now the driver structure consists of a single
> file
> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
Jérôme Glisse writes:
> This patch add a new memory migration helpers, which migrate memory
> backing a range of virtual address of a process to different memory
> (which can be allocated through special allocator). It differs from
> numa migration by working on a range of virtual address and
Hi,
Few patches removing dead code (machines not supported).
The third patch ([RFT 3/6] ASoC: samsung: smdk_wm8580: Remove machine
specific quirks) requires testing. I hope I understood the code
correctly.
The last ARM patch is independent. I will take it through samsung-soc
tree. I put it here
MACH_SMDKC100, MACH_SMDKV210 and MACH_SMDKC110 are no longer supported
so drop the dead code.
Signed-off-by: Krzysztof Kozlowski
---
sound/soc/samsung/smdk_wm8580.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/sound/soc/samsung/smdk_wm8580.c
MACH_SMDKC100 was removed in commit b8529ec1c1b0 ("ARM: S5PC100: no more
support S5PC100 SoC"). MACH_SMDKV210 and MACH_SMDKC110 in commit
28c8331d386 ("ARM: S5PV210: Remove support for board files").
Signed-off-by: Krzysztof Kozlowski
---
sound/soc/samsung/Kconfig | 2 +-
1 file changed, 1
The driver no longer differentiates between machines (S3C24xx machines
are not supported by it) so there is no need to override I2S device id
in cpu_dai_name.
Signed-off-by: Krzysztof Kozlowski
---
Not tested. The driver did not override .platform_name which looks
suspicious to me. However I
Instead of build time, Samsung ASoC drivers have rather runtime
dependency on Exynos or other Samsung platforms. For building they
require Common Clock Framework. If it is provided they could be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski
---
Remove non-existing MACH symbols from S5PV210 defconfig.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/configs/s5pv210_defconfig | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/configs/s5pv210_defconfig
b/arch/arm/configs/s5pv210_defconfig
index fa989902236d..c51f0f02012b
The I2S sound drivers for SmartQ board and WM8580 codec can be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski
---
sound/soc/samsung/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig
John Hubbard writes:
> On Fri, 18 Nov 2016, Jérôme Glisse wrote:
>
>> Cliff note: HMM offers 2 things (each standing on its own). First
>> it allows to use device memory transparently inside any process
>> without any modifications to process program code. Second it allows
>> to mirror process
Root in a user ns cannot be trusted to write a traditional
security.capability xattr. If it were allowed to do so, then any
unprivileged user on the host could map his own uid to root in a
namespace, write the xattr, and execute the file with privilege on the
host.
This patch introduces v3 of
On 18/11/16 16:59, Peter Rosin wrote:
> On 2016-11-18 16:35, Rob Herring wrote:
>> On Thu, Nov 17, 2016 at 10:48:03PM +0100, Peter Rosin wrote:
>>> ---
>>> .../devicetree/bindings/misc/mux-gpio.txt | 79
>>> ++
>>> 1 file changed, 79 insertions(+)
>>> create mode
From: Alexey Khoroshilov
Date: Sat, 19 Nov 2016 01:40:10 +0300
> at91ether_start_xmit() does not check for dma mapping errors.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Applied, thanks.
On 17/11/16 21:48, Peter Rosin wrote:
> When both the iio subsystem and the i2c subsystem wants to update
> the same mux, there needs to be some coordination. Invent a new
> minimal "mux" subsystem that handles this.
I'd probably put something more general in the description. Lots of things
may
On 17/11/16 21:48, Peter Rosin wrote:
> Extend the inkern api with functions for reading and writing ext_info
> of iio channels.
I'd like Lars' feedback on this one.
Superficially looks fine to me but I am not as familiar with this interface
as Lars is ;) (he wrote it IIRC:)
> ---
>
From: Geliang Tang
Date: Fri, 18 Nov 2016 22:21:17 +0800
> Drop duplicate header scatterlist.h from iommu_common.h.
>
> Signed-off-by: Geliang Tang
Applied, thanks.
On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote:
[...]
> @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void)
> int ret;
> char *str;
>
> - if (machine_is_smdkc100()
> - || machine_is_smdkv210() || machine_is_smdkc110()) {
> -
On 11/19/2016 04:42 PM, Lars-Peter Clausen wrote:
> On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote:
> [...]
>> @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void)
>> int ret;
>> char *str;
>>
>> -if (machine_is_smdkc100()
>> -||
From: Vijay Kumar
Date: Fri, 11 Nov 2016 10:11:57 -0800
> @@ -1444,8 +1444,12 @@ void smp_send_stop(void)
> int cpu;
>
> if (tlb_type == hypervisor) {
> + int this_cpu = smp_processor_id();
> +
> + sunhv_migrate_hvcons_irq(this_cpu);
> +
You can't
On 11/19/2016 04:45 PM, Lars-Peter Clausen wrote:
> On 11/19/2016 04:42 PM, Lars-Peter Clausen wrote:
>> On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote:
>> [...]
>>> @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void)
>>> int ret;
>>> char *str;
>>>
>>> - if
On 17/11/16 21:48, Peter Rosin wrote:
> When a multiplexer changes how an iio device behaves (for example
> by feeding different signals to an ADC), this driver can be used
> create one virtual iio channel for each multiplexer state.
>
> Depends on the generic multiplexer driver.
I'm not really
2016-11-18 18:46 GMT+01:00 Josh Poimboeuf :
> NMI stack dumps are bracked by the following tags:
>
>
> ...
>
>
> The ending tag is kind of confusing if you don't already know what "EOE"
> means (end of exception). The same ending tag is also used to mark the
> end of all other exceptions'
Goal: avoid programming ced devices too early for large deltas, for
details, c.f. the description of [23/28].
Previous v7 can be found at [1].
While the runtimes looked Ok for x86, you were concerned about
outliers on ARM:
Thomas Gleixner writes:
> On Wed, 21 Sep 2016, Nicolai Stange
With the upcoming NTP correction related rate adjustments to be implemented
in the clockevents core, the latter needs to get informed about every rate
change of a clockevent device made after its registration.
Currently, sh_tmu violates this requirement in that it registers its
clockevent device
With the upcoming NTP correction related rate adjustments to be implemented
in the clockevents core, the latter needs to get informed about every rate
change of a clockevent device made after its registration.
Currently, em_sti violates this requirement in that it registers its
clockevent device
With the yet to come introduction of NTP correction awareness to the
clockevent core, drivers should report their valid ranges in units of
cycles to the latter.
Currently, the x86's uv rtc clockevent device is initialized as follows:
clock_event_device_uv.min_delta_ns = NSEC_PER_SEC /
A clockevent device's rate should be configured before or at registration
and changed afterwards through clockevents_update_freq() only.
For the configuration at registration, we already have
clockevents_config_and_register().
Right now, there are no clockevents_config() users outside of the
With the yet to come introduction of NTP correction awareness to the
clockevent core, drivers should report their valid ranges in units of
cycles to the latter.
Currently, the s390's CPU timer clockevent device is initialized as
follows:
cd->min_delta_ns= 1;
cd->max_delta_ns=
With the upcoming NTP correction related rate adjustments to be implemented
in the clockevents core, the latter needs to get informed about every rate
change of a clockevent device made after its registration.
Currently, h8300_timer8 violates this requirement in that it registers its
clockevent
Now that all clockevent drivers set ->min_delta_ticks and ->max_delta_ticks
independently of whether they use clockevents_config*() or not, the
clockevent core can calculate ->min_delta_ns and ->max_delta_ns from these
unconditionally.
The goal is to prepare the clockevent core for introducing
The struct clock_event_device has got the ->min_delta_ns, ->max_delta_ns,
->min_delta_ticks and ->max_delta_ticks members for setting the bounds
of valid deltas to be programmed.
During operation, the clockevent core uses the ->*_delta_ns versions only.
OTOH, the ->*_delta_ticks are currently
Currently, the em_sti driver prepares and enables the needed clock in
em_sti_enable(), potentially called through its clockevent device's
->set_state_oneshot().
However, the clk_prepare() step may sleep whereas tick_program_event() and
thus, ->set_state_oneshot(), can be called in atomic context.
With the upcoming NTP correction related rate adjustments to be implemented
in the clockevents core, the latter needs to get informed about every rate
change of a clockevent device made after its registration.
Currently, sh_cmt violates this requirement in that it registers its
clockevent device
Now that the clockevent core always initializes the ->*_delta_ns values
from their ->_delta_ticks counterparts, there is no point in having the
clockevent devices' drivers doing so as well.
Don't initialize ->min_delta_ns and ->max_delta_ns from the clockevent
devices' drivers.
This patch was
The use of a clockevent device's ->min_delta_ns in the event programming
path hinders upcoming changes to the clockevent core making it NTP
correction aware: both, ->mult and ->min_delta_ns would need to get
updated as well as consumed atomically and we'd rather like to avoid any
locking here.
We
print_tickdevice(), assembling the per-tick device sections in
/proc/timer_list, is the last user of struct clock_event_device's
->min_delta_ns member.
In order to make this one fully obsolete while retaining userspace ABI,
calculate the displayed value of 'min_delta_ns' on the fly from
Upcoming changes to the clockevent core will make it adjusting a clockevent
device's mult/shift pair in order to compensate for NTP corrections made
by the timekeeping core.
For certain devices this behaviour is unwanted. Introduce the
CLOCK_EVT_FEAT_NO_ADJUST flag that, when being set, will
While being of type unsigned long right now, the ->min_delta_ticks and
->min_delta_ticks_adjusted members of struct clock_event_device aren't
expected to ever overflow an unsigned int.
The latter sits in the first cacheline. For the case of
sizeof(long) > sizeof(int), this is a waste of precious
The struct clock_event_device's ->min_delta_ns member isn't used anymore.
Purge it.
In __clockevents_update_bounds(), shortcut the
->min_delta_ticks => ->min_delta_ns => ->min_delta_ticks_adjusted
calculation detour -- it had been made solely for the purpose of ensuring
that
Right now, the members ->state_use_accessors and ->features of
struct clock_event_device occupy an int each which is way more than needed:
the former can only take one of the five different values from
enum clock_event_state while the latter is a bitmask with the highest
CLOCK_EVT_FEAT_* bit
Before converting the given delta from ns to cycles by means of the
mult/shift pair, clockevents_program_event() enforces it to be greater or
equal than ->max_delta_ns. Simplified, this reads as
delta = max(delta, dev->min_delta_ns);
clc = (delta * dev->mult) >> dev->shift;
Note that
Currently, clockevents_program_min_delta() sets a clockevent device's
->next_event to the point in time where the minimum delta would actually
expire:
delta = dev->min_delta_ns;
dev->next_event = ktime_add_ns(ktime_get(), delta);
For your reference, this is so since the initial advent of
401 - 500 of 646 matches
Mail list logo
