On 10/02/2018 10:39 PM, Lance Roy wrote:
> lockdep_assert_held() is better suited to checking locking requirements,
> since it won't get confused when someone else holds the lock. This is
> also a step towards possibly removing spin_is_locked().
>
> Signed-off-by: Lance Roy
> Cc: John Johansen
On 10/02/2018 10:39 PM, Lance Roy wrote:
> lockdep_assert_held() is better suited to checking locking requirements,
> since it won't get confused when someone else holds the lock. This is
> also a step towards possibly removing spin_is_locked().
>
> Signed-off-by: Lance Roy
> Cc: John Johansen
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Bjorn Helgaas
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Bjorn Helgaas
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Alexander Viro
Cc:
---
fs/userfaultfd.c | 2 +-
1 file changed, 1
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Alexander Viro
Cc:
---
fs/userfaultfd.c | 2 +-
1 file changed, 1
On 10/1/18 7:35 AM, Dennis Dalessandro wrote:
> On 9/28/2018 11:12 PM, John Hubbard wrote:
>> On 9/28/18 8:39 AM, Jason Gunthorpe wrote:
>>> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
>> [...]
diff --git
On 10/1/18 7:35 AM, Dennis Dalessandro wrote:
> On 9/28/2018 11:12 PM, John Hubbard wrote:
>> On 9/28/18 8:39 AM, Jason Gunthorpe wrote:
>>> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
>> [...]
diff --git
One of the main uses of spin_is_locked() is to require that a lock is held when
a function is called, for debugging, but lockdep_assert_held() is better for
this purpose since it won't make a mistake when someone else is holding the
lock. This patch series replaces all of this kind of use of
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Daniel Drake
Cc: Ulrich Kunitz
Cc: Kalle Valo
Cc: "David S.
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Cc:
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc:
One of the main uses of spin_is_locked() is to require that a lock is held when
a function is called, for debugging, but lockdep_assert_held() is better for
this purpose since it won't make a mistake when someone else is holding the
lock. This patch series replaces all of this kind of use of
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Daniel Drake
Cc: Ulrich Kunitz
Cc: Kalle Valo
Cc: "David S.
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Cc:
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc:
Hello Arnd,
On Tue, Oct 02, 2018 at 11:07:32PM +0200, Arnd Bergmann wrote:
> gcc points out that a pointer is longer than an int on 64-bit
> architectures, and that casting between the two may be dangerous:
>
> drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
>
Hello Arnd,
On Tue, Oct 02, 2018 at 11:07:32PM +0200, Arnd Bergmann wrote:
> gcc points out that a pointer is longer than an int on 64-bit
> architectures, and that casting between the two may be dangerous:
>
> drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
>
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Steve Glendinning
Cc: "David S. Miller"
Cc:
---
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc:
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Darren
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Yang Shi
Cc: Matthew
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: John Johansen
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc:
---
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Cliff Whickman
Cc: Robin Holt
Cc: Arnd Bergmann
Cc: Greg
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Cliff Whickman
Cc: Robin Holt
Cc: Arnd Bergmann
Cc: Greg
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Steve Glendinning
Cc: "David S. Miller"
Cc:
---
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc:
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Darren
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Yang Shi
Cc: Matthew
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: John Johansen
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc:
---
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
arch/c6x/kernel/setup.c
between commit:
31b02fe54206 ("c6x: switch to NO_BOOTMEM")
from the c6x tree and commit:
be7cd2df1d22 ("c6x: use common built-in dtb support")
from the devicetree tree.
I fixed it up
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
arch/c6x/kernel/setup.c
between commit:
31b02fe54206 ("c6x: switch to NO_BOOTMEM")
from the c6x tree and commit:
be7cd2df1d22 ("c6x: use common built-in dtb support")
from the devicetree tree.
I fixed it up
On Wed, 3 Oct 2018, Eric W. Biederman wrote:
> Direct access to hardware/drivers and not through an abstraction like
> the vfs (an abstraction over block devices) can legitimately be handled
> by hotplug events. I unplug one keyboard I plug in another.
>
> I don't know if the input layer is more
On Wed, 3 Oct 2018, Eric W. Biederman wrote:
> Direct access to hardware/drivers and not through an abstraction like
> the vfs (an abstraction over block devices) can legitimately be handled
> by hotplug events. I unplug one keyboard I plug in another.
>
> I don't know if the input layer is more
On Tue, Oct 2, 2018 at 9:41 PM Viresh Kumar wrote:
>
> On 01-10-18, 13:21, Dmitry Torokhov wrote:
> > RK3399 has one cluster with 4 small cores, and another one with 2 big
> > cores, with cores in different clusters having different OPPs and thus
> > different policies. Let's enable this via
On Tue, Oct 2, 2018 at 9:41 PM Viresh Kumar wrote:
>
> On 01-10-18, 13:21, Dmitry Torokhov wrote:
> > RK3399 has one cluster with 4 small cores, and another one with 2 big
> > cores, with cores in different clusters having different OPPs and thus
> > different policies. Let's enable this via
In stm_char_policy_set_ioctl(), the 'size' field of the struct
'stp_polic_id' is firstly copied from the user space and then checked,
because the length of the 'id' field in this struct, which represents an
identification string, is not fixed. If the 'size' field cannot pass the
check, an error
In stm_char_policy_set_ioctl(), the 'size' field of the struct
'stp_polic_id' is firstly copied from the user space and then checked,
because the length of the 'id' field in this struct, which represents an
identification string, is not fixed. If the 'size' field cannot pass the
check, an error
Thomas Gleixner writes:
> On Tue, 2 Oct 2018, Arnd Bergmann wrote:
>> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
>> >
>> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
>> > > In the context of process migration there is a simpler subproblem that I
>> > > think it is worth exploring
Thomas Gleixner writes:
> On Tue, 2 Oct 2018, Arnd Bergmann wrote:
>> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
>> >
>> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
>> > > In the context of process migration there is a simpler subproblem that I
>> > > think it is worth exploring
On 01-10-18, 13:21, Dmitry Torokhov wrote:
> RK3399 has one cluster with 4 small cores, and another one with 2 big
> cores, with cores in different clusters having different OPPs and thus
> different policies. Let's enable this via "have_governor_per_policy"
> platform data.
The policies are
On 01-10-18, 13:21, Dmitry Torokhov wrote:
> RK3399 has one cluster with 4 small cores, and another one with 2 big
> cores, with cores in different clusters having different OPPs and thus
> different policies. Let's enable this via "have_governor_per_policy"
> platform data.
The policies are
ld again.
I have no idea.
Is it fine if you use kbuild tree from the last week?
I added 4 kbuild patches this week, but they look irrelevant.
masahiro@pug:~/ref/linux-next$ git log --oneline
next-20180928..next-20181002 | grep kbuild
4712eca8 Merge remote-tracking branch 'kbuild/for-next'
ae
ld again.
I have no idea.
Is it fine if you use kbuild tree from the last week?
I added 4 kbuild patches this week, but they look irrelevant.
masahiro@pug:~/ref/linux-next$ git log --oneline
next-20180928..next-20181002 | grep kbuild
4712eca8 Merge remote-tracking branch 'kbuild/for-next'
ae
On Tue, Oct 2, 2018 at 1:21 AM Nikola Ciprich
wrote:
>
> Hi Greg and others,
>
> sorry for reporting this so late, but still...
>
> this breaks build on older compilers, since it requires
> -mindirect-branch=thunk-inline -mindirect-branch-register even though
> retpoline support is disabled in
On Tue, Oct 2, 2018 at 1:21 AM Nikola Ciprich
wrote:
>
> Hi Greg and others,
>
> sorry for reporting this so late, but still...
>
> this breaks build on older compilers, since it requires
> -mindirect-branch=thunk-inline -mindirect-branch-register even though
> retpoline support is disabled in
When I fixed the vDSO build to use inline retpolines, I messed up
the Makefile logic and made it unconditional. It should have
depended on CONFIG_RETPOLINE and on the availability of compiler
support. This broke the build on some older compilers.
Fixes: 2e549b2ee0e3 ("x86/vdso: Fix vDSO build
When I fixed the vDSO build to use inline retpolines, I messed up
the Makefile logic and made it unconditional. It should have
depended on CONFIG_RETPOLINE and on the availability of compiler
support. This broke the build on some older compilers.
Fixes: 2e549b2ee0e3 ("x86/vdso: Fix vDSO build
Hi Masahiro,
I don't know if that has anything to changes in the kbuild system, but
since Tuesday, I have been getting random build errors that go away after
I remove the object directory and build again. The latest example is this:
include/linux/kconfig.h: file not recognized: file format not
Hi Masahiro,
I don't know if that has anything to changes in the kbuild system, but
since Tuesday, I have been getting random build errors that go away after
I remove the object directory and build again. The latest example is this:
include/linux/kconfig.h: file not recognized: file format not
On 10/02/2018 09:02 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2018 at 09:39:49AM +0200, Milian Wolff escreveu:
>> Only use the mapped IP to find inline frames, but keep
>> using the unmapped IP for the callchain cursor. This
>> ensures we properly show the unmapped IP when
On 10/02/2018 09:02 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2018 at 09:39:49AM +0200, Milian Wolff escreveu:
>> Only use the mapped IP to find inline frames, but keep
>> using the unmapped IP for the callchain cursor. This
>> ensures we properly show the unmapped IP when
Christoph Hellwig 於 2018年10月2日 週二 下午10:51寫道：
>
> On Tue, Oct 02, 2018 at 04:52:31PM +0800, Zong Li wrote:
> > From: Vincent Chen
> >
> > For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
> > after AND with PAGE_MASK because the data type of PAGE_MASK is
> > unsigned long. To fix
Christoph Hellwig 於 2018年10月2日 週二 下午10:51寫道：
>
> On Tue, Oct 02, 2018 at 04:52:31PM +0800, Zong Li wrote:
> > From: Vincent Chen
> >
> > For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
> > after AND with PAGE_MASK because the data type of PAGE_MASK is
> > unsigned long. To fix
Add umoddi3 and udivmoddi4 support for 32-bit.
The RV32 need the umoddi3 to do modulo when the operands are long long
type, like other libraries implementation such as ucmpdi2, lshrdi3 and
so on.
I encounter the undefined reference 'umoddi3' when I use the in
house dma driver, although it is in
On RV32, it will use the __umoddi3. Select GENERIC_LIB_UMODDI3 to avoid
undefined reference.
Signed-off-by: Zong Li
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a344980..dc262fa 100644
--- a/arch/riscv/Kconfig
+++
Add umoddi3 and udivmoddi4 support for 32-bit.
The RV32 need the umoddi3 to do modulo when the operands are long long
type, like other libraries implementation such as ucmpdi2, lshrdi3 and
so on.
I encounter the undefined reference 'umoddi3' when I use the in
house dma driver, although it is in
On RV32, it will use the __umoddi3. Select GENERIC_LIB_UMODDI3 to avoid
undefined reference.
Signed-off-by: Zong Li
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a344980..dc262fa 100644
--- a/arch/riscv/Kconfig
+++
Only RV64 supports 128 integer size.
Signed-off-by: Zong Li
---
arch/riscv/lib/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 445ec84..5739bd0 100644
--- a/arch/riscv/lib/Makefile
+++
This patches contain the modificaion as follows:
1. Fix up the building fail on RV32.
2. Add umoddi3 and udivmoddi4 functions for RV32.
3. Fix ioremap problem on RV32.
Thanks all for review these code and modify the copyright description.
Changes in v4:
- Retain the complete copyright
On RV32, it doesn't select the SWIOTLB, only RV64 support swiotlb now.
Signed-off-by: Zong Li
---
arch/riscv/kernel/setup.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index aee6031..6de6584 100644
--- a/arch/riscv/kernel/setup.c
From: Vincent Chen
For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
after AND with PAGE_MASK because the data type of PAGE_MASK is
unsigned long. To fix this problem, the page alignment is done by
subtracting the page offset instead of AND with PAGE_MASK.
Signed-off-by:
Only RV64 supports 128 integer size.
Signed-off-by: Zong Li
---
arch/riscv/lib/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 445ec84..5739bd0 100644
--- a/arch/riscv/lib/Makefile
+++
This patches contain the modificaion as follows:
1. Fix up the building fail on RV32.
2. Add umoddi3 and udivmoddi4 functions for RV32.
3. Fix ioremap problem on RV32.
Thanks all for review these code and modify the copyright description.
Changes in v4:
- Retain the complete copyright
On RV32, it doesn't select the SWIOTLB, only RV64 support swiotlb now.
Signed-off-by: Zong Li
---
arch/riscv/kernel/setup.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index aee6031..6de6584 100644
--- a/arch/riscv/kernel/setup.c
From: Vincent Chen
For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero
after AND with PAGE_MASK because the data type of PAGE_MASK is
unsigned long. To fix this problem, the page alignment is done by
subtracting the page offset instead of AND with PAGE_MASK.
Signed-off-by:
On Mon, 1 Oct 2018 11:48:55 -0400
Steven Rostedt wrote:
> On Thu, 27 Sep 2018 19:48:58 +0900
> Masami Hiramatsu wrote:
>
> > Hello Steve,
> >
> > Could you also include this series to the branch?
> >
>
> Hi Masami,
>
> I just came back from Embedded / Kernel Recipes, I'll look at these
On Mon, 1 Oct 2018 11:48:55 -0400
Steven Rostedt wrote:
> On Thu, 27 Sep 2018 19:48:58 +0900
> Masami Hiramatsu wrote:
>
> > Hello Steve,
> >
> > Could you also include this series to the branch?
> >
>
> Hi Masami,
>
> I just came back from Embedded / Kernel Recipes, I'll look at these
On Sat, 29 Sep 2018 17:22:13 +0800
王晓东 wrote:
> Hi there,
>
> We would like to report a kernel stack corrupted problem we identified
> in the perf_trace_rcu_dyntick function of tracing events subsystem.
> And the problem was founded by syzkaller. We has tested the PoC on
> the lasted master
On Sat, 29 Sep 2018 17:22:13 +0800
王晓东 wrote:
> Hi there,
>
> We would like to report a kernel stack corrupted problem we identified
> in the perf_trace_rcu_dyntick function of tracing events subsystem.
> And the problem was founded by syzkaller. We has tested the PoC on
> the lasted master
Hi Leonard,
On Tue, Oct 2, 2018 at 3:42 PM Leonard Crestez wrote:
> @@ -371,10 +372,12 @@
> MX6SX_PAD_RGMII1_RD1__ENET1_RX_DATA_1 0x3081
> MX6SX_PAD_RGMII1_RD2__ENET1_RX_DATA_2 0x3081
>
Hi Leonard,
On Tue, Oct 2, 2018 at 3:42 PM Leonard Crestez wrote:
> @@ -371,10 +372,12 @@
> MX6SX_PAD_RGMII1_RD1__ENET1_RX_DATA_1 0x3081
> MX6SX_PAD_RGMII1_RD2__ENET1_RX_DATA_2 0x3081
>
On Mon, Sep 10, 2018 at 09:16:12PM +0530, Souptick Joarder wrote:
> Return type of ext4_page_mkwrite and ext4_filemap_fault are
> changed to use vm_fault_t type.
>
> With this patch all the callers of block_page_mkwrite_return()
> are changed to handle vm_fault_t. So converting the return type
>
On Mon, Sep 10, 2018 at 09:16:12PM +0530, Souptick Joarder wrote:
> Return type of ext4_page_mkwrite and ext4_filemap_fault are
> changed to use vm_fault_t type.
>
> With this patch all the callers of block_page_mkwrite_return()
> are changed to handle vm_fault_t. So converting the return type
>
On 10/02/2018 06:09 PM, Michal Hocko wrote:
> On Tue 02-10-18 17:45:28, Anshuman Khandual wrote:
>> Architectures like arm64 have PUD level HugeTLB pages for certain configs
>> (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be
>> enabled for migration. It can be achieved
On 10/02/2018 06:09 PM, Michal Hocko wrote:
> On Tue 02-10-18 17:45:28, Anshuman Khandual wrote:
>> Architectures like arm64 have PUD level HugeTLB pages for certain configs
>> (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be
>> enabled for migration. It can be achieved
Hi Arnd, Olof,
Please hold on.
I've received a little more patches.
I will queue up them, and send a respin later on.
Thanks.
On Wed, Oct 3, 2018 at 8:47 AM Masahiro Yamada
wrote:
>
> Hi Arnd, Olof,
>
> Please pull UniPhier DT updates for the v4.20 MW.
>
> In this cycle, I queued up all
Hi Arnd, Olof,
Please hold on.
I've received a little more patches.
I will queue up them, and send a respin later on.
Thanks.
On Wed, Oct 3, 2018 at 8:47 AM Masahiro Yamada
wrote:
>
> Hi Arnd, Olof,
>
> Please pull UniPhier DT updates for the v4.20 MW.
>
> In this cycle, I queued up all
Hello
Please i still await your response regarding my previous email.
Hello
Please i still await your response regarding my previous email.
G'day Song,
Noticed a one more thing below
On 2/10/2018 10:38 PM, Song Qiang wrote:
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with a MagI2C
interface.
Following functions are available:
- Single-shot measurement
G'day Song,
Noticed a one more thing below
On 2/10/2018 10:38 PM, Song Qiang wrote:
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with a MagI2C
interface.
Following functions are available:
- Single-shot measurement
Hello
Please i still await your response regarding my previous email.
Hello
Please i still await your response regarding my previous email.
Palmer Dabbelt 於 2018年10月2日 週二 下午11:02寫道：
>
> On Tue, 02 Oct 2018 07:50:41 PDT (-0700), Christoph Hellwig wrote:
> >> The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other
> >> functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and
> >> udivmoddi4 for flexible
Palmer Dabbelt 於 2018年10月2日 週二 下午11:02寫道：
>
> On Tue, 02 Oct 2018 07:50:41 PDT (-0700), Christoph Hellwig wrote:
> >> The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other
> >> functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and
> >> udivmoddi4 for flexible
This kernel parameter allows the modification of the padding used
for the physical memory mapping section when KASLR memory is enabled.
For memory hotplug capable systems, the default padding size,
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, may not be enough.
The option is useful to adjust the
This kernel parameter allows the modification of the padding used
for the physical memory mapping section when KASLR memory is enabled.
For memory hotplug capable systems, the default padding size,
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, may not be enough.
The option is useful to adjust the
If each node of physical memory layout has huge space for hotplug,
the padding used for the physical memory mapping section is not enough.
For exapmle of the layout:
SRAT: Node 6 PXM 4 [mem 0x1000-0x13ff] hotplug
SRAT: Node 7 PXM 5 [mem 0x1400-0x17ff] hotplug
If each node of physical memory layout has huge space for hotplug,
the padding used for the physical memory mapping section is not enough.
For exapmle of the layout:
SRAT: Node 6 PXM 4 [mem 0x1000-0x13ff] hotplug
SRAT: Node 7 PXM 5 [mem 0x1400-0x17ff] hotplug
This patch series are adding an kernel parameter to change
the padding size used for KASLR. It is useful for memory hotplug
capable system. User can adjust the padding size to use it.
It is better if the padding size is calculated automatically,
however, ACPI SRAT is not available at the KASLR
Add warning message if the padding size for KASLR,
rand_mem_physical_padding, is not enough. The message also
says the suitable padding size.
Signed-off-by: Masayoshi Mizuma
---
drivers/acpi/numa.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/acpi/numa.c
This patch series are adding an kernel parameter to change
the padding size used for KASLR. It is useful for memory hotplug
capable system. User can adjust the padding size to use it.
It is better if the padding size is calculated automatically,
however, ACPI SRAT is not available at the KASLR
Add warning message if the padding size for KASLR,
rand_mem_physical_padding, is not enough. The message also
says the suitable padding size.
Signed-off-by: Masayoshi Mizuma
---
drivers/acpi/numa.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/acpi/numa.c
On Tue, 2 Oct 2018 17:15:17 -0700
Daniel Wang wrote:
> On Tue, Oct 2, 2018 at 1:42 AM Petr Mladek wrote:
> >
> > Well, I still wonder why it helped and why you do not see it with 4.4.
> > I have a feeling that the console owner switch helped only by chance.
> > In fact, you might be affected by
On Tue, 2 Oct 2018 17:15:17 -0700
Daniel Wang wrote:
> On Tue, Oct 2, 2018 at 1:42 AM Petr Mladek wrote:
> >
> > Well, I still wonder why it helped and why you do not see it with 4.4.
> > I have a feeling that the console owner switch helped only by chance.
> > In fact, you might be affected by
Hi Jacek,
On 3 October 2018 at 04:25, Jacek Anaszewski wrote:
> Hi Baolin,
>
> Thank you for the v14. We'll probably need v15, though :-)
>
> I added the comments in the code below.
>
> On 10/02/2018 05:43 PM, Baolin Wang wrote:
>> This patch adds one new led trigger that LED device can
Hi Jacek,
On 3 October 2018 at 04:25, Jacek Anaszewski wrote:
> Hi Baolin,
>
> Thank you for the v14. We'll probably need v15, though :-)
>
> I added the comments in the code below.
>
> On 10/02/2018 05:43 PM, Baolin Wang wrote:
>> This patch adds one new led trigger that LED device can
1 - 100 of 2384 matches
Mail list logo
