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 one
>
> 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.
a
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
'st
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 ord
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 -EGAIN
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 change
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.
>
> R
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, mu
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 ma
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.
>
> Th
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!
Than
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 inse
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, that
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 f
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 struc
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 D
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 optional_qualifie
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
> ---
> drivers
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: i2c-mu
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(-)
--- a/arch/x86/
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 n
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 chan
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
---
arch/
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 out
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 o
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 thu
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 b/sound/soc/sa
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 inser
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 di
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
---
sound/soc/samsung
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 1006
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 b/sound/soc/samsung/Kconfi
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 ad
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 the
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 100
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 nee
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:)
> ---
> drivers/iio/i
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()) {
> - smdk.num_li
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()
>> -|| machine_is_smdkv210()
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 unconditio
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 (machine_is_smd
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 fo
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 wrot
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 w
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 w
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
cloc
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= LONG_MAX
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 de
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 NTP
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 used
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 w
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 cre
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
->min_delt
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 cause
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 s
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 ->min_delta_ticks_a
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 define
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 ->min_de
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
cloc
Being of type unsigned long, the struct clock_event_device's ->retries
member is incremented in clockevents_program_min_delta() and used for
diagnostic purposes in /proc/timer_list only.
Turning ->retries' type into unsigned int avoids the introduction of
some padding with future reorderings of st
Upon adjustments of the monotonic clock's frequencies from the
timekeeping core, the clockevents devices' ->mult_adjusted should be
changed accordingly, too.
Introduce clockevents_adjust_all_freqs() which traverses all registered
clockevent devices and, if the CLOCK_EVT_FEAT_NO_ADJUST flag is not
Benchmarks have shown that clockevents_adjust_all_freqs() is memory bound.
The members of struct clock_event_device accessed therein, namely
->features, ->mult_adjusted, ->shift, ->mult and ->list are split across
two cachelines.
In what follows, a cacheline size of 64 bytes will be assumed.
I.)
Before converting the given delta from ns to cycles by means of the
mult/shift pair, clockevents_program_event() enforces it to be less or
equal than ->max_delta_ns. Simplified, this reads as
delta = min(delta, dev->max_delta_ns);
clc = (delta * dev->mult) >> dev->shift;
A device's ->max_delt
In order to avoid races between setting a struct clock_event_device's
->mult_adjusted in clockevents_update_freq() and yet to be implemented
updates triggered from the timekeeping core, the setting of ->mult and
->mult_adjusted should be made atomic.
Protect the update in clockevents_update_freq()
With NOHZ_FULL and one single well-isolated, CPU consumptive task, one
would expect approximately one clockevent interrupt per second. However, on
my Intel Haswell where the monotonic clock is the TSC monotonic clock and
the clockevent device is the TSC deadline device, it turns out that every
seco
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
clockevents_adjust_all_freqs() iterates over all devices in the
clockevent_devices list and adjusts frequencies as appropriate, skipping
over those that have either of CLOCK_EVT_FEAT_DUMMY and
CLOCK_EVT_FEAT_NO_ADJUST set or aren't oneshot capable.
This results in unnecessary memory accesses to th
Hi Boris,
2016-11-19 17:30 GMT+09:00 Boris Brezillon :
> Hi Masahiro,
>
> On Wed, 9 Nov 2016 13:35:19 +0900
> Masahiro Yamada wrote:
>
>> I am tackling on this driver to use it for my SoCs.
>> The difficulty is a bunch of platform specific stuff
>> (more specifically, Intel MRST specific) is ha
>
> 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 c
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 tile's timer clockevent device is initialized as follows:
evt->max_delta_ns = clockevent_delta2ns(MAX_TICK, evt);
and
On 11/19/2016 01:20 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.34 release.
There are 37 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be ma
On 11/19/2016 01:22 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.8.10 release.
There are 49 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be ma
On Fri, Oct 28, 2016 at 12:33:44AM +0200, Clemens Gruber wrote:
> Document the devicetree bindings for the Microchip MCP3021/3221.
>
> Signed-off-by: Clemens Gruber
> Acked-by: Rob Herring
Applied to -next.
Guenter
On Wed, Nov 09, 2016 at 06:16:14PM +0100, Clemens Gruber wrote:
> Replace S_IRUGO with the better readable 0444.
> This fixes a checkpatch warning.
>
> Signed-off-by: Clemens Gruber
Applied to -next.
Guenter
> ---
> drivers/hwmon/mcp3021.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
On Thu, Jul 28, 2016 at 8:53 PM, Mario Limonciello
wrote:
> The Dell Rugged 7202 has 3 programmable buttons (labeled P1, P2, P3)
> and a detachable keyboard/mouse dock.
>
> Signed-off-by: Mario Limonciello
There was a long discussion in the past. Just to get it clear. Are we
all okay with versio
dma_pool_alloc does not initialize the value of the newly allocated
block for the v_lli, and the uninitilize value make the tests failed
which is on pine64 with dmatest.
we can fix it just change the "|=" to "=" for the v_lli->cfg.
Signed-off-by: Hao Zhang
---
v1: https://www.spinics.net/lists/ar
Make suggested checkpatch modification for
CHECK: spaces preferred around that '|'
Signed-off-by: Walt Feasel
---
v3 makes changes to correct for email format patch submission
drivers/staging/dgnc/dgnc_tty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dgnc
Make modifications to comment style
Signed-off-by: Walt Feasel
---
v3 makes changes to correct for email format patch submission
drivers/staging/dgnc/dgnc_tty.c | 229 +++-
1 file changed, 86 insertions(+), 143 deletions(-)
diff --git a/drivers/staging/dgnc/
Linux kernel coding style modifications for dgnc_tty.c to include:
Space perferred around
Align on parenthesis
Comment style modifications
Spelling corrections
Walt Feasel (4):
staging: dgnc: dgnc_tty.c Space preferred around
staging: dgnc: dgnc_tty.c Align on parenthesis
staging: dgnc: dgn
Make suggested checkpatch modification for
CHECK: Alignment should match open parenthesis
Signed-off-by: Walt Feasel
---
v3 makes changes to correct for email format patch submission
drivers/staging/dgnc/dgnc_tty.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a
Make spelling corrections for 'transitions' and 'satisfy'
Signed-off-by: Walt Feasel
---
v2 resubmitted without behaviour
v3 makes changes to correct for email format patch submission
drivers/staging/dgnc/dgnc_tty.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/d
On Sat, 2016-11-19 at 12:56 +, Jonathan Cameron wrote:
> 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
101 - 200 of 323 matches
Mail list logo
