Hi Jan,
Just out of curiosity, have you tried to use "76" on both values to
check if the problem still happens?
--
Regards,
Marcelo
On Fri, Sep 23, 2016 at 08:22:27PM -0400, Jan Stancek wrote:
> Hi,
>
> I'm chasing a memory corruption with 4.8-rc7 as I'm observing random Oopses
> on ppc BE/LE
On Mon, Sep 26, 2016 at 03:36:24PM +0800, Bob Liu wrote:
> xen_blkif_get/put() for each queue is useless, and introduces a bug:
>
> If there is I/O inflight when removing device, xen_blkif_disconnect() will
> return -EBUSY and xen_blkif_put() not be called.
> Which means the references are leaked,
On 09/26/2016 02:10 PM, Peter Zijlstra wrote:
> On Mon, Sep 26, 2016 at 02:01:43PM +0200, Christian Borntraeger wrote:
>> They applied ok on next from 9/13. Things go even worse.
>> With this host configuration:
>>
>> CPU NODE BOOK SOCKET CORE L1d:L1i:L2d:L2i ONLINE CONFIGURED ADDRESS
>> 0 00
Hi all,
on an i.MX6Q we had a situation where we got "Imprecise Data Aborts".
The backtraces of those aborts were useless, all over the place.
But we found out that we can trigger this bug with this procedure:
- make some external PC send constantly through the serial port
to the i.MX6Q.
- run
On Sun, Sep 25, 2016 at 01:48:50PM +0800, Baoyou Xie wrote:
> We get a few warnings when building kernel with W=1:
> drivers/scsi/mvsas/mv_sas.c:77:18: warning: no previous prototype for
> 'mvs_find_dev_mvi' [-Wmissing-prototypes]
> drivers/scsi/mvsas/mv_sas.c:105:5: warning: no previous prototype
Hallo,
On Mon, Sep 26, 2016 at 03:55:31PM +0200, Sascha Hauer wrote:
> The USR2_DCDIN bit is tested for in register usr1. As the name
> suggests the usr2 register should be used instead. This fixes
> reading the Carrier detect status.
>
> Signed-off-by: Sascha Hauer
Fixes: 90ebc4838666 ("serial:
Hi Sascha,
On Mon, Sep 26, 2016 at 10:55 AM, Sascha Hauer wrote:
> The USR2_DCDIN bit is tested for in register usr1. As the name
> suggests the usr2 register should be used instead. This fixes
> reading the Carrier detect status.
>
> Signed-off-by: Sascha Hauer
Good catch:
Reviewed-by: Fabio
From: Nava kishore Manne
This patch Adds the new compatible string for ZynqMP SoC.
Signed-off-by: Nava kishore Manne
---
Changes for v5:
-Fixed some minor comments.
Changes for v4:
-Modified the ChangeLog comment.
Changes for v3:
-Added changeLog
Hi
Is there any chance this could be removed from the upcoming drm-4.9
pull, at least until this issue has been fixed
Regards
Mike
On 21 September 2016 at 12:34, Mike Lothian wrote:
> I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll
> attach the info you requested once I get
Hi
On Mon, Sep 26, 2016 at 3:55 PM, Fabio Estevam wrote:
> On Mon, Sep 26, 2016 at 10:54 AM, Michael Trimarchi
> wrote:
>
>>> Why don't you simply do like this?
>>>
>>>reg_3p3v: regulator-3p3v {
>>>compatible = "regulator-fixed";
>>>regulator-name = "3P3V"
The USR2_DCDIN bit is tested for in register usr1. As the name
suggests the usr2 register should be used instead. This fixes
reading the Carrier detect status.
Signed-off-by: Sascha Hauer
---
drivers/tty/serial/imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/t
On Mon, Sep 26, 2016 at 10:54 AM, Michael Trimarchi
wrote:
>> Why don't you simply do like this?
>>
>>reg_3p3v: regulator-3p3v {
>>compatible = "regulator-fixed";
>>regulator-name = "3P3V";
>>regulator-min-microvolt = <330>;
>>
Hi
On Mon, Sep 26, 2016 at 3:47 PM, Fabio Estevam wrote:
> Hi Matteo,
>
> On Mon, Sep 26, 2016 at 10:44 AM, Matteo Lisi wrote:
>> Hi Fabio,
>>
>> Our SOM doesn't use external PMIC.
>>
>> We powered all devices with a fix voltage regulators that cannot be drive
>> directly from SoC so
>> any exte
Hi Fabio,
Our SOM doesn't use external PMIC.
We powered all devices with a fix voltage regulators that cannot be
drive directly from SoC so
any external power rail can be driven by drivers.
Regards
Matteo
Il 21/09/2016 18:46, Fabio Estevam ha scritto:
Hi Michael,
On Tue, Sep 20, 2016 at
Hi Matteo,
On Mon, Sep 26, 2016 at 10:44 AM, Matteo Lisi wrote:
> Hi Fabio,
>
> Our SOM doesn't use external PMIC.
>
> We powered all devices with a fix voltage regulators that cannot be drive
> directly from SoC so
> any external power rail can be driven by drivers.
Sure, this is fine.
Why don
Hi,
the series is now in hid.git#for-4.9/logitech. Thanks,
--
Jiri Kosina
SUSE Labs
On Mon, Sep 26, 2016 at 02:39:53PM +0200, Mike Galbraith wrote:
> On Mon, 2016-09-26 at 14:29 +0200, Mike Galbraith wrote:
>
> > Checkout timers/core, and merge nodeid, and all is well. I'm currently
> > bisecting the result against HEAD.. which will likely be about as
> > useful as the last five
Currently if AAD is enabled in the device, during system suspend
the feature remains, regardless of whether the codec is a wake-up
source or not. This means some additional power is being used
which is unnecessary, and can causes issues with some platforms'
IRQ handlers where state changes during s
On 09/26/16 01:55, Peter Zijlstra wrote:
On Sun, Sep 25, 2016 at 07:08:45PM -0700, Bart Van Assche wrote:
A quote from Documentation/memory_barriers.txt:
For example, because 'jiffies' is marked volatile, it is never
necessary to say READ_ONCE(jiffies). The reason for this is
that READ_ONCE()
Currently the reset code in i2c_probe only resets the AAD part of
the device and not the entire codec. This patch updates the driver
to resolve this and ensures that if the codec is still active from
a previous boot then the audio paths are powered down prior to
reset.
Signed-off-by: Adam Thomson
This patch set makes the following updates to the driver code:
1) Ensures codec is properly reset at startup, and if previously active then
disable audio paths prior to reset.
2) Disables AAD in suspend, if device is not a wake-up source.
Changes are based on top of latest code introduced u
On 09/26/2016 01:33 AM, Daniel Wagner wrote:
> Hi Anna,
>
> On 09/23/2016 03:48 PM, Anna Schumaker wrote:
>>> Besides trying to analys all the code paths to the wait_for_completion()
>>> call and convince myself that there is only one waiter, I also run
>>> a few tests:
>>>
>>> - some fio benchma
Hi Arnd
On 09/23/2016 09:38 PM, Arnd Bergmann wrote:
Building this driver with a 64-bit dma_addr_t type results in
a compiler warning:
drivers/tty/serial/stm32-usart.c: In function 'stm32_of_dma_rx_probe':
drivers/tty/serial/stm32-usart.c:746:20: error: cast from pointer to integer of
differen
Hi Arnd
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 23 September 2016 14:43
> To: Gabriele Paoloni
> Cc: zhichang.yuan; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; lorenzo.pieral...@arm.com; miny...@acm.org;
> linux-...@vger.kernel.org;
Krzysztof Kozlowski writes:
> On Sun, Sep 25, 2016 at 11:10:10PM +0200, Wolfgang Wiedmeyer wrote:
>> The capacity property uses the RepSOC register to report the current state
>> of charge. This register did not provide a reliable SOC value during my
>> testing with the max17047 variant on a Gala
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Saturday, September 24, 2016 4:08 AM
> To: Nava kishore Manne
> Cc: gre...@linuxfoundation.org; mark.rutl...@arm.com; jsl...@suse.com;
> michal.si...@xilinx.com; Soren Brinkmann ; linux-
> ser...@vger.kernel.org; d
On 26/09/2016:12:01:59 PM, Catalin Marinas wrote:
> On Sun, Sep 25, 2016 at 10:32:28PM +0530, Pratyush Anand wrote:
> > On Fri, Sep 23, 2016 at 6:35 PM, Catalin Marinas
> > wrote:
> > > On Fri, Sep 23, 2016 at 09:42:30AM +0530, Pratyush Anand wrote:
> > >> On 22/09/2016:05:50:30 PM, Catalin Marina
Krzysztof Kozlowski writes:
> On Sun, Sep 25, 2016 at 11:10:11PM +0200, Wolfgang Wiedmeyer wrote:
>> This patch reports the battery technology as Li-ion.
>>
>> Signed-off-by: Wolfgang Wiedmeyer
>> ---
>> drivers/power/max17042_battery.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff
Schönen Tag,
Wir UK CREDIT LTD KREDITFinanzGesellschaft mit Sitz in Großbritannien durch
die
Operationen und eine gute Kundenbasis auf der ganzen Welt. Wir bieten Darlehen
zu niedrigen
Zinssatz von 3%. Liebe Leser werden darauf hingewiesen, dass dieses Angebot
ernst
gesinnten Individuu
On 09/26/2016 05:24 PM, Peter Senna Tschudin wrote:
On Monday, September 26, 2016 12:29 CEST, Archit Taneja
wrote:
Hi,
Some comments.
Thank you for the review!
On 08/09/2016 10:11 PM, Peter Senna Tschudin wrote:
Add a driver that create a drm_bridge and a drm_connector for the LVDS
@@ -976,13 +974,12 @@ static void handle_controller(_cmsg *cmsg)
if (debugmode)
printk(KERN_DEBUG "capidrv-%d: listenconf Info=0x%4x
(%s) cipmask=0x%x\n",
card->contrnr, cmsg->Info,
capi_info2str(cmsg->Info), card->cipmask);
>>
On Monday, September 26, 2016 07:43:14 AM Zheng, Lv wrote:
> Hi, Rafael
>
> > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > Subject: Re: [PATCH v5 0/5] ACPI 2.0: Stop defer-executing module level code
> >
> > On Friday, September 23, 2016 11:26:26 AM Lv Zheng wrote:
> > > After fixing A
On 09/26/2016 02:10 PM, Peter Zijlstra wrote:
> On Mon, Sep 26, 2016 at 02:01:43PM +0200, Christian Borntraeger wrote:
>> They applied ok on next from 9/13. Things go even worse.
>> With this host configuration:
>>
>> CPU NODE BOOK SOCKET CORE L1d:L1i:L2d:L2i ONLINE CONFIGURED ADDRESS
>> 0 00
On Wednesday, September 14, 2016 10:54:58 AM Hoan Tran wrote:
> For PCC mailbox with interrupt flag, CPPC should call mbox_chan_txdone()
> function to notify the mailbox framework about TX completion.
>
> Signed-off-by: Hoan Tran
> Reviewed-by: Prashanth Prakash
> ---
> drivers/acpi/cppc_acpi.c
rt_mutex_waiter::prio is a copy of task_struct::prio which is updated
during the PI chain walk, such that the PI chain order isn't messed up
by (asynchronous) task state updates.
Currently rt_mutex_waiter_less() uses task state for deadline tasks;
this is broken, since the task state can, as said
Previous patches changed the meaning of the return value of
rt_mutex_slowunlock(); update comments and code to reflect this.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/futex.c | 12 ++--
kernel/locking/rtmutex.c| 20 +---
kernel/locking/
There is but a single user and the previous patch mandates slowfn must
be rt_mutex_slowunlock(), so fold the lot together and save a few
lines.
Reviewed-by: Steven Rostedt
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/locking/rtmutex.c | 29 ++---
1 file changed, 10
Pass the PI donor task, instead of a numerical priority.
Numerical priorities are not sufficient to describe state ever since
SCHED_DEADLINE.
Annotate all sched tracepoints that are currently broken; fixing them
will bork userspace. *hate*.
Signed-off-by: Peter Zijlstra (Intel)
---
include/tra
Currently dl tasks will actually return at the very beginning
of rt_mutex_adjust_prio_chain() in !detect_deadlock cases:
if (waiter->prio == task->prio) {
if (!detect_deadlock)
goto out_unlock_pi; // out here
else
requeue = false;
}
As the deadline
We should deboost before waking the high-priority task, such that we
don't run two tasks with the same "state" (priority, deadline,
sched_class, etc).
In order to make sure the boosting task doesn't start running between
unlock and deboost (due to 'spurious' wakeup), we move the deboost
under the
OK, long time since I posted, but I finally found these patches again.
Hopefully I addressed all feedback from last time (sorry if I missed anything).
Aside from the stuff I posted during review last time, I restructured the first
two patches to get rid of that unparsable changelog.
I folded part
With the introduction of SCHED_DEADLINE the whole notion that priority
is a single number is gone, therefore the @prio argument to
rt_mutex_setprio() doesn't make sense anymore.
So rework the code to pass a pi_task instead.
Note this also fixes a problem with pi_top_task caching; previously we
wo
There was a pure ->prio comparison left in try_to_wake_rt_mutex(),
convert it to use rt_mutex_waiter_less(), noting that greater-or-equal
is not-less (both in kernel priority view).
This necessitated the introduction of cmp_task() which creates a
pointer to an unnamed stack variable of struct rt_m
A crash happened while I was playing with deadline PI rtmutex.
BUG: unable to handle kernel NULL pointer dereference at 0018
IP: [] rt_mutex_get_top_task+0x1f/0x30
PGD 232a75067 PUD 230947067 PMD 0
Oops: [#1] SMP
CPU: 1 PID: 10994 Comm: a.out Not tainted
C
Peter Zijlstra writes:
> On Mon, Sep 26, 2016 at 11:27:08AM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra writes:
>> > At which point we _should_ start failing fork(), which is a somewhat
>> > unexpected, and undesirable side-effect.
>>
>> I'm not sure I see why we should fail fork() when
On Mon, 2016-09-26 at 14:29 +0200, Mike Galbraith wrote:
> Checkout timers/core, and merge nodeid, and all is well. I'm currently
> bisecting the result against HEAD.. which will likely be about as
> useful as the last five bisections, but ya never know. (ok git, finger
> somebody already [hotplu
On 26 September 2016 at 14:13, Rafał Miłecki wrote:
> On 26 September 2016 at 13:46, Arend Van Spriel
> wrote:
>> On 26-9-2016 12:23, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> We need to track 802.1x packets to know if there are any pending ones
>>> for transmission. This is required
Hi Daniel,
On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote:
> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
> wrote:
> >
> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
> > >
> > > Sorry, that was a misunderstanding. Buildroot routinely runs the strip
> > > command on .ko fil
On Thu, 22 Sep 2016 19:29:08 +0200,
Greg Kroah-Hartman wrote:
>
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Zefan Li
>
> commit 06f4e94898918bcad00cdd4d349313a439d6911e upstream.
>
> A new task inherits cpus_allowed and mems_a
The 100c10 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)
So move the dma_m
Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using
dma_map_page() way before the TTM layer has had a chance to set the DMA
mask. This may prevent the driver from loading at all on platforms whose
system memory is not covered by the default DMA mask of 32-bit (i.e., when
all R
This v4 is now a 3 piece series, after Alexandre pointed out that both
GF 100 and NV50 are affected by the same issue, and that a related issue
has been solved already for Tegra in commit 9d0394c6bed5
("drm/nouveau/instmem/gk20a: set DMA mask early").
The issue that this series addresses is the fa
The 100c08 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)
So move the dma_m
>> The script "checkpatch.pl" can point out that assignments should usually
>> not be performed within condition checks.
>> Thus move the assignment for a variable to a separate statement
>> in four functions.
>
> Did you recycle this commit explanation?
Yes. - I am going to use similar commit me
Hi Ingo,
I've encountered a strange regression in tip, symptom is that if you
boot with nr_cpus=nr_you_have, what actually boots is nr_you_have/2.
Do not pass nr_cpus=, and all is well.
Bisection repeatedly goes as below, pointing to the nodeid merge,
despite both timers/core and x86/apic (nod
On Monday, September 26, 2016 10:15:24 AM Marek Szyprowski wrote:
> Hi Rafael,
>
>
> On 2016-09-24 03:25, Rafael J. Wysocki wrote:
> > On Friday, September 23, 2016 03:50:02 PM Lukas Wunner wrote:
> >> On Fri, Sep 23, 2016 at 02:49:20PM +0200, Rafael J. Wysocki wrote:
> >>> On Tuesday, September
On Fri, Sep 23, 2016 at 12:49:30PM -0400, Julien Desfossez wrote:
> With this macro, we propose new versions of the sched_switch, sched_waking,
> sched_process_fork and sched_pi_setprio tracepoint probes that contain more
> scheduling information and get rid of the "prio" field. We also add the PI
On 26 September 2016 at 12:56, Peter Zijlstra wrote:
> On Mon, Sep 26, 2016 at 12:42:22PM +0200, Christian Borntraeger wrote:
>> Folks,
>>
>> I have seen big scalability degredations sind 4.3 (bisected 9d89c257d
>> sched/fair: Rewrite runnable load and utilization average tracking)
>> This has not
Fix the insertion of cfs_rq in rq->leaf_cfs_rq_list to ensure that
a child will always be called before its parent.
The hierarchical order in shares update list has been introduced by
commit 67e86250f8ea ("sched: Introduce hierarchal order on shares update list")
With the current implementation a
A task can be asynchronously detached from cfs_rq when migrating
between CPUs. The load of the migrated task is then removed from
source cfs_rq during its next update. We use this event to set propagation
flag.
During the load balance, we take advanatge of the update of blocked load
to we propagat
The moves of tasks are now propagated down to root and the utilization
of cfs_rq reflects reality so it doesn't need to be estimated at init.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sc
On 26-9-2016 14:13, Rafał Miłecki wrote:
> On 26 September 2016 at 13:46, Arend Van Spriel
> wrote:
>> On 26-9-2016 12:23, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> We need to track 802.1x packets to know if there are any pending ones
>>> for transmission. This is required for perfor
When a task moves from/to a cfs_rq, we set a flag which is then used to
propagate the change at parent level (sched_entity and cfs_rq) during
next update. If the cfs_rq is throttled, the flag will stay pending until
the cfs_rw is unthrottled.
For propagating the utilization, we copy the utilizatio
When a task switches to fair scheduling class, the period between now and
the last update of its utilization is accounted as running time whatever
happened during this period. This wrong accounting applies to the task
and also to the task group branch.
When changing the property of a running task
Ensure that the move of a sched_entity will be reflected in load and
utilization of the task_group hierarchy.
When a sched_entity moves between groups or CPUs, load and utilization
of cfs_rq don't reflect the changes immediately but converge to new values.
As a result, the metrics are no more alig
Factorize post_init_entity_util_avg and part of attach_task_cfs_rq
in one function attach_entity_cfs_rq
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index
Every time, we modify load/utilization of sched_entity, we start to sync
it with its cfs_rq. This update is done is different ways:
-when attaching/detaching a sched_entity, we update cfs_rq and then we
sync the entity with the cfs_rq.
-when enqueueing/dequeuing the sched_entity, we update both sch
On Sunday, September 25, 2016 03:12:05 PM Ondrej Zary wrote:
> Hello,
> I've upgraded kernel (Debian Squeeze - backports) from 4.6 (4.6.4-1~bpo8+1)
> to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working with error messages like
> this:
>
> ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci
On 26 September 2016 at 13:46, Arend Van Spriel
wrote:
> On 26-9-2016 12:23, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> We need to track 802.1x packets to know if there are any pending ones
>> for transmission. This is required for performing key update in the
>> firmware.
>
> The problem
On Mon, Sep 26, 2016 at 02:01:43PM +0200, Christian Borntraeger wrote:
> They applied ok on next from 9/13. Things go even worse.
> With this host configuration:
>
> CPU NODE BOOK SOCKET CORE L1d:L1i:L2d:L2i ONLINE CONFIGURED ADDRESS
> 0 000 00:0:0:0 yesyes0
We get 6 warnings when building kernel with W=1:
drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous prototype for
'beiscsi_log_enable_disp' [-Wmissing-prototypes]
drivers/scsi/be2iscsi/be_main.c:78:1: warning: no previous prototype for
'beiscsi_log_enable_change' [-Wmissing-prototypes]
dr
On 09/26/2016 01:53 PM, Peter Zijlstra wrote:
> On Mon, Sep 26, 2016 at 01:42:05PM +0200, Christian Borntraeger wrote:
>> On 09/26/2016 12:56 PM, Peter Zijlstra wrote:
>
>>> One of the differences in the old and new thing is being addressed by
>>> these patches:
>>>
>>>
>>> https://lkml.kernel.
On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
> > But then code which reads those will have to *know* that those cores are
> > offline - otherwise it would be confused by what it is reading there.
>
> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
>
We get 2 warnings when building kernel with W=1:
drivers/tty/serial/stm32-usart.c:63:5: warning: no previous prototype for
'stm32_pending_rx' [-Wmissing-prototypes]
drivers/tty/serial/stm32-usart.c:88:15: warning: no previous prototype for
'stm32_get_char' [-Wmissing-prototypes]
In fact, these t
2016-09-22 15:14 GMT+02:00 Uwe Kleine-König :
> On Mon, Sep 12, 2016 at 11:47:31AM +0200, Richard Genoud wrote:
>> This function returns true if CTS and RTS are used as GPIOs.
>> Some drivers (like atmel_serial) needs to know if the flow control is
>> handled by the controller or by GPIOs.
>>
>> Si
On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
> when online is 0, topology disappears so there is no way to determine _the
> location_ of the offline'd thread.
What does "the location" mean exactly?
On Monday, September 26, 2016 12:29 CEST, Archit Taneja
wrote:
> Hi,
>
> Some comments.
Thank you for the review!
>
> On 08/09/2016 10:11 PM, Peter Senna Tschudin wrote:
> > Add a driver that create a drm_bridge and a drm_connector for the LVDS
> > to DP++ display bridge of the GE B850v3
On Mon, Sep 26, 2016 at 01:42:05PM +0200, Christian Borntraeger wrote:
> On 09/26/2016 12:56 PM, Peter Zijlstra wrote:
> > One of the differences in the old and new thing is being addressed by
> > these patches:
> >
> >
> > https://lkml.kernel.org/r/1473666472-13749-1-git-send-email-vincent.gu
From: Wanpeng Li
WARNING: CPU: 0 PID: 3331 at arch/x86/entry/common.c:45
enter_from_user_mode+0x32/0x50
CPU: 0 PID: 3331 Comm: ldt_gdt_64 Not tainted 4.8.0-rc7+ #13
Call Trace:
dump_stack+0x99/0xd0
__warn+0xd1/0xf0
warn_slowpath_null+0x1d/0x20
enter_from_user_mode+0x32/0x50
error_en
On 26-9-2016 12:23, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> We need to track 802.1x packets to know if there are any pending ones
> for transmission. This is required for performing key update in the
> firmware.
The problem we are trying to solve is a pretty old one. The problem is
that w
Do fault injection initialization in default_options to keep consistent
with other default option configurating.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 4d5911b..aa35e60 100644
On 09/22/2016 08:10 AM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote:
>> System boots with (usually) with 2 threads/core. Some performance users want
>> one thread per core. Since there is no "noht" option anymore, users use
>> /sys to
>> disable a t
In ->remount_fs, we didn't recover original fault injection config if
we encounter error, fix it.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index aa35e60..6132b4c 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2
This patch adds to support checkpoint error injection in f2fs for testing
fatal error tolerance, it will be useful that it can simulate abnormal
power off by f2fs itself instead of calling godown ioctl by running apps.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h| 1 +
fs/f2fs/gc.c | 5 +++
We get 4 warnings when building kernel with W=1:
drivers/vhost/vhost.c:52:23: warning: no previous prototype for
'vhost_umem_interval_tree_insert' [-Wmissing-prototypes]
drivers/vhost/vhost.c:52:23: warning: no previous prototype for
'vhost_umem_interval_tree_remove' [-Wmissing-prototypes]
driver
On 09/26/2016 12:56 PM, Peter Zijlstra wrote:
> On Mon, Sep 26, 2016 at 12:42:22PM +0200, Christian Borntraeger wrote:
>> Folks,
>>
>> I have seen big scalability degredations sind 4.3 (bisected 9d89c257d
>> sched/fair: Rewrite runnable load and utilization average tracking)
>> This has not been fi
On Friday, September 23, 2016 09:45:09 PM Larry Finger wrote:
> On 09/18/2016 09:54 PM, Larry Finger wrote:
> > On 09/14/2016 11:00 AM, Larry Finger wrote:
> >> On 09/09/2016 12:39 PM, Larry Finger wrote:
> >>> I have found a regression in kernel 4.8-rc2 that causes the speed of my
> >>> laptop
>
On 24-9-2016 22:44, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> There are two protocols used by Broadcom FullMAC devices: BCDC and
> msgbuf. They use different ways for (some part of) communication with
> the firmware. Firmware Signaling is required for the first one only
> (BCDC).
>
> So far
Hi all,
On Sun, 25 Sep 2016 20:06:19 -0700 Linus Torvalds
wrote:
>
> exactly like you did. It's just that with 12 characters in the hex
> format, people will still be able to cut-and-paste the hash into git
> to get the full commit details even a year from now. With just 7 hex
> digits, you may
2016-09-26 1:53 GMT+01:00 Larry Finger :
> On 09/25/2016 06:00 PM, Gonçalo Salazar wrote:
>>
>> Fixed a block comment indentation in the rtl8712 usb_intf.c file.
>> Made this as a first commit.
>> Resubmitted with updated subject.
>>
>> Please let me know of any feedback you have.
>
>
> I missed th
On Sun, Sep 25, 2016 at 11:10:10PM +0200, Wolfgang Wiedmeyer wrote:
> The capacity property uses the RepSOC register to report the current state
> of charge. This register did not provide a reliable SOC value during my
> testing with the max17047 variant on a Galaxy S3 (Trats2/GT-I9300). The
> repo
Changes in V2:
- Patches sent to early with bad contents
Changes in V3:
- Change subject
- Split "configure imx for ULPI phy" for disable-oc code
Changes in V4:
- Fix "Change switch order" commit message
- Indent switch/case (set case on the same column as sw
In order to use ULPI phy with usb host 2 and 3, we need to configure
controller register to enable ULPI features.
Each USB controller have different behaviour, so in order to avoid to have
several "swicth(data->index)" and lock/unlock, we prefer to get the index
switch and then test for features i
The internal 60Mhz clock for host2 and host3 are useless in ULPI
phy mode, so we disable it when configuring ULPI PHY node for
those host.
Signed-off-by: Fabien Lahoudere
---
drivers/usb/chipidea/usbmisc_imx.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/chipidea/
Hi
On Mon, 26 Sep 2016, Benjamin Tissoires wrote:
> Thanks for the patch series. I am not against it, but I'd rather see the
> commit message of this one amended, and the second patch changed.
Sorry if I came out too aggresive (I'll amend), I'm just annoyed that I
had to spend a weekend night di
There is no need to export qcaspi_netdev_open and qcaspi_netdev_close
because they are also accessible via the net_device_ops.
Signed-off-by: Stefan Wahren
---
drivers/net/ethernet/qualcomm/qca_debug.c | 5 +++--
drivers/net/ethernet/qualcomm/qca_spi.h | 3 ---
2 files changed, 3 insertions(+)
As preparation for the upcoming UART driver we need a module
which contains common functions for both interfaces. The module
qca_framing is a good candidate but renaming to qca_common would
make it clear.
Signed-off-by: Stefan Wahren
---
drivers/net/ethernet/qualcomm/Makefile | 2 +-
driv
The MTU of the QCA7000 is independent from it's host interface (UART,SPI).
So move the change_mtu function to qca_common.
Signed-off-by: Stefan Wahren
---
drivers/net/ethernet/qualcomm/qca_common.c | 11 +++
drivers/net/ethernet/qualcomm/qca_common.h | 3 +++
drivers/net/ethernet/qualco
Unfortunately the frame format is not exactly identical between SPI
and UART. In case of SPI there is an additional HW length at the
beginning. So store the initial state to make the decoding state machine
more flexible and easy to extend for UART support.
Signed-off-by: Stefan Wahren
---
driver
In order to share common functions between QCA7000 SPI and UART protocol
driver the qca_common needs to be a separate kernel module.
Signed-off-by: Stefan Wahren
---
drivers/net/ethernet/qualcomm/Kconfig | 8 +++-
drivers/net/ethernet/qualcomm/Makefile | 5 +++--
drivers/net/ether
401 - 500 of 623 matches
Mail list logo
