Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 11, 2018 at 07:40:26AM +0200, Dmitry Vyukov wrote: > On Fri, May 11, 2018 at 1:54 AM, Paolo Bonzini wrote: > > On 10/05/2018 21:16, Roman Kagan wrote: > >> If an IDR contains a single entry at index==0, the underlying radix tree > >> has a single item in its root

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 11, 2018 at 07:40:26AM +0200, Dmitry Vyukov wrote: > On Fri, May 11, 2018 at 1:54 AM, Paolo Bonzini wrote: > > On 10/05/2018 21:16, Roman Kagan wrote: > >> If an IDR contains a single entry at index==0, the underlying radix tree > >> has a single item in its root node, in which case >

Re: [PATCH] ARM: dts: imx51-zii-rdu1: fix touchscreen bindings

On Mon, May 07, 2018 at 04:53:09PM +0300, Nikita Yushchenko wrote: > This fixes errors in RDU1 device tree that cause touch screens not > working. > > Signed-off-by: Nikita Yushchenko Applied, thanks.

Re: [PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support

On Thu, May 10, 2018 at 10:43 PM, Jagan Teki wrote: > Amarula A64 Relic is Allwinner A64 based IoT device, which support > - Allwinner A64 Cortex-A53 > - Mali-400MP2 GPU > - AXP803 PMIC > - 1GB DDR3 RAM > - 8GB eMMC > - AP6330 Wifi/BLE > - MIPI-DSI > - CSI: OV5640

Re: [PATCH] ARM: dts: imx51-zii-rdu1: fix touchscreen bindings

On Mon, May 07, 2018 at 04:53:09PM +0300, Nikita Yushchenko wrote: > This fixes errors in RDU1 device tree that cause touch screens not > working. > > Signed-off-by: Nikita Yushchenko Applied, thanks.

Re: [PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support

On Thu, May 10, 2018 at 10:43 PM, Jagan Teki wrote: > Amarula A64 Relic is Allwinner A64 based IoT device, which support > - Allwinner A64 Cortex-A53 > - Mali-400MP2 GPU > - AXP803 PMIC > - 1GB DDR3 RAM > - 8GB eMMC > - AP6330 Wifi/BLE > - MIPI-DSI > - CSI: OV5640 sensor > - USB OTG > - 12V DC

Re: [PATCH 2/3] sched/fair: util_est: update before schedutil

On 10-05-18, 16:05, Patrick Bellasi wrote: > When a task is enqueue the estimated utilization of a CPU is updated > to better support the selection of the required frequency. > However, schedutil is (implicitly) updated by update_load_avg() which > always happens before util_est_{en,de}queue(),

Re: [PATCH 2/3] sched/fair: util_est: update before schedutil

On 10-05-18, 16:05, Patrick Bellasi wrote: > When a task is enqueue the estimated utilization of a CPU is updated > to better support the selection of the required frequency. > However, schedutil is (implicitly) updated by update_load_avg() which > always happens before util_est_{en,de}queue(),

Re: [PATCH 1/3] sched/cpufreq: always consider blocked FAIR utilization

On 10-05-18, 16:05, Patrick Bellasi wrote: > Since the refactoring introduced by: > >commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") > > we aggregate FAIR utilization only if this class has runnable tasks. > This was mainly due to avoid the risk to stay on an high

Re: [PATCH 1/3] sched/cpufreq: always consider blocked FAIR utilization

On 10-05-18, 16:05, Patrick Bellasi wrote: > Since the refactoring introduced by: > >commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") > > we aggregate FAIR utilization only if this class has runnable tasks. > This was mainly due to avoid the risk to stay on an high

Re: [PATCH 3/3] sched/fair: schedutil: explicit update only when required

On 10-05-18, 16:05, Patrick Bellasi wrote: > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > -static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct > sched_entity *se, int flags) > +static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct > sched_entity *se) > { >

[PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support

Amarula A64 Relic is Allwinner A64 based IoT device, which support - Allwinner A64 Cortex-A53 - Mali-400MP2 GPU - AXP803 PMIC - 1GB DDR3 RAM - 8GB eMMC - AP6330 Wifi/BLE - MIPI-DSI - CSI: OV5640 sensor - USB OTG - 12V DC power supply Signed-off-by: Jagan Teki ---

Re: [PATCH 3/3] sched/fair: schedutil: explicit update only when required

On 10-05-18, 16:05, Patrick Bellasi wrote: > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > -static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct > sched_entity *se, int flags) > +static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct > sched_entity *se) > { >

[PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support

Amarula A64 Relic is Allwinner A64 based IoT device, which support - Allwinner A64 Cortex-A53 - Mali-400MP2 GPU - AXP803 PMIC - 1GB DDR3 RAM - 8GB eMMC - AP6330 Wifi/BLE - MIPI-DSI - CSI: OV5640 sensor - USB OTG - 12V DC power supply Signed-off-by: Jagan Teki --- Changes for v2: - Rename dts

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 11, 2018 at 1:54 AM, Paolo Bonzini wrote: > On 10/05/2018 21:16, Roman Kagan wrote: >> If an IDR contains a single entry at index==0, the underlying radix tree >> has a single item in its root node, in which case >> __radix_tree_lookup(index!=0) doesn't set its

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 11, 2018 at 1:54 AM, Paolo Bonzini wrote: > On 10/05/2018 21:16, Roman Kagan wrote: >> If an IDR contains a single entry at index==0, the underlying radix tree >> has a single item in its root node, in which case >> __radix_tree_lookup(index!=0) doesn't set its *@nodep argument (in >>

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

On Fri, 11 May 2018, Michael Schmitz wrote: > > I'm afraid using platform_device_register() (which you already use for > the SCC devices) is the only option handling this on a per-device basis > without touching platform core code, while at the same time keeping the > DMA mask setup out of

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

On Fri, 11 May 2018, Michael Schmitz wrote: > > I'm afraid using platform_device_register() (which you already use for > the SCC devices) is the only option handling this on a per-device basis > without touching platform core code, while at the same time keeping the > DMA mask setup out of

Re: [PATCH 1/3] x86/platform/UV: Add adjustable set memory block size function

On Thu, May 10, 2018 at 06:18:33PM -0500, mike.tra...@hpe.com wrote: > Add a new function to "adjust" the current fixed UV memory block size of > 2GB so it can be changed to a different physical boundary. This is out > of necessity so UV BIOS can accommodate Intel BIOS changes for NVDIMM's, >

Re: [PATCH 1/3] x86/platform/UV: Add adjustable set memory block size function

On Thu, May 10, 2018 at 06:18:33PM -0500, mike.tra...@hpe.com wrote: > Add a new function to "adjust" the current fixed UV memory block size of > 2GB so it can be changed to a different physical boundary. This is out > of necessity so UV BIOS can accommodate Intel BIOS changes for NVDIMM's, >

Re: [PATCH 2/3] x86/platform/UV: Use new set memory block size function

On Thu, May 10, 2018 at 06:18:34PM -0500, mike.tra...@hpe.com wrote: > Add a call to the new function to "adjust" the current fixed UV memory > block size of 2GB so it can be changed to a different physical boundary. > This accommodates changes in the Intel BIOS, and therefore UV BIOS, which > now

Re: [PATCH 2/3] x86/platform/UV: Use new set memory block size function

On Thu, May 10, 2018 at 06:18:34PM -0500, mike.tra...@hpe.com wrote: > Add a call to the new function to "adjust" the current fixed UV memory > block size of 2GB so it can be changed to a different physical boundary. > This accommodates changes in the Intel BIOS, and therefore UV BIOS, which > now

Re: [PATCH 3/3] x86/platform/UV: Add kernel parameter to set memory block size

On Thu, May 10, 2018 at 06:18:35PM -0500, mike.tra...@hpe.com wrote: > Add a kernel parameter that allows setting UV memory block size. This > is to provide an adjustment for new forms of PMEM and other DIMM memory > that might require alignment restrictions other than scanning the global >

KASAN: use-after-free Read in cma_cancel_operation

We report the crash: KASAN: use-after-free Read in cma_cancel_operation Note that this bug is previously reported by syzkaller. https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b Nonetheless, this bug has not fixed yet, and we hope that this report and our analysis,

Re: [PATCH 3/3] x86/platform/UV: Add kernel parameter to set memory block size

On Thu, May 10, 2018 at 06:18:35PM -0500, mike.tra...@hpe.com wrote: > Add a kernel parameter that allows setting UV memory block size. This > is to provide an adjustment for new forms of PMEM and other DIMM memory > that might require alignment restrictions other than scanning the global >

KASAN: use-after-free Read in cma_cancel_operation

We report the crash: KASAN: use-after-free Read in cma_cancel_operation Note that this bug is previously reported by syzkaller. https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b Nonetheless, this bug has not fixed yet, and we hope that this report and our analysis,

Re: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

On Thu, May 10, 2018 at 06:18:32PM -0500, mike.tra...@hpe.com wrote: > > Update support for the UV kernel to accommodate Intel BIOS changes in > NVDIMM alignment, which caused UV BIOS to align the memory boundaries > on different blocks than the previous UV standard of 2GB. > > -- This is

Re: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

On Thu, May 10, 2018 at 06:18:32PM -0500, mike.tra...@hpe.com wrote: > > Update support for the UV kernel to accommodate Intel BIOS changes in > NVDIMM alignment, which caused UV BIOS to align the memory boundaries > on different blocks than the previous UV standard of 2GB. > > -- This is

KASAN: null-ptr-deref Read in rds_ib_get_mr

We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr Note that this bug is previously reported by syzkaller. https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91 Nonetheless, this bug has not fixed yet, and we hope that this report and our analysis, which gets

KASAN: null-ptr-deref Read in rds_ib_get_mr

We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr Note that this bug is previously reported by syzkaller. https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91 Nonetheless, this bug has not fixed yet, and we hope that this report and our analysis, which gets

Re: [PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available

"Alastair D'Silva" writes: > diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h > index 8d2748e69c84..bb80f294b429 100644 > --- a/include/uapi/misc/ocxl.h > +++ b/include/uapi/misc/ocxl.h > @@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd { > #define

Re: [PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available

"Alastair D'Silva" writes: > diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h > index 8d2748e69c84..bb80f294b429 100644 > --- a/include/uapi/misc/ocxl.h > +++ b/include/uapi/misc/ocxl.h > @@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd { > #define OCXL_IOCTL_IRQ_SET_FD

Re: nds32 build failures

Hi Arnd: I am GCC guy from Andes, we've missed the release schedule for GCC 8, we didn't upstream the Linux support on time. Our plan is put our GCC 8 on github and continue commit rest patches to upstream. And we'll put our source on github after our internal testing done. Thanks. On Fri, May

Re: nds32 build failures

Hi Arnd: I am GCC guy from Andes, we've missed the release schedule for GCC 8, we didn't upstream the Linux support on time. Our plan is put our GCC 8 on github and continue commit rest patches to upstream. And we'll put our source on github after our internal testing done. Thanks. On Fri, May

Re: [PATCH v3 02/14] drivers: soc: sunxi: Add dedicated compatibles for the A13, A20 and A33

On Mon, May 7, 2018 at 5:44 AM, Paul Kocialkowski wrote: > This introduces platform-specific compatibles for the A13, A20 and A33 > SRAM driver. No particular adaptation for these platforms is required at > this point, although this might become the case in the

Re: [PATCH v3 02/14] drivers: soc: sunxi: Add dedicated compatibles for the A13, A20 and A33

On Mon, May 7, 2018 at 5:44 AM, Paul Kocialkowski wrote: > This introduces platform-specific compatibles for the A13, A20 and A33 > SRAM driver. No particular adaptation for these platforms is required at > this point, although this might become the case in the future. > > Signed-off-by: Paul

Re: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to

Hi, Le 04/05/2018 à 04:09, Wan, Jane (Nokia - US/Sunnyvale) a écrit The following is the reposting of patch with v2 version indication based on comment on "[PATCH 1/2]" (also in the attachment). Subject: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to recover the contents of

Re: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to

Hi, Le 04/05/2018 à 04:09, Wan, Jane (Nokia - US/Sunnyvale) a écrit The following is the reposting of patch with v2 version indication based on comment on "[PATCH 1/2]" (also in the attachment). Subject: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to recover the contents of

Re: [PATCH v3 5/7] ocxl: Expose the thread_id needed for wait on POWER9

"Alastair D'Silva" writes: > diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h > index 0af83d80fb3e..8d2748e69c84 100644 > --- a/include/uapi/misc/ocxl.h > +++ b/include/uapi/misc/ocxl.h > @@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata { > __u64

Re: [PATCH v3 5/7] ocxl: Expose the thread_id needed for wait on POWER9

"Alastair D'Silva" writes: > diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h > index 0af83d80fb3e..8d2748e69c84 100644 > --- a/include/uapi/misc/ocxl.h > +++ b/include/uapi/misc/ocxl.h > @@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata { > __u64 reserved[13]; // Total of

Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

On Thu, 2018-05-10 at 23:26 +, Luis R. Rodriguez wrote: > On Wed, May 09, 2018 at 10:00:58PM -0400, Mimi Zohar wrote: > > On Wed, 2018-05-09 at 23:48 +, Luis R. Rodriguez wrote: > > > On Wed, May 09, 2018 at 06:06:57PM -0400, Mimi Zohar wrote: > > > > > > > > Yes, writing regdb as a

Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

On Thu, 2018-05-10 at 23:26 +, Luis R. Rodriguez wrote: > On Wed, May 09, 2018 at 10:00:58PM -0400, Mimi Zohar wrote: > > On Wed, 2018-05-09 at 23:48 +, Luis R. Rodriguez wrote: > > > On Wed, May 09, 2018 at 06:06:57PM -0400, Mimi Zohar wrote: > > > > > > > > Yes, writing regdb as a

RE: [PATCH v2] z3fold: fix reclaim lock-ups

A headless page also need to be set UNDER_RECLAIM in previous reply, but I missed it. --- mm/z3fold.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 5f659ab..8536a47 100644 --- a/mm/z3fold.c +++ b/mm/z3fold.c @@ -849,10 +849,10 @@ static int

RE: [PATCH v2] z3fold: fix reclaim lock-ups

A headless page also need to be set UNDER_RECLAIM in previous reply, but I missed it. --- mm/z3fold.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 5f659ab..8536a47 100644 --- a/mm/z3fold.c +++ b/mm/z3fold.c @@ -849,10 +849,10 @@ static int

[git pull] drm fixes for v4.17-rc5

Hi Linus, As last week seemed a bit slow, we got a few more fixes this week. The main stuff is 2 weeks of fixes for amdgpu, some missing bits of vega12 atom firmware support were added, and some power management fixes. Nouveau got two regression fixes for an DP MST deadlock and a random oops

[git pull] drm fixes for v4.17-rc5

Hi Linus, As last week seemed a bit slow, we got a few more fixes this week. The main stuff is 2 weeks of fixes for amdgpu, some missing bits of vega12 atom firmware support were added, and some power management fixes. Nouveau got two regression fixes for an DP MST deadlock and a random oops

Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

On Fri, May 11, 2018 at 01:24:42AM +, Dey, Megha wrote: > > Are you suggesting that the SIMD wrapper, will do what is currently being > done by the ' mcryptd_queue_worker ' function (assuming FPU is not disabled) > i.e dispatching the job to the inner algorithm? > > I have got rid of the

Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

On Fri, May 11, 2018 at 01:24:42AM +, Dey, Megha wrote: > > Are you suggesting that the SIMD wrapper, will do what is currently being > done by the ' mcryptd_queue_worker ' function (assuming FPU is not disabled) > i.e dispatching the job to the inner algorithm? > > I have got rid of the

Re: nds32 build failures

On 05/10/2018 07:40 PM, Arnd Bergmann wrote: On Wed, Apr 18, 2018 at 3:19 AM, Greentime Hu wrote: 2018-04-17 20:47 GMT+08:00 Arnd Bergmann : On Mon, Apr 16, 2018 at 11:06 AM, Greentime Hu wrote: 2018-04-16 11:58 GMT+08:00 Guenter Roeck

Re: nds32 build failures

On 05/10/2018 07:40 PM, Arnd Bergmann wrote: On Wed, Apr 18, 2018 at 3:19 AM, Greentime Hu wrote: 2018-04-17 20:47 GMT+08:00 Arnd Bergmann : On Mon, Apr 16, 2018 at 11:06 AM, Greentime Hu wrote: 2018-04-16 11:58 GMT+08:00 Guenter Roeck : This built failure is because the toolchain version

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Finn, Am 11.05.2018 um 15:28 schrieb Finn Thain: > On Fri, 11 May 2018, Michael Schmitz wrote: > Which begs the question: why can' you set up all Nubus bus devices' DMA masks in nubus_device_register(), or nubus_add_board()? >>> >>> I am expecting to see the same WARNING from the

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Finn, Am 11.05.2018 um 15:28 schrieb Finn Thain: > On Fri, 11 May 2018, Michael Schmitz wrote: > Which begs the question: why can' you set up all Nubus bus devices' DMA masks in nubus_device_register(), or nubus_add_board()? >>> >>> I am expecting to see the same WARNING from the

Re: [PATCH] ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level

Hello Andrew, On 05/11/2018 05:49 AM, Andrew Morton wrote: On Thu, 10 May 2018 13:32:30 +0800 Larry Chen wrote: ocfs2_inode_lock_tracker as a variant of ocfs2_inode_lock, is used to prevent deadlock due to recursive lock acquisition. But this function does not distinguish

Re: [PATCH] ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level

Hello Andrew, On 05/11/2018 05:49 AM, Andrew Morton wrote: On Thu, 10 May 2018 13:32:30 +0800 Larry Chen wrote: ocfs2_inode_lock_tracker as a variant of ocfs2_inode_lock, is used to prevent deadlock due to recursive lock acquisition. But this function does not distinguish whether the

Re: [PATCH] tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}

On 09/05/18 20:46, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > Doing an audit of trace events, I discovered two trace events in the xen > subsystem that use a hack to create zero data size trace events. This is not > what trace events are for. Trace events

Re: [PATCH] tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}

On 09/05/18 20:46, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > Doing an audit of trace events, I discovered two trace events in the xen > subsystem that use a hack to create zero data size trace events. This is not > what trace events are for. Trace events add memory footprint

Re: [PATCH 0/5] fix radix tree multi-order iteration race

On Thu, May 10, 2018 at 03:48:44PM -0700, Andrew Morton wrote: > so I think I'll just ignore all that and send this series off to Linus next > week. Great. Thank you, Andrew.

Re: [PATCH 0/5] fix radix tree multi-order iteration race

On Thu, May 10, 2018 at 03:48:44PM -0700, Andrew Morton wrote: > so I think I'll just ignore all that and send this series off to Linus next > week. Great. Thank you, Andrew.

Re: [GIT PULL] arm64: updates for 4.17

On Wed, Apr 4, 2018 at 9:32 AM, Will Deacon wrote: > Hi Linus, > > Please pull these arm64 updates for 4.17. Note that I've pulled in a > stable branch from Eric Biederman here to fulfil some siginfo dependencies, > so the diffstat strays slightly out of arm64 due to his

Re: [GIT PULL] arm64: updates for 4.17

On Wed, Apr 4, 2018 at 9:32 AM, Will Deacon wrote: > Hi Linus, > > Please pull these arm64 updates for 4.17. Note that I've pulled in a > stable branch from Eric Biederman here to fulfil some siginfo dependencies, > so the diffstat strays slightly out of arm64 due to his changes. {snip} > >

RE: cross-compiling a 64-bit kernel on a 32-bit host

> Subject: Re: cross-compiling a 64-bit kernel on a 32-bit host > > Hi Josh, > > CC LKP team. > > On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote: > >Hi Fengguang, > > > >I occasionally get compilation bug reports from people who are > >cross-compiling an x86-64 kernel target on

RE: cross-compiling a 64-bit kernel on a 32-bit host

> Subject: Re: cross-compiling a 64-bit kernel on a 32-bit host > > Hi Josh, > > CC LKP team. > > On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote: > >Hi Fengguang, > > > >I occasionally get compilation bug reports from people who are > >cross-compiling an x86-64 kernel target on

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 08:50:07PM +0100, Dmitry Safonov wrote: > random uses __ratelimit() which calls ___ratelimit() with a function > name. Depending on !RATELIMIT_MSG_ON_RELEASE it prints how many > messages were suppressed every ratelimit interval (1 second for random) > and flushes

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

On Thu, May 10, 2018 at 08:50:07PM +0100, Dmitry Safonov wrote: > random uses __ratelimit() which calls ___ratelimit() with a function > name. Depending on !RATELIMIT_MSG_ON_RELEASE it prints how many > messages were suppressed every ratelimit interval (1 second for random) > and flushes

[PATCH] um: remove unused vdso-syms.lds

This file contains symbol values, and was originally linked into vmlinux, but I have no idea what it was actually used for. Since commit 827880ec260b ("x86/um: thin archives build fix"), it is not even linked. Now it is completely orphan, and no problem has been reported. It is a proof that

[PATCH] um: remove unused vdso-syms.lds

This file contains symbol values, and was originally linked into vmlinux, but I have no idea what it was actually used for. Since commit 827880ec260b ("x86/um: thin archives build fix"), it is not even linked. Now it is completely orphan, and no problem has been reported. It is a proof that

Re: [UML] Question about arch/x86/um/vdso/vdso-syms.lds

Richard, 2018-05-09 15:36 GMT+09:00 Richard Weinberger : > Masahiro, > > Am Mittwoch, 9. Mai 2018, 05:36:18 CEST schrieb Masahiro Yamada: >> Hi Richard, >> >> >> Please let me ask a question about vdso-syms.lds >> under arch/x86/um/vdso/. >> >> This file exists since: >> >>

Re: [UML] Question about arch/x86/um/vdso/vdso-syms.lds

Richard, 2018-05-09 15:36 GMT+09:00 Richard Weinberger : > Masahiro, > > Am Mittwoch, 9. Mai 2018, 05:36:18 CEST schrieb Masahiro Yamada: >> Hi Richard, >> >> >> Please let me ask a question about vdso-syms.lds >> under arch/x86/um/vdso/. >> >> This file exists since: >> >> commit

Re: [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328

On 2018-05-10 8:50 PM, Robin Murphy wrote: On 10/05/18 10:16, d...@t-chip.com.cn wrote: From: Levin Du Adding a new gpio controller named "gpio-syscon10" to rk3328, providing access to the pins defined in the syscon GRF_SOC_CON10. This is the GPIO_MUTE pin, right? The

Re: [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328

On 2018-05-10 8:50 PM, Robin Murphy wrote: On 10/05/18 10:16, d...@t-chip.com.cn wrote: From: Levin Du Adding a new gpio controller named "gpio-syscon10" to rk3328, providing access to the pins defined in the syscon GRF_SOC_CON10. This is the GPIO_MUTE pin, right? The public TRM is rather

Re: [PATCH v4 0/1] Add livepatch kselftests

On Fri, May 11, 2018 at 10:53:24AM +0800, Ye Xiaolong wrote: > Hi, Joe > > Sorry for the late response. Hi Xiaolong, no worries... > On 04/26, Joe Lawrence wrote: > >>On 04/25/2018 02:28 PM, Joe Lawrence wrote: > > > >> [ ... snip ... ] > >> > >> base-commit:

Re: [PATCH v4 0/1] Add livepatch kselftests

On Fri, May 11, 2018 at 10:53:24AM +0800, Ye Xiaolong wrote: > Hi, Joe > > Sorry for the late response. Hi Xiaolong, no worries... > On 04/26, Joe Lawrence wrote: > >>On 04/25/2018 02:28 PM, Joe Lawrence wrote: > > > >> [ ... snip ... ] > >> > >> base-commit:

Re: cross-compiling a 64-bit kernel on a 32-bit host

Hi Josh, CC LKP team. On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote: Hi Fengguang, I occasionally get compilation bug reports from people who are cross-compiling an x86-64 kernel target on an x86-32 host. Any chance the 0-day build bot could test that configuration? I think

Re: cross-compiling a 64-bit kernel on a 32-bit host

Hi Josh, CC LKP team. On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote: Hi Fengguang, I occasionally get compilation bug reports from people who are cross-compiling an x86-64 kernel target on an x86-32 host. Any chance the 0-day build bot could test that configuration? I think

[PATCH 4/9] arm64: dts: ls208xa: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 Add the identify of the platform to support set the rcpm with big-endian or little-endian. Signed-off-by: Zhang Ying-22455 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |6 -- 1 files changed, 4

[PATCH 4/9] arm64: dts: ls208xa: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 Add the identify of the platform to support set the rcpm with big-endian or little-endian. Signed-off-by: Zhang Ying-22455 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH 8/9] arm64: dts: ls1046a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 Add the identify of the platform to support set the rcpm with big-endian or little-endian. Signed-off-by: Zhang Ying-22455 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |2 +- 1 files changed, 1 insertions(+), 1

[PATCH 9/9] armv8: add psci 0.2 stardard support

From: Yuantian Tang In current kernel, only psci v1.0 is supported. But our psci firmware only support psci v0.2. So update psci driver to support psci v0.2. Signed-off-by: Tang Yuantian --- drivers/firmware/psci.c |4 1 files changed, 4

[PATCH 8/9] arm64: dts: ls1046a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 Add the identify of the platform to support set the rcpm with big-endian or little-endian. Signed-off-by: Zhang Ying-22455 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

[PATCH 9/9] armv8: add psci 0.2 stardard support

From: Yuantian Tang In current kernel, only psci v1.0 is supported. But our psci firmware only support psci v0.2. So update psci driver to support psci v0.2. Signed-off-by: Tang Yuantian --- drivers/firmware/psci.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git

[PATCH 6/9] soc: fsl: fix the compilation issue

From: Zhang Ying-22455 Signed-off-by: Zhang Ying-22455 --- drivers/soc/fsl/layerscape/ftm_alarm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c

[PATCH 6/9] soc: fsl: fix the compilation issue

From: Zhang Ying-22455 Signed-off-by: Zhang Ying-22455 --- drivers/soc/fsl/layerscape/ftm_alarm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c b/drivers/soc/fsl/layerscape/ftm_alarm.c index 811dcfa..c22ef49 100644 ---

[PATCH 7/9] arm64: dts: ls1043a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 Add the identify of the platform to support set the rcpm with big-endian or little-endian. Signed-off-by: Zhang Ying-22455 --- arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |2 +- 1 files changed, 1 insertions(+), 1

[PATCH 7/9] arm64: dts: ls1043a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 Add the identify of the platform to support set the rcpm with big-endian or little-endian. Signed-off-by: Zhang Ying-22455 --- arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

[PATCH 5/9] drivers: firmware: psci: use psci v0.2 to implement sleep

From: Yuantian Tang Technically psci v0.2 can not support system sleep. Unfortunately our PPA only supports psci v0.2. So workaround this by changing psci v1.0 to v0.2 call to implement system sleep. Signed-off-by: Tang Yuantian Signed-off-by: Yinbo Zhu

[PATCH 5/9] drivers: firmware: psci: use psci v0.2 to implement sleep

From: Yuantian Tang Technically psci v0.2 can not support system sleep. Unfortunately our PPA only supports psci v0.2. So workaround this by changing psci v1.0 to v0.2 call to implement system sleep. Signed-off-by: Tang Yuantian Signed-off-by: Yinbo Zhu --- drivers/firmware/psci.c | 16

[PATCH 2/9] armv8: pm: Fix issue of rcpm driver wrongly program other IP control bits

From: Ran Wang When rcpm driver get target register data from DTS property 'fsl, rcpm-wakeup' (second value), it directly write that data to register RCPM_IPPDEXPCRx rather than 'OR' the value read from it before. This operation will over-write those non-related IP control

[PATCH 3/9] soc: fsl: set rcpm bit for FTM

From: Zhang Ying-22455 Set RCPM for FTM when using FTM as wakeup source. Because the RCPM module of each platform has different big-end and little-end mode, there need to set RCPM depending on the platform. Signed-off-by: Zhang Ying-22455

[PATCH 2/9] armv8: pm: Fix issue of rcpm driver wrongly program other IP control bits

From: Ran Wang When rcpm driver get target register data from DTS property 'fsl, rcpm-wakeup' (second value), it directly write that data to register RCPM_IPPDEXPCRx rather than 'OR' the value read from it before. This operation will over-write those non-related IP control bit which might have

[PATCH 3/9] soc: fsl: set rcpm bit for FTM

From: Zhang Ying-22455 Set RCPM for FTM when using FTM as wakeup source. Because the RCPM module of each platform has different big-end and little-end mode, there need to set RCPM depending on the platform. Signed-off-by: Zhang Ying-22455 Signed-off-by: Yinbo Zhu ---

[PATCH 1/9] armv8: pm: add rcpm module support

From: Yuantian Tang The Run Control and Power Management (RCPM) module communicates with embedded cores, coherency modules, and other device platform module to provide run control and power management functionality Signed-off-by: Tang Yuantian

[PATCH 1/9] armv8: pm: add rcpm module support

From: Yuantian Tang The Run Control and Power Management (RCPM) module communicates with embedded cores, coherency modules, and other device platform module to provide run control and power management functionality Signed-off-by: Tang Yuantian Signed-off-by: Yinbo Zhu ---

[PATCH v1 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain

According to a description from TRM, add all the power domains. Signed-off-by: Elaine Zhang --- include/dt-bindings/power/rk3228-power.h | 26 ++ 1 file changed, 26 insertions(+) create mode 100644 include/dt-bindings/power/rk3228-power.h diff

[PATCH v1 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain

According to a description from TRM, add all the power domains. Signed-off-by: Elaine Zhang --- include/dt-bindings/power/rk3228-power.h | 26 ++ 1 file changed, 26 insertions(+) create mode 100644 include/dt-bindings/power/rk3228-power.h diff --git

[PATCH v1 10/13] soc: rockchip: power-domain: add power domain support for rk3228

This driver is modified to support RK3228 SoC. Signed-off-by: Elaine Zhang --- drivers/soc/rockchip/pm_domains.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c

[PATCH v1 10/13] soc: rockchip: power-domain: add power domain support for rk3228

This driver is modified to support RK3228 SoC. Signed-off-by: Elaine Zhang --- drivers/soc/rockchip/pm_domains.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c index

[PATCH v1 09/13] dt-bindings: add binding for rk3228 power domains

Add binding documentation for the power domains found on Rockchip RK3228 SoCs. Signed-off-by: Elaine Zhang --- Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v1 09/13] dt-bindings: add binding for rk3228 power domains

Add binding documentation for the power domains found on Rockchip RK3228 SoCs. Signed-off-by: Elaine Zhang --- Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt

[PATCH v1 13/13] soc: rockchip: power-domain: add power domain support for px30

This driver is modified to support PX30 SoC. Signed-off-by: Elaine Zhang Signed-off-by: Finley Xiao --- drivers/soc/rockchip/pm_domains.c | 30 ++ 1 file changed, 30 insertions(+) diff --git

[PATCH v1 12/13] dt-bindings: add binding for px30 power domains

Add binding documentation for the power domains found on Rockchip PX30 SoCs. Signed-off-by: Elaine Zhang Signed-off-by: Finley Xiao --- Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++ 1 file changed, 3 insertions(+)

  1   2   3   4   5   6   7   8   9   10   >