Le 24/08/2019 à 02:18, Xiaowei Bao a écrit :
-Original Message-
From: Andrew Murray
Sent: 2019年8月23日 22:28
To: Xiaowei Bao
Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
shawn...@kernel.org; Leo Li ; kis...@ti.com;
lorenzo.pieral...@arm.co; a...@arndb.de; gre..
On Thu 22 Aug 10:01 PDT 2019, Vinod Koul wrote:
> Convert the rpmh clock driver to use the new parent data scheme by
> specifying the parent data for board clock.
>
> Signed-off-by: Vinod Koul
> ---
> drivers/clk/qcom/clk-rpmh.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
Am 22.08.19 um 21:01 schrieb Simon Arlott:
> Add replacement email address for the one on my expired domain.
>
> Signed-off-by: Simon Arlott
I already send out my pull requests. Can anyone else take care of this?
__flush_tlb_one_user() currently flushes a single entry, and flushes it
both in the kernel and user page-tables, when PTI is enabled.
Change __flush_tlb_one_user() and related interfaces into
__flush_tlb_range() that flushes a range and does not flush the user
page-table.
This refactoring is need
When a shootdown is initiated, the initiating CPU has cycles to burn as
it waits for the responding CPUs to receive the IPI and acknowledge it.
In these cycles it is better to flush the user page-tables using
INVPCID, instead of deferring the TLB flush.
The best way to figure out whether there are
INVPCID is considerably slower than INVLPG of a single PTE. Using it to
flush the user page-tables when PTI is enabled therefore introduces
significant overhead.
Instead, unless page-tables are released, it is possible to defer the
flushing of the user page-tables until the time the code returns t
INVPCID is considerably slower than INVLPG of a single PTE, but it is
currently used to flush PTEs in the user page-table when PTI is used.
Instead, it is possible to defer TLB flushes until after the user
page-tables are loaded. Preventing speculation over the TLB flushes
should keep the whole th
Sorry, I made a mistake and included the wrong patches. I will send
RFC v2 in few minutes.
> On Aug 23, 2019, at 3:46 PM, Nadav Amit wrote:
>
> INVPCID is considerably slower than INVLPG of a single PTE, but it is
> currently used to flush PTEs in the user page-table when PTI is used.
>
> Inst
INVPCID is considerably slower than INVLPG of a single PTE. Using it to
flush the user page-tables when PTI is enabled therefore introduces
significant overhead.
Instead, unless page-tables are released, it is possible to defer the
flushing of the user page-tables until the time the code returns t
When a shootdown is initiated, the initiating CPU has cycles to burn as
it waits for the responding CPUs to receive the IPI and acknowledge it.
In these cycles it is better to flush the user page-tables using
INVPCID, instead of deferring the TLB flush.
The best way to figure out whether there are
INVPCID is considerably slower than INVLPG of a single PTE, but it is
currently used to flush PTEs in the user page-table when PTI is used.
Instead, it is possible to defer TLB flushes until after the user
page-tables are loaded. Preventing speculation over the TLB flushes
should keep the whole th
The assertions that check whether IRQs are disabled depend currently on
different debug features. Use instead lockdep_assert_irqs_disabled(),
which is standard, enabled by the same debug feature, and provides more
information upon failures.
Signed-off-by: Nadav Amit
---
arch/x86/mm/tlb.c | 5 ++
The percpu code mostly uses inline assembly. Using segment qualifiers
allows to use C code instead, which enables the compiler to perform
various optimizations (e.g., CSE). For example, in __schedule() the
following two instructions:
mov%gs:0x7e5f1eff(%rip),%edx# 0x10350
movslq %e
When per_cpu_ptr() is used, the caller should have preemption disabled,
as otherwise the pointer is meaningless. If the user wants an "unstable"
pointer he should call raw_cpu_ptr().
Add an assertion to check that indeed preemption is disabled, and
distinguish between the two cases to allow furthe
GCC v6+ supports x86 segment qualifiers (__seg_gs and __seg_fs). Define
COMPILER_HAS_X86_SEG_SUPPORT when it is supported.
Signed-off-by: Nadav Amit
---
include/linux/compiler-gcc.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.
this_cpu_read_stable() is allowed and supposed to cache and return the
same value, specifically for current_task. It actually does not cache
current_task very well, which hinders possible invalid caching when the
task is switched in __switch_to().
Fix the possible caching by avoiding the use of cu
The current_task is supposed to be constant in each thread and therefore
does not need to be reread. There is already an attempt to cache it
using inline assembly, using this_cpu_read_stable(), which hides the
dependency on the read memory address.
However, this caching is not working very well. F
GCC 6+ supports segment qualifiers. Using them allows to implement
several optimizations:
1. Avoid unnecessary instructions when an operation is carried on
read/written per-cpu value, and instead allow the compiler to set
instructions that access per-cpu value directly.
2. Make this_cpu_ptr() mor
Using a segment prefix qualifier is cleaner than using a segment prefix
in the inline assembly, and provides the compiler with more information,
telling it that __seg_gs:[addr] is different than [addr] when it
analyzes data dependencies. It also enables various optimizations that
will be implemente
Implementing arch_raw_cpu_ptr() in C, allows the compiler to perform
better optimizations, such as setting an appropriate base to compute
the address instead of an add instruction.
The benefit of this computation is relevant only when using compiler
segment qualifiers. It is inapplicable to use th
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
triggers following stack trace:
[25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
[25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
[25244.888167] Call Trace:
[25244.889182]
[25244.890001] tcp_fragment+0x9c/0x2cf
[25244.8912
The unification of these two functions allows to use them in the updated
SMP infrastrucutre.
To do so, remove the reason argument from flush_tlb_func_local(), add
a member to struct tlb_flush_info that says which CPU initiated the
flush and act accordingly. Optimize the size of flush_tlb_info whil
cpu_tlbstate is mostly private and only the variable is_lazy is shared.
This causes some false-sharing when TLB flushes are performed.
Break cpu_tlbstate intro cpu_tlbstate and cpu_tlbstate_shared, and mark
each one accordingly.
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Reviewed-by: Dave Hansen
S
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. Introduce
paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
and hyper-v are only compile-tested).
While the updated smp infrastructure is capable of r
The compiler is smart enough without these hints.
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Suggested-by: Dave Hansen
Reviewed-by: Dave Hansen
Signed-off-by: Nadav Amit
---
arch/x86/mm/tlb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/m
Currently, on_each_cpu() and similar functions do not exploit the
potential of concurrency: the function is first executed remotely and
only then it is executed locally. Functions such as TLB flush can take
considerable time, so this provides an opportunity for performance
optimization.
To do so,
Open-code on_each_cpu_cond_mask() in native_flush_tlb_others() to
optimize the code. Open-coding eliminates the need for the indirect branch
that is used to call is_lazy(), and in CPUs that are vulnerable to
Spectre v2, it eliminates the retpoline. In addition, it allows to use a
preallocated cpuma
[ Similar cover-letter to v3 with updated performance numbers on skylake.
Sorry for the time it since the last version. ]
Currently, local and remote TLB flushes are not performed concurrently,
which introduces unnecessary overhead - each PTE flushing can take 100s
of cycles. This patch-set allo
Blindly writing to is_lazy for no reason, when the written value is
identical to the old value, makes the cacheline dirty for no reason.
Avoid making such writes to prevent cache coherency traffic for no
reason.
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Suggested-by: Dave Hansen
Reviewed-by: Dave
cpumask_next_and() and cpumask_any_but() are pure, and marking them as
such seems to generate different and presumably better code for
native_flush_tlb_multi().
Reviewed-by: Dave Hansen
Signed-off-by: Nadav Amit
---
include/linux/cpumask.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletion
SGI UV TLB flushes is outdated and will be replaced with compatible
smp_call_many APIC function in the future. For now, simplify the code by
removing the UV special case.
Cc: Peter Zijlstra
Suggested-by: Andy Lutomirski
Acked-by: Mike Travis
Reviewed-by: Dave Hansen
Signed-off-by: Nadav Amit
On Fri, Aug 23, 2019 at 07:32:58PM -0700, Greg KH wrote:
On Fri, Aug 23, 2019 at 09:18:05PM -0400, Sasha Levin wrote:
On Fri, Aug 23, 2019 at 10:36:27AM -0700, Greg KH wrote:
> On Fri, Aug 23, 2019 at 02:28:53AM -0400, Sasha Levin wrote:
> > On Fri, Aug 23, 2019 at 02:42:48AM +0200, Stefan Lippe
> -Original Message-
> From: Alex Williamson
> Sent: Saturday, August 24, 2019 10:29 AM
> To: Parav Pandit
> Cc: Jiri Pirko ; Jiri Pirko ; David S .
> Miller ; Kirti Wankhede ;
> Cornelia Huck ; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; cjia ; net...@vger.kernel.org
> Subj
On Sat, Aug 24, 2019 at 10:11:24AM +1000, Dave Chinner wrote:
> On Fri, Aug 23, 2019 at 09:04:29AM -0300, Jason Gunthorpe wrote:
> > On Fri, Aug 23, 2019 at 01:23:45PM +1000, Dave Chinner wrote:
> >
> > > > But the fact that RDMA, and potentially others, can "pass the
> > > > pins" to other proces
On Sat, 24 Aug 2019 03:56:08 +
Parav Pandit wrote:
> > -Original Message-
> > From: Alex Williamson
> > Sent: Saturday, August 24, 2019 1:14 AM
> > To: Parav Pandit
> > Cc: Jiri Pirko ; Jiri Pirko ; David S
> > . Miller
> > ; Kirti Wankhede ; Cornelia
> > Huck ; k...@vger.kernel.or
On Fri, Aug 23, 2019 at 01:23:45PM +1000, Dave Chinner wrote:
> On Wed, Aug 21, 2019 at 01:44:21PM -0700, Ira Weiny wrote:
> > On Wed, Aug 21, 2019 at 04:48:10PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 21, 2019 at 11:57:03AM -0700, Ira Weiny wrote:
> > >
> > > > > Oh, I didn't think we wer
Hi Alex,
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Parav Pandit
> Sent: Saturday, August 24, 2019 9:26 AM
> To: Alex Williamson
> Cc: Jiri Pirko ; Jiri Pirko ; David S .
> Miller ; Kirti Wankhede ;
> Cornelia Huck ; k...@vger.kern
> -Original Message-
> From: Alex Williamson
> Sent: Saturday, August 24, 2019 1:14 AM
> To: Parav Pandit
> Cc: Jiri Pirko ; Jiri Pirko ; David S .
> Miller
> ; Kirti Wankhede ; Cornelia
> Huck ; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; cjia ; net...@vger.kernel.org
> Su
On 08/23/2019 06:53 PM, Tudor Ambarus - M18064 wrote:
> + * configuration register Quad Enable bit is one, only the the
^duplication
On Thu, 22 Aug 2019 17:51:12 +0200, Peter Zijlstra wrote:
> On Mon, Aug 12, 2019 at 07:18:59PM +0530, Satendra Singh Thakur wrote:
> > -The semaphore code has four funcs
> > down,
> > down_interruptible,
> > down_killable,
> > down_timeout
> > -These four funcs have almost similar code except that
On Sat, Aug 24, 2019 at 6:33 AM Roman Gushchin wrote:
>
> On Fri, Aug 16, 2019 at 05:47:26PM -0700, Roman Gushchin wrote:
> > Commit 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync
> > with the hierarchical ones") effectively decreased the precision of
> > per-memcg vmstats_local an
On Sat, Aug 24, 2019 at 10:57 AM Hillf Danton wrote:
>
>
> On Fri, 23 Aug 2019 18:00:15 -0400 Adric Blake wrote:
> > Synopsis:
> > A WARN_ON_ONCE is hit twice in set_task_reclaim_state under the
> > following conditions:
> > - a memory cgroup has been created and a task assigned it it
> > - memory
On Fri, 2019-08-23 at 16:13 +0800, Hsin-Yi Wang wrote:
> On Fri, Aug 23, 2019 at 4:09 PM Qii Wang wrote:
>
> > >
> > > static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
> > > {
> > > - return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> > > + if (adap->quirks->flags & I2C_AQ_NO_ZERO_L
On Fri, Aug 23, 2019 at 02:28:46PM -0500, Scott Wood wrote:
> On Fri, 2019-08-23 at 18:20 +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-08-21 18:19:05 [-0500], Scott Wood wrote:
> > > Without this, rcu_note_context_switch() will complain if an RCU read
> > > lock is held when migrate_enable()
On Fri, Aug 23, 2019 at 12:41:03PM -0600, shuah wrote:
> On 8/22/19 11:05 AM, Sasha Levin wrote:
> >
> > This is the start of the stable review cycle for the 5.2.10 release.
> > There are 135 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with t
On 8/23/19 2:26 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190822:
>
> The thermal tree gained a conflict against the jc_docs tree.
>
> The rdma tree gained a conflict against the rdma-fixes tree.
>
> The net-next tree gained conflicts against the pci tree.
>
> The crypto tree g
On Fri, Aug 23, 2019 at 09:18:05PM -0400, Sasha Levin wrote:
> On Fri, Aug 23, 2019 at 10:36:27AM -0700, Greg KH wrote:
> > On Fri, Aug 23, 2019 at 02:28:53AM -0400, Sasha Levin wrote:
> > > On Fri, Aug 23, 2019 at 02:42:48AM +0200, Stefan Lippers-Hollmann wrote:
> > > > Hi
> > > >
> > > > On 2019-
On Fri, Aug 23, 2019 at 5:27 PM Andrey Smirnov wrote:
>
> Configure IRQ line for SX1503 GPIO expander. We already have
> appropriate pinmux entry and all that is missing is "interrupt-parent"
> and "interrupts" properties. Add them.
>
> Signed-off-by: Andrey Smirnov
> Cc: Shawn Guo
> Cc: Chris H
> On Aug 21, 2019, at 3:30 AM, Peter Zijlstra wrote:
>
> On Wed, Aug 21, 2019 at 12:10:08PM +0200, Peter Zijlstra wrote:
>> On Tue, Aug 20, 2019 at 01:23:14PM -0700, Song Liu wrote:
>
>>> host-5.2-after # grep "x pmd" /sys/kernel/debug/page_tables/dump_pid
>>> 0x0060-0x00
On Mon, 19 Aug 2019, Mao Han wrote:
> PS: I got some compile error while compiling glibc 2.30 with linux
> v5.3-rc4 header. vfork.S include linux/sched.h(./include/uapi/linux/sched.h)
> which has a struct clone_args inside, added by
> 7f192e3cd316ba58c88dfa26796cf77789dd9872.
Noticed that also.
Hi Mika,
I'm trying to figure out specifically why we need this and where it
should go. Questions below.
On Wed, Aug 21, 2019 at 03:45:19PM +0300, Mika Westerberg wrote:
> Currently Linux does not follow PCIe spec regarding the required delays
> after reset. A concrete example is a Thunderbolt a
> On Aug 23, 2019, at 5:59 PM, Thomas Gleixner wrote:
>
> On Wed, 21 Aug 2019, Thomas Gleixner wrote:
>> On Wed, 21 Aug 2019, Song Liu wrote:
On Aug 20, 2019, at 1:23 PM, Song Liu wrote:
Before 32-bit support, pti_clone_pmds() always adds PMD_SIZE to addr.
This behavior c
On Wed, 21 Aug 2019, Alex Shi wrote:
> 在 2019/8/21 上午2:24, Hugh Dickins 写道:
> > I'll set aside what I'm doing, and switch to rebasing ours to v5.3-rc
> > and/or mmotm. Then compare with what Alex has, to see if there's any
> > good reason to prefer one to the other: if no good reason to prefer our
On Fri, 23 Aug 2019, David Abdurachmanov wrote:
> On Fri, Aug 23, 2019 at 5:30 PM Paul Walmsley
> wrote:
> >
> > On Thu, 22 Aug 2019, David Abdurachmanov wrote:
> >
> > > There is one failing kernel selftest: global.user_notification_signal
> >
> > Is this the only failing test? Or are the rest
On Fri, Aug 23, 2019 at 10:36:27AM -0700, Greg KH wrote:
On Fri, Aug 23, 2019 at 02:28:53AM -0400, Sasha Levin wrote:
On Fri, Aug 23, 2019 at 02:42:48AM +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On 2019-08-22, Greg KH wrote:
> > On Fri, Aug 23, 2019 at 12:05:27AM +0200, Stefan Lippers-Hollm
On Fri, 2019-08-23 at 20:14 +0200, Dietmar Eggemann wrote:
>
> Looks like with the se->depth related code gone here in
> pick_next_task_fair() and the call to find_matching_se() in
> check_preempt_wakeup() you could remove se->depth entirely.
>
> [...]
I've just done that in a separate patch in
.
>
> Well the code states ".. and hope that it doesn't break when there
> is actually a signal :)". Maybe we are just unlucky. I don't have results
> from other architectures to compare.
>
> I found that Linaro is running selftests, but SECCOMP is disabled
> and
nning selftests, but SECCOMP is disabled
and thus it's failing. Is there another CI which tracks selftests?
https://qa-reports.linaro.org/lkft/linux-next-oe/tests/kselftest/seccomp_seccomp_bpf?top=next-20190823
>
>
> - Paul
On 8/23/19 3:00 PM, Adric Blake wrote:
Synopsis:
A WARN_ON_ONCE is hit twice in set_task_reclaim_state under the
following conditions:
- a memory cgroup has been created and a task assigned it it
- memory.limit_in_bytes has been set
- memory has filled up, likely from cache
In my usage, I cre
On Wed, 21 Aug 2019, Thomas Gleixner wrote:
> On Wed, 21 Aug 2019, Song Liu wrote:
> > > On Aug 20, 2019, at 1:23 PM, Song Liu wrote:
> > >
> > > Before 32-bit support, pti_clone_pmds() always adds PMD_SIZE to addr.
> > > This behavior changes after the 32-bit support: pti_clone_pgtable()
> > >
Please check CONFIG_FRAME_POINTER
1 *frame = *((struct stackframe *)frame->fp - 1);
This code is origionally from riscv/kernel/stacktrace.c: walk_stackframe
In linux/Makefile it'll involve the options for gcc to definitely
store ra & prev_fp in fp pointer.
ifdef CONFIG_FRAME_POINTER
KBUILD_CFLAGS
On Thu, Aug 22, 2019 at 02:58:42PM +0800, Sam Shih wrote:
> Due to we added clock-frequency property to fix
> mt7628 pwm during configure from userspace.
> We can alos use this property to determine whether
> the complex clock tree exists in the SoC or not.
> So we can safety remove has-clock prope
On Thu, Aug 22, 2019 at 02:58:41PM +0800, Sam Shih wrote:
> From: Ryder Lee
>
> This updates bindings for MT7629 pwm controller.
>
> This patch is the same as
> https://patchwork.kernel.org/patch/10769381/
> and it has a Reviewed-by tag in v1
This paragraph doesn't belong in the commit log.
>
On Thu, Aug 22, 2019 at 02:58:40PM +0800, Sam Shih wrote:
> From: Ryder Lee
>
> This adds a property "num-pwms" for PWM controller.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Sam Shih
> ---
> arch/arm/boot/dts/mt7623.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/b
On Thu, Aug 22, 2019 at 02:58:39PM +0800, Sam Shih wrote:
> From: Ryder Lee
>
> This adds a property "num-pwms" for PWM controller.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Sam Shih
> ---
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a
On Thu, Aug 22, 2019 at 04:12:20PM +0800, Yingjoe Chen wrote:
> On Thu, 2019-08-22 at 14:58 +0800, Sam Shih wrote:
> > This updates bindings for MT7628 pwm controller.
> >
> > Signed-off-by: Sam Shih
> > ---
> > Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 4
> > 1 file changed,
On Thu, Aug 22, 2019 at 02:58:36PM +0800, Sam Shih wrote:
> Add SPDX identifiers to pwm-mediatek.c
> Update license to GNU General Public License v2.0
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
Thanks
Uwe
--
Pengutronix e.K.
On Thu, Aug 22, 2019 at 02:58:35PM +0800, Sam Shih wrote:
> Use pwm_mediatek as common prefix to match the filename.
> No functional change intended.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Sam Shih
> ---
> Changes since v5:
> - Follow reviewers's comments
> The license stuff is a separate
On Thu, Aug 22, 2019 at 02:58:34PM +0800, Sam Shih wrote:
> Instead of using fixed size of arrays, allocate the memory for them
> based on the information we get from the DT.
>
> Also remove the check for num_pwms, due to dynamically allocate pwm
> should not cause array index out of bound.
>
> S
Hello Sam,
On Thu, Aug 22, 2019 at 02:58:33PM +0800, Sam Shih wrote:
> This fix mt7628 pwm during configure from userspace. The SoC
> is legacy MIPS and has no complex clock tree. This patch add property
> clock-frequency to the SoC specific data and legacy MIPS SoC need to
> configure it in DT. T
The Real-Time Summit is organized by the Linux Foundation Real-Time Linux (RTL)
collaborative project. The event is intended to gather developers and users of
Linux as a Real-Time Operating System. The main intent is to provide room for
discussion between developers, tooling experts, and users.
Th
On Thu, 22 Aug 2019, David Abdurachmanov wrote:
> There is one failing kernel selftest: global.user_notification_signal
Is this the only failing test? Or are the rest of the selftests skipped
when this test fails, and no further tests are run, as seems to be shown
here:
https://lore.kernel
Thanks for fixing this problem. I didn't realize it because I usually use a
buffer size >= the default ETR buffer size, which is harder to reproduce the
problem.
The patches LGTM, maybe you also want to fix the problem commented by Leo Yan.
I tested the patches by recording etm data with a buffer s
On Thu, Aug 22, 2019 at 02:58:31PM +0800, Sam Shih wrote:
> From: Ryder Lee
>
> This adds a property "num-pwms" to avoid having an endless
> list of compatibles with no differences for the same driver.
>
> Signed-off-by: Ryder Lee
> Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
Than
On Thu, Aug 22, 2019 at 02:58:32PM +0800, Sam Shih wrote:
> This patch drop the check for of_device_get_match_data.
> Due to the only way call driver probe is compatible match.
> The .data pointer which point to the SoC specify data is
> directly set by driver, and it should not be NULL in our case
If the CSI is unregistered and then registered again without the
driver being removed and re-probed (which will happen when the media
device is removed and re-probed without also removing/re-probing the
CSI), the result is the kobject error and backtrace "tried to init an
initialized object". This
If a subdevice is unregistered and then registered again without the
driver being removed and re-probed (which will happen when the media
device is removed and re-probed without also removing/re-probing the
subdevice), media_device_register_entity() is called with a non-zero
entity->num_pads, and t
The devicetree specification recommends using generic node names.
Some ZII dts files already follow such recommendation, but some don't,
so use generic node names for consistency among the ZII dts files.
Signed-off-by: Andrey Smirnov
Cc: Shawn Guo
Cc: Chris Healy
Cc: Cory Tusar
Cc: Fabio Este
Hello,
On Tue, Aug 20, 2019 at 05:56:40AM +, Anson Huang wrote:
> Gentle ping...
My impression[1] is that Thierry collects patches in bulk once or twice
per release cycle. The last two such bulks were between 5.2-rc6 and
5.2-rc7 and in the 5.2 merge window. So given we're at v5.3-rc5 now I
ex
Configure IRQ line for SX1503 GPIO expander. We already have
appropriate pinmux entry and all that is missing is "interrupt-parent"
and "interrupts" properties. Add them.
Signed-off-by: Andrey Smirnov
Cc: Shawn Guo
Cc: Chris Healy
Cc: Cory Tusar
Cc: Fabio Estevam
Cc: linux-arm-ker...@lists.in
On Fri, 23 Aug 2019, Andy Lutomirski wrote:
> > On Aug 23, 2019, at 5:03 PM, Thomas Gleixner wrote:
> >
> >> On Sat, 24 Aug 2019, Thomas Gleixner wrote:
> >> On Fri, 23 Aug 2019, Andy Lutomirski wrote:
> On Aug 23, 2019, at 4:44 PM, Thomas Gleixner wrote:
>
> >> On Sat, 24 Aug 201
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月23日 21:39
> To: Xiaowei Bao
> Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.co; a...@arndb.de; gre...@linuxfoundation.org; M.h.
> Lian ;
On Fri, Aug 23, 2019 at 10:15:04AM -0700, Ira Weiny wrote:
> On Fri, Aug 23, 2019 at 10:59:14AM +1000, Dave Chinner wrote:
> > On Wed, Aug 21, 2019 at 11:02:00AM -0700, Ira Weiny wrote:
> > > On Tue, Aug 20, 2019 at 08:55:15AM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Aug 20, 2019 at 11:12:10AM
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月23日 22:28
> To: Xiaowei Bao
> Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.co; a...@arndb.de; gre...@linuxfoundation.org; M.h.
> Lian ;
>>>Subject: Re: [PATCH 3/3] nvme: complete request in work queue on CPU
>>>with flooded interrupts
>>>
>>>
Sagi,
Here are the test results.
Benchmark command:
fio --bs=4k --ioengine=libaio --iodepth=64
--
>>>filename=/dev/nvme0n1:/dev/nvme1n1:/dev/nvme2n1:/dev/nvm
> On Aug 23, 2019, at 5:03 PM, Thomas Gleixner wrote:
>
>> On Sat, 24 Aug 2019, Thomas Gleixner wrote:
>> On Fri, 23 Aug 2019, Andy Lutomirski wrote:
On Aug 23, 2019, at 4:44 PM, Thomas Gleixner wrote:
>> On Sat, 24 Aug 2019, Thomas Gleixner wrote:
>> On Sun, 28 Jul 2019, S
On Fri, Aug 23, 2019 at 09:04:29AM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 23, 2019 at 01:23:45PM +1000, Dave Chinner wrote:
>
> > > But the fact that RDMA, and potentially others, can "pass the
> > > pins" to other processes is something I spent a lot of time trying to
> > > work out.
> >
>
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月23日 21:58
> To: Xiaowei Bao
> Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.co; a...@arndb.de; gre...@linuxfoundation.org; M.h.
> Lian ;
On Fri, 2019-08-23 at 20:13 +0200, Dietmar Eggemann wrote:
>
>
> > @@ -1668,7 +1668,7 @@ static void task_numa_compare(struct
> > task_numa_env *env,
> > /*
> > * In the overloaded case, try and keep the load balanced.
> > */
> > - load = task_h_load(env->p) - task_h_load(cur);
>
On Sat, 24 Aug 2019, Thomas Gleixner wrote:
> On Fri, 23 Aug 2019, Andy Lutomirski wrote:
> > > On Aug 23, 2019, at 4:44 PM, Thomas Gleixner wrote:
> > >
> > >> On Sat, 24 Aug 2019, Thomas Gleixner wrote:
> > >>> On Sun, 28 Jul 2019, Sebastian Mayr wrote:
> > >>>
> > >>> -static inline int sizeo
On Fri, 23 Aug 2019, Andy Lutomirski wrote:
> > On Aug 23, 2019, at 4:44 PM, Thomas Gleixner wrote:
> >
> >> On Sat, 24 Aug 2019, Thomas Gleixner wrote:
> >>> On Sun, 28 Jul 2019, Sebastian Mayr wrote:
> >>>
> >>> -static inline int sizeof_long(void)
> >>> +static inline int sizeof_long(struct p
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月23日 21:45
> To: Xiaowei Bao
> Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.co; a...@arndb.de; gre...@linuxfoundation.org; M.h.
> Lian ;
> On Aug 23, 2019, at 4:44 PM, Thomas Gleixner wrote:
>
>> On Sat, 24 Aug 2019, Thomas Gleixner wrote:
>>> On Sun, 28 Jul 2019, Sebastian Mayr wrote:
>>>
>>> -static inline int sizeof_long(void)
>>> +static inline int sizeof_long(struct pt_regs *regs)
>>> {
>>> -return in_ia32_syscall() ?
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月23日 21:36
> To: Xiaowei Bao
> Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.co; a...@arndb.de; gre...@linuxfoundation.org; M.h.
> Lian ;
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月23日 21:25
> To: Xiaowei Bao
> Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.co; a...@arndb.de; gre...@linuxfoundation.org; M.h.
> Lian ;
On Sat, 24 Aug 2019, Thomas Gleixner wrote:
> On Sun, 28 Jul 2019, Sebastian Mayr wrote:
>
> > -static inline int sizeof_long(void)
> > +static inline int sizeof_long(struct pt_regs *regs)
> > {
> > - return in_ia32_syscall() ? 4 : 8;
>
> This wants a comment.
>
> > + return user_64bit_mo
Sebastian,
On Sun, 28 Jul 2019, Sebastian Mayr wrote:
sorry for the delay..
> 32-bit processes running on a 64-bit kernel are not always detected
> correctly, causing the process to crash when uretprobes are installed.
> The reason for the crash is that in_ia32_syscall() is used to determine
> t
On Fri, Aug 16, 2019 at 05:47:26PM -0700, Roman Gushchin wrote:
> Commit 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync
> with the hierarchical ones") effectively decreased the precision of
> per-memcg vmstats_local and per-memcg-per-node lruvec percpu counters.
>
> That's good for
From: Kuppuswamy Sathyanarayanan
As per ACPI specification r6.3, sec 5.6.6, when firmware owns Downstream
Port Containment (DPC), its expected to use the "Error Disconnect
Recover" (EDR) notification to alert OSPM of a DPC event and if OS
supports EDR, its expected to handle the software state in
From: Kuppuswamy Sathyanarayanan
As per ACPI specification v6.3, sec 5.6.6, Error Disconnect Recover
(EDR) notification used by firmware to let OS know about the DPC event
and permit OS to perform error recovery when processing the EDR
notification. Also, as per PCI firmware specification r3.2 Do
1 - 100 of 849 matches
Mail list logo
