Fix following DTC warnings in S5Pv210 boards:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
no unit name
Warning (unit_address_vs_reg): Node /soc/fimd@f800/display-timings/timing@0
has a unit name, but no reg property
Signed-off-by: Krzysztof Kozlowski
---
Fix following DTC warnings in all Exynos542x/5800 boards:
Warning (unit_address_vs_reg): Node /video-phy@10040728 has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /video-phy@10040714 has a unit name, but no
reg property
Warning (unit_address_vs_reg): Node /usb@1200 ha
Fix following DTC warnings in Exynos5420 SMDK5420:
Warning (unit_address_vs_reg): Node
/dp-controller@145B/display-timings/timing@0 has a unit name, but no reg
property
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 +-
1 file changed, 1 insertion(+),
Fix following DTC warnings in all Exynos4 boards:
Warning (unit_address_vs_reg): Node /soc/video-phy@10020710 has a unit name,
but no reg property
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/
Fix following DTC warnings in Exynos5440 boards:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
no unit name
Warning (unit_address_vs_reg): Node /pinctrl has a reg or ranges property, but
no unit name
Warning (unit_address_vs_reg): Node /rtc has a reg or ranges pro
Fix following DTC warnings in all Exynos5250 boards:
Warning (unit_address_vs_reg): Node
/dp-controller@145B/display-timings/timing@0 has a unit name, but no reg
property
Warning (unit_address_vs_reg): Node /usb@1200 has a unit name, but no reg
property
Warning (unit_address_vs_reg): No
Fix following DTC warnings in Exynos4x12 boards:
Warning (unit_address_vs_reg): Node /camera/fimc-is@1200/pmu has a reg or
ranges property, but no unit name
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Patches 1 to 12 in this series were accepted by Eduardo.
Patches 13 and 14 need to go via platform or dt tree.
Used get_maintainer.pl to get maintainers and open list, add them in To: and Cc:
list.
To:
Rob Herring
Pawel Moll
Mark Rutland
Ian Campbell
Kumar Gala
Cc:
devicet...@vger.kernel.or
On Thu, Mar 31, 2016 at 10:53:02AM -0700, bseg...@google.com wrote:
> Yuyang Du writes:
>
> > The increased load resolution (fixed point arithmetic range) is
> > unconditionally deactivated with #if 0, so it is effectively broken.
> >
> > But the increased load range is still used somewhere (e.g.
To:
Rob Herring
Pawel Moll
Mark Rutland
Ian Campbell
Kumar Gala
Cc:
devicet...@vger.kernel.org
On 2016年03月29日 23:17, Eduardo Valentin wrote:
> On Tue, Mar 29, 2016 at 06:29:24PM +0800, Wei Ni wrote:
>> Set general "critical" trip temperatures for cpu, gpu, mem and pllx
>> thermal zones for a
This patch series is to fix the problems below and recently debugged
in this mailing list:
o to fix a problem for the HW where the normal descriptor
o to fix the mdio registration according to the different
platform configurations
I am resending all the patches again: built on top of net.git re
Initially the phy_bus_name was added to manipulate the
driver name but it was recently just used to manage the
fixed-link and then to take some decision at run-time.
So the patch uses the is_pseudo_fixed_link and removes
the phy_bus_name variable not necessary anymore.
The driver can manage the md
This reverts commit 88f8b1bb41c6208f81b6a480244533ded7b59493.
due to problems on GeekBox and Banana Pi M1 board when
connected to a real transceiver instead of a switch via
fixed-link.
Signed-off-by: Giuseppe Cavallaro
Cc: Gabriel Fernandez
Cc: Andreas Färber
Cc: Frank Schäfer
Cc: Dinh Nguyen
This patch fixs a regression raised when test on chips that use
the normal descriptor layout. In fact, no len bits were set for
the TDES1 and no OWN bit inside the TDES0.
Signed-off-by: Giuseppe CAVALLARO
Tested-by: Andreas Färber
Cc: Fabrice Gasnier
---
drivers/net/ethernet/stmicro/stmmac/nor
* Lianwei Wang wrote:
> The wake_up_all_idle_cpus API always wake up all the online
> cpus, but sometimes we only want to wake up a set of cpus.
>
> Use a generic function to wake up a group of cpus that is
> specified by the cpumask parameter. This generic API can
> benefit to the cases that o
Fix following DTC warnings in S3C2416 and S3C6410 boards:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
no unit name
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c2416-smdk2416.dts | 2 +-
arch/arm/boot/dts/s3c6410-mini6410.dts | 2 +-
arch/arm/boo
On 03/31/2016 04:33 PM, 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.
>
> Signed-off-by: David Gstir
> Signed-
Use smp_call_sync_on_phys_cpu() to raise SMI on cpu 0.
Signed-off-by: Juergen Gross
---
drivers/firmware/dcdbas.c | 46 --
1 file changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 829ee
On some hardware models (e.g. Dell Studio 1555 laptop) some hardware
related functions (e.g. SMIs) are to be executed on physical cpu 0
only. Instead of open coding such a functionality multiple times in
the kernel add a service function for this purpose. This will enable
the possibility to take sp
Use the smp_call_sync_on_phys_cpu() function to call system management
mode on cpu 0.
Signed-off-by: Juergen Gross
---
drivers/hwmon/dell-smm-hwmon.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/d
Some hardware (e.g. Dell Studio laptops) require special functions to
be called on physical cpu 0 in order to avoid occasional hangs. When
running as dom0 under Xen this could be achieved only via special boot
parameters (vcpu pinning) limiting the hypervisor in it's scheduling
decisions.
This pat
Import the actual version of include/xen/interface/sched.h from Xen.
Signed-off-by: Juergen Gross
---
include/xen/interface/sched.h | 100 ++
1 file changed, 82 insertions(+), 18 deletions(-)
diff --git a/include/xen/interface/sched.h b/include/xen/interf
Add generic virtualization support for pinning the current vcpu to a
specified physical cpu. As this operation isn't performance critical
(a very limited set of operations like BIOS calls and SMIs is expected
to need this) just add a hypervisor specific indirection.
Such a pinning should last as s
Some hardware models (e.g. Dell Studio 1555 laptops) require calls to
the firmware to be issued on cpu 0 only. As Dom0 might have to use
these calls, add xen_pin_vcpu() to achieve this functionality.
In case either the domain doesn't have the privilege to make the
related hypercall or the hypervis
The logic of 'kvmppc_handle_loads' is same as 'kvmppc_handle_load',
but with sign extension. It sets mmio_sign_extend to 1, then calls
'kvmppc_handle_load', but in 'kvmppc_handle_load', the
mmio_sign_extend flag is reset to 0, so the data does not actually get
sign-extended.
This patch fixes the
On 01/04/16 06:49, He Kuang wrote:
> Build errors on aarch64:
>
> libperf.a(libperf-in.o): In function `convert_timestamp':
> util/jitdump.c:356: undefined reference to `tsc_to_perf_time'
> collect2: error: ld returned 1 exit status
> Makefile.perf:347: recipe for target 'perf' failed
>
Hi David, Thomas,
On Thu, 31 Mar 2016 16:47:10 -0400 David Miller wrote:
> From: Thomas Petazzoni
> Date: Thu, 31 Mar 2016 22:37:35 +0200
>
> > Hello,
> >
> > On Thu, 31 Mar 2016 15:15:47 -0400 (EDT), David Miller wrote:
> >> From: Jisheng Zhang
> >> Date: Wed, 30 Mar 2016 19:55:21 +0800
>
On 2016.03.31 02:24 Jörg Otte wrote:
> 2016-03-30 22:26 GMT+02:00 Srinivas Pandruvada wrote:
>> On Wed, 2016-03-30 at 22:12 +0200, Rafael J. Wysocki wrote:
>>> On Wed, Mar 30, 2016 at 8:58 PM, Srinivas Pandruvada wrote:
On Wed, 2016-03-30 at 11:50 -0700, Doug Smythies wrote:
... [cut]...
>>>
Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not b
When the usb gadget supporting for usb charger is ready, the usb charger
should get the type by the 'get_charger_type' callback which is implemented
by the usb gadget operations, and get the usb charger pointer from struct
'usb_gadget'.
Signed-off-by: Baolin Wang
---
drivers/usb/gadget/udc/charg
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.
Introduce a callback 'get_charger_type' which
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the
On Friday 01 April 2016 02:09 AM, Mark Brown wrote:
* PGP Signed by an unknown key
On Fri, Apr 01, 2016 at 01:18:23AM +0530, Laxman Dewangan wrote:
On Friday 01 April 2016 12:52 AM, Mark Brown wrote:
So as per above, it will be adjusted to 13.75mV/us (nearest higher side) for
device configurat
On Thu 31-03-16 10:03:31, Andrew Morton wrote:
> On Thu, 31 Mar 2016 11:20:05 +0200 Ingo Molnar wrote:
>
> > So AFAIK Andrew's tree is based on top of linux-next
>
> Not really true any more - I only base -mm patches on linux-next
> patches when they must be based that way due to some known depe
On 31/03/16 17:17, Naveen Kumar Parna wrote:
> When switching SD and SDIO cards from 3.3V to 1.8V signal level fails, a bug
> in sdhci_set_power() will trigger.
> To fix the kernel crash during recovery from signal voltage switch failure,
> OCR should be reset to avail voltage mask before power-c
On Thu, 2016-03-31 at 22:12 -0700, Andrey Vagin wrote:
> From: Andrey Vagin
>
> __vfs_write() returns a negative value in a error case.
Ha, right, I'll send this along to Andrew with my next series which
should be soon.
>
> Cc: Ian Kent
> Signed-off-by: Andrey Vagin
> ---
> fs/autofs4/waitq
On Fri, Apr 01, 2016 at 09:14:30AM +0200, Juergen Gross wrote:
> + if (cpu >= nr_cpu_ids)
> + return -EINVAL;
> + if (cpu != 0)
> + return -EINVAL;
The other functions return -ENXIO for this.
Commit-ID: d18d12d0ff07c47fb913f297c174f30a3f96042d
Gitweb: http://git.kernel.org/tip/d18d12d0ff07c47fb913f297c174f30a3f96042d
Author: Richard Cochran
AuthorDate: Thu, 31 Mar 2016 15:51:32 +0200
Committer: Ingo Molnar
CommitDate: Fri, 1 Apr 2016 08:53:49 +0200
lib/proportions: Remove u
On 01/04/16 09:37, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 09:14:30AM +0200, Juergen Gross wrote:
>> +if (cpu >= nr_cpu_ids)
>> +return -EINVAL;
>
>> +if (cpu != 0)
>> +return -EINVAL;
>
> The other functions return -ENXIO for this.
Aah, okay. Will change.
Commit-ID: f87e0434a3bedeb5e4d75d96d9f3ad424dae6b33
Gitweb: http://git.kernel.org/tip/f87e0434a3bedeb5e4d75d96d9f3ad424dae6b33
Author: Rusty Russell
AuthorDate: Fri, 1 Apr 2016 12:15:46 +1030
Committer: Ingo Molnar
CommitDate: Fri, 1 Apr 2016 08:58:13 +0200
lguest, x86/entry/32: Fix ha
Commit-ID: d7847a7017b2a2759dd5590c0cffdbdf2994918e
Gitweb: http://git.kernel.org/tip/d7847a7017b2a2759dd5590c0cffdbdf2994918e
Author: Ingo Molnar
AuthorDate: Fri, 1 Apr 2016 09:00:35 +0200
Committer: Ingo Molnar
CommitDate: Fri, 1 Apr 2016 09:03:27 +0200
x86/cpufeature: Fix build bug
On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote:
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include "smpboot.h"
>
> @@ -758,9 +759,14 @@ struct smp_sync_call_struct {
> static void smp_call_sync_callback
I proposed also to simplify the intel_pstate_calc_busy function:
core_pct = int_tofp(sample->aperf) * int_tofp(100);
core_pct = div64_u64(core_pct, int_tofp(sample->mperf));
is equivalent to:
core_pct = sample->aperf * int_tofp(100);
core_pct = div64_u64(core_pct, sample->mperf)
On Fri, Apr 01, 2016 at 12:40:27AM -0700, tip-bot for Ingo Molnar wrote:
> Commit-ID: d7847a7017b2a2759dd5590c0cffdbdf2994918e
> Gitweb: http://git.kernel.org/tip/d7847a7017b2a2759dd5590c0cffdbdf2994918e
> Author: Ingo Molnar
> AuthorDate: Fri, 1 Apr 2016 09:00:35 +0200
> Committer: Ingo
This patch adds new ports-implemented mask, which is required to get
achi working on the mainline. Without this patch value read from
PORTS_IMPL register which is zero would not enable any ports for
software to use.
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Andy Gross
---
arch/arm/boot/dt
On some SOCs PORTS_IMPL register value is never programmed by the
firmware and left at zero value. Which means that no sata ports are
available for software. AHCI driver used to cope up with this by
fabricating the port_map if the PORTS_IMPL register is read zero,
but recent patch broke this workar
In usecases where force_port_map is used saved_port_map is never set,
resulting in not programming the PORTS_IMPL register as part of initial
config. This patch fixes this by setting it to port_map even in case
where force_port_map is used, making it more inline with other parts of
the code.
Signe
Hi Tejun,
On some SOCs PORTS_IMPL register value is never programmed by the BIOS
and left at zero value. Which means that no sata ports are available for
software. AHCI driver used to cope up with this by fabricating the
port_map if the PORTS_IMPL register is read zero, but recent patch [1]
broke
On Mar 31 '16 09:24, Andreas Ziegler wrote:
> Fix a typo in the help message for the -d parameter by removing one 'm'.
>
> Signed-off-by: Andreas Ziegler
Acked-by: Valentin Rothberg
> ---
> scripts/checkkconfigsymbols.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Fri, 1 Apr 2016, Len Brown wrote:
> +/*
> + * aperfmperf_snapshot_khz()
> + * On the current CPU, snapshot APERF, MPERF, and jiffies
> + * unless we already did it within 100ms
> + * calculate kHz, save snapshot
> + */
> +static void aperfmperf_snapshot_khz(void *dummy)
> +{
> + unsigned lon
We have been reclaimed highmem zone if buffer_heads is over limit
but [1] changed the behavior so it doesn't reclaim highmem zone
although buffer_heads is over the limit.
This patch restores the logic.
As well, [2] removed classzone_idx so we don't need code related to
it. This patch cleans it up.
On Thu, 31 Mar 2016, Nishanth Menon wrote:
> Palams extcon IRQs are nested threaded and wired to the Palmas
> inerrupt controller. So, this flag is not required for nested
> irqs anymore, since commit 3c646f2c6aa9 ("genirq: Don't suspend
> nested_thread irqs over system suspend") was merged. Howev
Hi,
Grygorii Strashko writes:
> On 03/31/2016 11:04 AM, Felipe Balbi wrote:
>> "Thang Q. Nguyen" writes:
>>> [ text/plain ]
>>> Thanks Grygorii for information.
>>> I checked but do not see dma_init_dev_from_parent is used in
>>> linux-next repository. Can you give me more information for what
On Fri, Apr 01, 2016 at 12:37:00AM -0400, Len Brown wrote:
> diff --git a/arch/x86/kernel/cpu/aperfmperf.c
> b/arch/x86/kernel/cpu/aperfmperf.c
> new file mode 100644
> index 000..9380102
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/aperfmperf.c
> @@ -0,0 +1,76 @@
> +/*
> + * x86 APERF/MPERF KH
On Fri 01-04-16 17:00:58, Minchan Kim wrote:
[...]
> [2] commit 5acbd3bfc93b ("mm, oom: rework oom detection")
I didn't look a tht patch yet but wanted to note that this sha is most
probably from linux-next and won't be stable. Also this patch will most
likely see some changes in future so making
On Thu, Mar 31, 2016 at 6:21 PM, Guenter Roeck wrote:
> On Tue, Mar 29, 2016 at 11:15:49AM -0700, Guenter Roeck wrote:
>> The sa1100 gpio driver was initialized from interrupt initialization code,
>> which is earlier than the gpio subsystem is initialized. Since commit
>> ff2b13592299 ("gpio: make
Am 01.04.2016 um 01:36 schrieb Randy Dunlap:
> Please be more careful in your description...
I'm very sorry. Will do a v2 soon. ;-)
> On 03/31/16 15:33, Richard Weinberger wrote:
>> Recent happenings in the node.js community showed how fragile software is
>> when
>> it comes to dependencies of f
On 31 March 2016 at 19:20, Crestez Dan Leonard
wrote:
> Using this requires software triggers like CONFIG_IIO_HRTIMER_TRIGGER.
Then we are missing DEPENDS in Kconfig...
>
> The device can be configured to do internal periodic sampling but does
> not appear to offer some sort of interrupt on data
On Thu, Mar 31, 2016 at 5:11 PM, Guenter Roeck wrote:
> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"),
> attempts to add a gpio chip prior to gpiolib initialization cause
> the system to crash. This happens because gpio_bus_type has not been
> registered yet. Defer creating
On Fri, Apr 1, 2016 at 3:33 AM, Greg Ungerer wrote:
> On 01/04/16 10:53, Guenter Roeck wrote:
>> Probably coldfire ?
>>
>> arch/m68k/coldfire/gpio.c:
>
> Yes, that is the one.
>
>> static struct bus_type mcfgpio_subsys = {
>> .name = "gpio",
>> .dev_name = "gpio",
>>
On Fri, Apr 01, 2016 at 12:37:00AM -0400, Len Brown wrote:
> From: Len Brown
>
> For x86 processors with APERF/MPERF and TSC,
> return meaningful and consistent MHz in
> /proc/cpuinfo and
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
>
> MHz is computed like so:
>
> MHz = base_MHz * d
—
Steph
> On Apr 1, 2016, at 10:03 AM, Peter Zijlstra wrote:
>
> On Fri, Apr 01, 2016 at 12:37:00AM -0400, Len Brown wrote:
>> diff --git a/arch/x86/kernel/cpu/aperfmperf.c
>> b/arch/x86/kernel/cpu/aperfmperf.c
>> new file mode 100644
>> index 000..9380102
>> --- /dev/null
>> +++ b/arch
On 01.04.2016 15:57, Krzysztof Kozlowski wrote:
> Fix following DTC warnings in Trats2 board:
>
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
> no unit name
> Warning (unit_address_vs_reg): Node
> /i2c-gpio-1/max77693@66/regulators/ESAFEOUT1@1 has a unit name, b
> These chips has an almost identical interface but a deal with a
> different number of value bits. Datasheet links for comparison:
comments below
> * http://www.ti.com/lit/ds/symlink/adc081c021.pdf
> * http://www.ti.com/lit/ds/symlink/adc101c021.pdf
> * http://www.ti.com/lit/ds/symlink/adc1
On 1.4.2016 4:06, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> There is a system that node's pfn are overlapped like as following.
>
> -pfn>
> N0 N1 N2 N0 N1 N2
>
> Therefore, we need to care this overlapping when iterating pfn range.
>
> mark_free_pages() iterates requested zon
On 1.4.2016 4:06, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> There is a system that node's pfn are overlapped like as following.
>
> -pfn>
> N0 N1 N2 N0 N1 N2
>
> Therefore, we need to care this overlapping when iterating pfn range.
>
> There are one place in page_owner.c that
On 1.4.2016 4:06, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> There is a system that node's pfn are overlapped like as following.
>
> -pfn>
> N0 N1 N2 N0 N1 N2
>
> Therefore, we need to care this overlapping when iterating pfn range.
>
> There are two places in vmstat.c that it
This patch adds second I2S connection to rt5650 codec for capture path
on mt8173-rt5650 machine driver.
Signed-off-by: PC Liao
---
Changes since v1:
Use codec dai name to determine the capture path.
---
.../devicetree/bindings/sound/mt8173-rt5650.txt|6 +++
sound/soc/mediatek/mt8173-rt
On 30-03-16, 13:18, Rafael J. Wysocki wrote:
> It conflicts with other stuff (as you know), so I'm not sure about the
> order in which they are going to be applied, though.
Please let me know when can I rebase and resend this one. I saw that you have
moved your patches to linux-next now.
--
vire
Trim your emails
On Fri, Apr 01, 2016 at 10:16:42AM +0200, Stephane Gasparini wrote:
> > That means these delta's can be arbitrarily large, in fact the MSRs can
> > have wrapped however many times.
>
> 64 bits is 18 446 744 073 709 551 615
>
> so even assuming a 10 GHz frequency if my math are
> .wipers and .max_pos need not be in max5487_cfg, they are common.
> .wipers isn't even used. Which means that if you like, you can
> use the ohms reading as the driver_data directly instead of going
> via the MAX548x enumeration, see below. Or is there some reason
> not doing so?
You make a good
Hi Ma Jun,
On 01/04/16 04:28, MaJun wrote:
> From: Ma Jun
>
> When the CPU of a non-balanced irq bounded is off line, the irq will be
> migrated to other CPUs,
> usually the first cpu on-line.
>
> We can suppose the situation if a system has more than one non-balanced irq.
> At extreme case, t
Hi Boris,
From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
Sent: Wednesday, March 30, 2016 10:04 PM
Subject: [PATCH v5 35/46] hwmon: pwm-fan: switch to the atomic API
>
> pwm_config/enable/disable() have been deprecated and should be replaced
> by pwm_apply_state().
>
> Signed-o
On 01/04/16 09:43, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote:
>> --- a/kernel/smp.c
>> +++ b/kernel/smp.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "smpboot.h"
>>
>> @@ -758,9 +759,14 @@ struct smp_sy
On Fri, Apr 01, 2016 at 10:23:23AM +0200, Peter Zijlstra wrote:
>
> Trim your emails
>
> On Fri, Apr 01, 2016 at 10:16:42AM +0200, Stephane Gasparini wrote:
>
> > > That means these delta's can be arbitrarily large, in fact the MSRs can
> > > have wrapped however many times.
> >
> > 64 bits is
The "ch->ch_bd" is already assined to "bd" but this is only
for checking null or MAGIC number.
in the dgnc_tty_ioctl function, bd can be used for referencing
to board_ops structure.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgnc/dgnc_tty.c | 37 -
1 file
Hi Boris,
From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
Sent: Wednesday, March 30, 2016 10:04 PM
Subject: [PATCH v5 08/46] hwmon: pwm-fan: use pwm_get_args() where
appropriate
>
> The PWM framework has clarified the concept of reference PWM config (the
> platform dependent con
fix checkpatch.pl warning about 'Avoid CamelCase'
Signed-off-by: Daeseok Youn
---
drivers/staging/dgnc/dgnc_tty.c | 2 +-
drivers/staging/dgnc/digi.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
ind
On Fri, Mar 25, 2016 at 12:20 PM, Peter Rosin wrote:
> Hi again,
>
> Cristina Moraru wrote:
>> Add implementation for Maxim MAX5487, MAX5488, MAX5489
>> digital potentiometers.
>>
>> Signed-off-by: Cristina Moraru
>> CC: Daniel Baluta
>
> Some more comments, the mcp4531 chips have n**2 + 1 posit
> Using this requires software triggers like CONFIG_IIO_HRTIMER_TRIGGER.
>
> The device can be configured to do internal periodic sampling but does
> not appear to offer some sort of interrupt on data ready. It only offers
> interrupts on values out of a specific range.
>
> Signed-off-by: Creste
/linux/x86_64-nfsroot/gcc-5/1131f64d74958d495d8a6d5f9b981e86ed3beb7a/vmlinuz-4.6.0-rc1-00028-g1131f64
-append 'root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-43/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-nfsroot-1131f64d74958d495d8a6d5f9b981e86ed3beb7a-20160401-52945-1
On 03/31/2016 11:01 PM, Andrew Morton wrote:
On Thu, 31 Mar 2016 15:13:41 +0200 Vlastimil Babka wrote:
On 03/29/2016 03:06 PM, Vlastimil Babka wrote:
> On 03/25/2016 08:22 PM, Andrew Morton wrote:
>> Also, mm/mempolicy.c:offset_il_node() worries me:
>>
>>do {
>>nid = ne
On Thu, Mar 31, 2016 at 03:38:10PM +0300, Sergei Shtylyov wrote:
> >When debugging a relocated kernel, the addresses of the relocated
> >symbols and the offset applied is essential information. If the kernel
> >is compiled with debugging information, then print this information
> >during bootup us
On Fri, Apr 01, 2016 at 10:28:46AM +0200, Juergen Gross wrote:
> On 01/04/16 09:43, Peter Zijlstra wrote:
> > On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote:
> >> --- a/kernel/smp.c
> >> +++ b/kernel/smp.c
> >> @@ -14,6 +14,7 @@
> >> #include
> >> #include
> >> #include
> >> +#
On Fri, Apr 1, 2016 at 12:59 PM, Adrian Hunter wrote:
> On 31/03/16 17:17, Naveen Kumar Parna wrote:
>> When switching SD and SDIO cards from 3.3V to 1.8V signal level fails, a bug
>> in sdhci_set_power() will trigger.
>> To fix the kernel crash during recovery from signal voltage switch failure,
On Tue, Mar 29, 2016 at 11:01:16AM +0100, Stefano Stabellini wrote:
> Not my full time job anymore, but still maintaining it.
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32bafda..049aa1d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12193,16 +1
On Fri 2016-04-01 10:08:03, Sergey Senozhatsky wrote:
> Hello Petr,
>
> On (03/31/16 13:12), Petr Mladek wrote:
> > > + * Set printing kthread sleep condition early, under the
> > > + * logbuf_lock, so it (if RUNNING) will go to console_lock()
> > > + * and spin on logbuf_lock.
> > > + */
> >
On 01/04/16 10:44, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 10:28:46AM +0200, Juergen Gross wrote:
>> On 01/04/16 09:43, Peter Zijlstra wrote:
>>> On Fri, Apr 01, 2016 at 09:14:33AM +0200, Juergen Gross wrote:
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -14,6 +14,7 @@
#incl
Commit cdcea058e510("serial: 8250_dw: Avoid serial_outx code duplicate
with new dw8250_check_lcr()") introduce a wrong logic when write val to
LCR reg. When CONFIG_64BIT enabled, __raw_writeq is used unconditionally.
But for !PORT_OCTEON, we better to use coincident write func.
Signed-off-by: Kef
On Wed, Jan 28, 2015 at 07:22:51PM +0300, Vladimir Davydov wrote:
> +++ b/mm/slub.c
> @@ -2007,6 +2007,7 @@ static void put_cpu_partial(struct kmem_cache *s,
> struct page *page, int drain)
> int pages;
> int pobjects;
>
> + preempt_disable();
> do {
> pages =
On 01/04/16 09:44, Ralf Baechle wrote:
On Thu, Mar 31, 2016 at 03:38:10PM +0300, Sergei Shtylyov wrote:
When debugging a relocated kernel, the addresses of the relocated
symbols and the offset applied is essential information. If the kernel
is compiled with debugging information, then print t
On Fri, 1 Apr 2016 09:26:54 +0200 Michal Hocko wrote:
> I was more worried about dependencies when you send your patch bomb to
> Linus because then it is an additional burden on you to watch for tip
> merge before you send yours.
That happens pretty often. I haven't screwed it up yet ;)
Usuall
On Fri, Apr 01, 2016 at 11:03:21AM +0200, Juergen Gross wrote:
> > Maybe just make the vpin thing an option like:
> >
> > smp_call_on_cpu(int (*func)(void *), int phys_cpu);
> > Also; is something like the vpin thing possible on KVM? because if we're
> > going to expose it to generic code lik
L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
to determine the cacheline size in runtime.
Signed-off-by: Jisheng Zhang
Suggested-by: Marcin Wojtas
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/et
L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
to determine the cacheline size in runtime.
Signed-off-by: Jisheng Zhang
Suggested-by: Marcin Wojtas
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/e
On Thu, Mar 31, 2016 at 02:26:06PM -0700, Steve Muckle wrote:
> > Can't, the way the wakeup path is constructed we would be sending the
> > IPI way before we know about utilization.
>
> Sorry I thought we were referring to the possibility of sending an IPI
> to just run the cpufreq driver rather t
On 3/31/2016 9:27 PM, Winkler, Tomas wrote:
> On Thu, 2016-03-31 at 19:57 +0100, Joao Pinto wrote:
>> Adding UFS 2.0 support to the UFS core driver.
>>
>> Signed-off-by: Joao Pinto
>
> Looks good to me, though not tested yet
> Tomas
I have tested the build in a x86 and ARC. Also tested the funct
2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki :
> On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote:
>> 2016-03-31 13:42 GMT+02:00 Rafael J. Wysocki :
>> > On Thursday, March 31, 2016 11:05:56 AM Jörg Otte wrote:
>> >
>> > [cut]
>> >
>> >> >
>> >>
>> >> Yes, works for me.
>> >>
>> >> CPUID(7):
On Fri 01-04-16 08:33:48, Ingo Molnar wrote:
[...]
> I can help on the Git level: I can do tip:locking/rwsem tree with only these
> changes, with stable sha1's, on which the remaining work can be based. The
> locking tree typically goes in early during the merge window, so there's no
> real depend
1 - 100 of 890 matches
Mail list logo
