Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration

"Naveen N. Rao" writes: > When a kprobe is being registered, we use the symbol_name field to > lookup the address where the probe should be placed. Since this is a > user-provided field, let's ensure that the length of the string is > within expected limits.

Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration

"Naveen N. Rao" writes: > When a kprobe is being registered, we use the symbol_name field to > lookup the address where the probe should be placed. Since this is a > user-provided field, let's ensure that the length of the string is > within expected limits. What are we actually trying to

Re: [PATCH 8/8] selftests: x86: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:44: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan

Re: [PATCH 8/8] selftests: x86: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:44: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan > --- >

Re: [PATCH 6/8] selftests: splice: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:8: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan

Re: [PATCH 6/8] selftests: splice: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:8: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan > --- >

Re: [PATCH 7/8] selftests: sync: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:24: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan

Re: [PATCH 7/8] selftests: sync: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:24: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan > --- >

Re: [PATCH 4/8] selftests: gpio: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:11: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan

Re: [PATCH 4/8] selftests: gpio: override clean in lib.mk to fix warnings

Shuah Khan writes: > Add override for lib.mk clean to fix the following warnings from clean > target run. > > Makefile:11: warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan > --- >

Re: [PATCH 2/8] selftests: lib.mk: define CLEAN macro to allow Makefiles to override clean

Shuah Khan writes: > Define CLEAN macro to allow Makefiles to override common clean target > in lib.mk. This will help fix the following failures: > > warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > >

Re: [PATCH 2/8] selftests: lib.mk: define CLEAN macro to allow Makefiles to override clean

Shuah Khan writes: > Define CLEAN macro to allow Makefiles to override common clean target > in lib.mk. This will help fix the following failures: > > warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > > Signed-off-by: Shuah Khan

Re: Linux 3.18.50

diff --git a/Makefile b/Makefile index 252070fdf91c..8665178e2a36 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 3 PATCHLEVEL = 18 -SUBLEVEL = 49 +SUBLEVEL = 50 EXTRAVERSION = NAME = Diseased Newt diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h index

Re: Linux 3.18.50

diff --git a/Makefile b/Makefile index 252070fdf91c..8665178e2a36 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ VERSION = 3 PATCHLEVEL = 18 -SUBLEVEL = 49 +SUBLEVEL = 50 EXTRAVERSION = NAME = Diseased Newt diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h index

Linux 3.18.50

I'm announcing the release of the 3.18.50 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be browsed at the normal kernel.org git web

Linux 3.18.50

I'm announcing the release of the 3.18.50 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be browsed at the normal kernel.org git web

Re: [HMM 03/15] mm/unaddressable-memory: new type of ZONE_DEVICE for unaddressable memory

On Fri, Apr 21, 2017 at 8:30 PM, Jérôme Glisse wrote: > HMM (heterogeneous memory management) need struct page to support migration > from system main memory to device memory. Reasons for HMM and migration to > device memory is explained with HMM core patch. > > This patch

Re: [HMM 03/15] mm/unaddressable-memory: new type of ZONE_DEVICE for unaddressable memory

On Fri, Apr 21, 2017 at 8:30 PM, Jérôme Glisse wrote: > HMM (heterogeneous memory management) need struct page to support migration > from system main memory to device memory. Reasons for HMM and migration to > device memory is explained with HMM core patch. > > This patch deals with device

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote: >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote: >> > While working on graphics support for virtual machines on ppc64

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä wrote: > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote: >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote: >> > While working on graphics support for virtual machines on ppc64 (which >> > exists in both little and big endian

[HMM 14/15] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v3

This introduce a dummy HMM device class so device driver can use it to create hmm_device for the sole purpose of registering device memory. It is useful to device driver that want to manage multiple physical device memory under same struct device umbrella. Changed since v2: - use

[HMM 14/15] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v3

This introduce a dummy HMM device class so device driver can use it to create hmm_device for the sole purpose of registering device memory. It is useful to device driver that want to manage multiple physical device memory under same struct device umbrella. Changed since v2: - use

Re: [HMM 02/15] mm/put_page: move ZONE_DEVICE page reference decrement v2

On Fri, Apr 21, 2017 at 8:30 PM, Jérôme Glisse wrote: > Move page reference decrement of ZONE_DEVICE from put_page() > to put_zone_device_page() this does not affect non ZONE_DEVICE > page. > > Doing this allow to catch when a ZONE_DEVICE page refcount reach > 1 which means

Re: [HMM 02/15] mm/put_page: move ZONE_DEVICE page reference decrement v2

On Fri, Apr 21, 2017 at 8:30 PM, Jérôme Glisse wrote: > Move page reference decrement of ZONE_DEVICE from put_page() > to put_zone_device_page() this does not affect non ZONE_DEVICE > page. > > Doing this allow to catch when a ZONE_DEVICE page refcount reach > 1 which means the device is no

Re: [tip:irq/urgent] genirq/affinity: Fix calculating vectors to assign

Looks like 4.11 will be release in a few days, it would be nice if this commit reaches the upstream tree before this moment. Thanks. On Thu, Apr 20, 2017 at 07:06:49AM -0700, tip-bot for Keith Busch wrote: > Commit-ID: b72f8051f34b8164a62391e3676edc34523c5952 > Gitweb:

Re: [tip:irq/urgent] genirq/affinity: Fix calculating vectors to assign

Looks like 4.11 will be release in a few days, it would be nice if this commit reaches the upstream tree before this moment. Thanks. On Thu, Apr 20, 2017 at 07:06:49AM -0700, tip-bot for Keith Busch wrote: > Commit-ID: b72f8051f34b8164a62391e3676edc34523c5952 > Gitweb:

[HMM 07/15] mm/hmm: heterogeneous memory management (HMM for short) v2

HMM provides 3 separate types of functionality: - Mirroring: synchronize CPU page table and device page table - Device memory: allocating struct page for device memory - Migration: migrating regular memory to device memory This patch introduces some common helpers and definitions to

[HMM 08/15] mm/hmm/mirror: mirror process address space on device with HMM helpers v2

This is a heterogeneous memory management (HMM) process address space mirroring. In a nutshell this provide an API to mirror process address space on a device. This boils down to keeping CPU and device page table synchronize (we assume that both device and CPU are cache coherent like PCIe device

[HMM 07/15] mm/hmm: heterogeneous memory management (HMM for short) v2

HMM provides 3 separate types of functionality: - Mirroring: synchronize CPU page table and device page table - Device memory: allocating struct page for device memory - Migration: migrating regular memory to device memory This patch introduces some common helpers and definitions to

[HMM 08/15] mm/hmm/mirror: mirror process address space on device with HMM helpers v2

This is a heterogeneous memory management (HMM) process address space mirroring. In a nutshell this provide an API to mirror process address space on a device. This boils down to keeping CPU and device page table synchronize (we assume that both device and CPU are cache coherent like PCIe device

[HMM 01/15] mm, memory_hotplug: introduce add_pages

From: Michal Hocko There are new users of memory hotplug emerging. Some of them require different subset of arch_add_memory. There are some which only require allocation of struct pages without mapping those pages to the kernel address space. We currently have __add_pages for

[HMM 01/15] mm, memory_hotplug: introduce add_pages

From: Michal Hocko There are new users of memory hotplug emerging. Some of them require different subset of arch_add_memory. There are some which only require allocation of struct pages without mapping those pages to the kernel address space. We currently have __add_pages for that purpose. But

[HMM 03/15] mm/unaddressable-memory: new type of ZONE_DEVICE for unaddressable memory

HMM (heterogeneous memory management) need struct page to support migration from system main memory to device memory. Reasons for HMM and migration to device memory is explained with HMM core patch. This patch deals with device memory that is un-addressable memory (ie CPU can not access it).

[HMM 03/15] mm/unaddressable-memory: new type of ZONE_DEVICE for unaddressable memory

HMM (heterogeneous memory management) need struct page to support migration from system main memory to device memory. Reasons for HMM and migration to device memory is explained with HMM core patch. This patch deals with device memory that is un-addressable memory (ie CPU can not access it).

[PATCH v3] selftests: ftrace: Allow some tests to be run in a tracing instance

>From 4464dc867ead3ea14654165ad3ab68263aff7b17 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Thu, 20 Apr 2017 12:53:18 -0400 Subject: [PATCH] selftests: ftrace: Allow some tests to be run in a tracing instance An tracing instance has several of the same

[PATCH v3] selftests: ftrace: Allow some tests to be run in a tracing instance

>From 4464dc867ead3ea14654165ad3ab68263aff7b17 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Thu, 20 Apr 2017 12:53:18 -0400 Subject: [PATCH] selftests: ftrace: Allow some tests to be run in a tracing instance An tracing instance has several of the same capabilities as the top

[HMM 04/15] mm/migrate: new migrate mode MIGRATE_SYNC_NO_COPY

Introduce a new migration mode that allow to offload the copy to a device DMA engine. This changes the workflow of migration and not all address_space migratepage callback can support this. So it needs to be tested in those cases. This is intended to be use by migrate_vma() which itself is use

[HMM 11/15] mm/migrate: support un-addressable ZONE_DEVICE page in migration

Allow to unmap and restore special swap entry of un-addressable ZONE_DEVICE memory. Signed-off-by: Jérôme Glisse Cc: Kirill A. Shutemov --- include/linux/migrate.h | 10 +++- mm/migrate.c| 136

[HMM 04/15] mm/migrate: new migrate mode MIGRATE_SYNC_NO_COPY

Introduce a new migration mode that allow to offload the copy to a device DMA engine. This changes the workflow of migration and not all address_space migratepage callback can support this. So it needs to be tested in those cases. This is intended to be use by migrate_vma() which itself is use

[HMM 11/15] mm/migrate: support un-addressable ZONE_DEVICE page in migration

Allow to unmap and restore special swap entry of un-addressable ZONE_DEVICE memory. Signed-off-by: Jérôme Glisse Cc: Kirill A. Shutemov --- include/linux/migrate.h | 10 +++- mm/migrate.c| 136 ++-- mm/page_vma_mapped.c| 10

Re: [PATCH] xprtrdma: use offset_in_page() macro

> On Apr 21, 2017, at 9:21 PM, Geliang Tang wrote: > > Use offset_in_page() macro instead of open-coding. > > Signed-off-by: Geliang Tang > --- > net/sunrpc/xprtrdma/rpc_rdma.c| 4 ++-- > net/sunrpc/xprtrdma/svc_rdma_sendto.c | 3 +-- > 2

[HMM 05/15] mm/migrate: new memory migration helper for use with device memory v4

This patch add a new memory migration helpers, which migrate memory backing a range of virtual address of a process to different memory (which can be allocated through special allocator). It differs from numa migration by working on a range of virtual address and thus by doing migration in chunk

Re: [PATCH] xprtrdma: use offset_in_page() macro

> On Apr 21, 2017, at 9:21 PM, Geliang Tang wrote: > > Use offset_in_page() macro instead of open-coding. > > Signed-off-by: Geliang Tang > --- > net/sunrpc/xprtrdma/rpc_rdma.c| 4 ++-- > net/sunrpc/xprtrdma/svc_rdma_sendto.c | 3 +-- > 2 files changed, 3 insertions(+), 4 deletions(-) >

[HMM 05/15] mm/migrate: new memory migration helper for use with device memory v4

This patch add a new memory migration helpers, which migrate memory backing a range of virtual address of a process to different memory (which can be allocated through special allocator). It differs from numa migration by working on a range of virtual address and thus by doing migration in chunk

[HMM 02/15] mm/put_page: move ZONE_DEVICE page reference decrement v2

Move page reference decrement of ZONE_DEVICE from put_page() to put_zone_device_page() this does not affect non ZONE_DEVICE page. Doing this allow to catch when a ZONE_DEVICE page refcount reach 1 which means the device is no longer reference by any one (unlike page from other zone, ZONE_DEVICE

[HMM 02/15] mm/put_page: move ZONE_DEVICE page reference decrement v2

Move page reference decrement of ZONE_DEVICE from put_page() to put_zone_device_page() this does not affect non ZONE_DEVICE page. Doing this allow to catch when a ZONE_DEVICE page refcount reach 1 which means the device is no longer reference by any one (unlike page from other zone, ZONE_DEVICE

Re: [RFC PATCH v5 1/2] usb: typec: USB Type-C Port Manager (tcpm)

On 04/21/2017 03:15 PM, Guenter Roeck wrote: From: Guenter Roeck This driver implements the USB Type-C Power Delivery state machine for both source and sink ports. Alternate mode support is not fully implemented. The driver attaches to the USB Type-C class code

Re: [RFC PATCH v5 1/2] usb: typec: USB Type-C Port Manager (tcpm)

On 04/21/2017 03:15 PM, Guenter Roeck wrote: From: Guenter Roeck This driver implements the USB Type-C Power Delivery state machine for both source and sink ports. Alternate mode support is not fully implemented. The driver attaches to the USB Type-C class code implemented in the following

[HMM 15/15] hmm: heterogeneous memory management documentation

This add documentation for HMM (Heterogeneous Memory Management). It presents the motivation behind it, the features necessary for it to be useful and and gives an overview of how this is implemented. Signed-off-by: Jérôme Glisse --- Documentation/vm/hmm.txt | 362

[HMM 15/15] hmm: heterogeneous memory management documentation

This add documentation for HMM (Heterogeneous Memory Management). It presents the motivation behind it, the features necessary for it to be useful and and gives an overview of how this is implemented. Signed-off-by: Jérôme Glisse --- Documentation/vm/hmm.txt | 362

[HMM 10/15] mm/hmm/mirror: device page fault handler

This handle page fault on behalf of device driver, unlike handle_mm_fault() it does not trigger migration back to system memory for device memory. Signed-off-by: Jérôme Glisse Signed-off-by: Evgeny Baskakov Signed-off-by: John Hubbard

[HMM 12/15] mm/migrate: allow migrate_vma() to alloc new page on empty entry v2

This allow caller of migrate_vma() to allocate new page for empty CPU page table entry. It only support anoymous memory and it won't allow new page to be instance if userfaultfd is armed. This is useful to device driver that want to migrate a range of virtual address and would rather allocate new

[HMM 10/15] mm/hmm/mirror: device page fault handler

This handle page fault on behalf of device driver, unlike handle_mm_fault() it does not trigger migration back to system memory for device memory. Signed-off-by: Jérôme Glisse Signed-off-by: Evgeny Baskakov Signed-off-by: John Hubbard Signed-off-by: Mark Hairgrove Signed-off-by: Sherry Cheung

[HMM 12/15] mm/migrate: allow migrate_vma() to alloc new page on empty entry v2

This allow caller of migrate_vma() to allocate new page for empty CPU page table entry. It only support anoymous memory and it won't allow new page to be instance if userfaultfd is armed. This is useful to device driver that want to migrate a range of virtual address and would rather allocate new

[HMM 13/15] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v3

This introduce a simple struct and associated helpers for device driver to use when hotpluging un-addressable device memory as ZONE_DEVICE. It will find a unuse physical address range and trigger memory hotplug for it which allocates and initialize struct page for the device memory. Changed since

[HMM 13/15] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE v3

This introduce a simple struct and associated helpers for device driver to use when hotpluging un-addressable device memory as ZONE_DEVICE. It will find a unuse physical address range and trigger memory hotplug for it which allocates and initialize struct page for the device memory. Changed since

[HMM 06/15] mm/migrate: migrate_vma() unmap page from vma while collecting pages

Common case for migration of virtual address range is page are map only once inside the vma in which migration is taking place. Because we already walk the CPU page table for that range we can directly do the unmap there and setup special migration swap entry. Signed-off-by: Jérôme Glisse

[HMM 06/15] mm/migrate: migrate_vma() unmap page from vma while collecting pages

Common case for migration of virtual address range is page are map only once inside the vma in which migration is taking place. Because we already walk the CPU page table for that range we can directly do the unmap there and setup special migration swap entry. Signed-off-by: Jérôme Glisse

[HMM 00/15] HMM (Heterogeneous Memory Management) v20

Patchset is on top of mmotm mmotm-2017-04-18 and Michal patchset ([PATCH -v3 0/13] mm: make movable onlining suck less). Branch: https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v20 I have included all suggestion made since v19, it is all build fix and change in respect to memory hotplug

[HMM 00/15] HMM (Heterogeneous Memory Management) v20

Patchset is on top of mmotm mmotm-2017-04-18 and Michal patchset ([PATCH -v3 0/13] mm: make movable onlining suck less). Branch: https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v20 I have included all suggestion made since v19, it is all build fix and change in respect to memory hotplug

[HMM 09/15] mm/hmm/mirror: helper to snapshot CPU page table v2

This does not use existing page table walker because we want to share same code for our page fault handler. Changes since v1: - Use spinlock instead of rcu synchronized list traversal Signed-off-by: Jérôme Glisse Signed-off-by: Evgeny Baskakov

[HMM 09/15] mm/hmm/mirror: helper to snapshot CPU page table v2

This does not use existing page table walker because we want to share same code for our page fault handler. Changes since v1: - Use spinlock instead of rcu synchronized list traversal Signed-off-by: Jérôme Glisse Signed-off-by: Evgeny Baskakov Signed-off-by: John Hubbard Signed-off-by: Mark

Re: [PATCH v2] selftests: ftrace: Allow some tests to be run in a tracing instance

On Sat, 22 Apr 2017 08:00:36 +0900 Masami Hiramatsu wrote: > > BTW, this seems too complecated (with many similar variables). I'm use to complicated ;-) > I think we just need following patch, if we run the tests which > have "instance" flag twice on top-level and an

Re: [PATCH v2] selftests: ftrace: Allow some tests to be run in a tracing instance

On Sat, 22 Apr 2017 08:00:36 +0900 Masami Hiramatsu wrote: > > BTW, this seems too complecated (with many similar variables). I'm use to complicated ;-) > I think we just need following patch, if we run the tests which > have "instance" flag twice on top-level and an instance. > (If you'd

Re: [RFC PATCH 1/3] clk: add clk_bulk_get accessories

On 04/12, Dong Aisheng wrote: > > #ifdef CONFIG_HAVE_CLK > @@ -230,6 +257,32 @@ static inline void clk_unprepare(struct clk *clk) > struct clk *clk_get(struct device *dev, const char *id); > > /** > + * clk_bulk_get - lookup and obtain a number of references to clock producer. > + * @dev:

Re: [RFC PATCH 1/3] clk: add clk_bulk_get accessories

On 04/12, Dong Aisheng wrote: > > #ifdef CONFIG_HAVE_CLK > @@ -230,6 +257,32 @@ static inline void clk_unprepare(struct clk *clk) > struct clk *clk_get(struct device *dev, const char *id); > > /** > + * clk_bulk_get - lookup and obtain a number of references to clock producer. > + * @dev:

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Fri, 21 Apr 2017, Kees Cook wrote: > > The linux-4.2 x86 defconfig could still be built with gcc-4.0, but > > later kernels have several minor problems with that, and > > require at least gcc-4.3. > > > > If we are ok with this status quo, we could simply declare gcc-4.3 > > the absolute

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Fri, 21 Apr 2017, Kees Cook wrote: > > The linux-4.2 x86 defconfig could still be built with gcc-4.0, but > > later kernels have several minor problems with that, and > > require at least gcc-4.3. > > > > If we are ok with this status quo, we could simply declare gcc-4.3 > > the absolute

Re: [RFC PATCH 0/3] clk: introduce clk_bulk_get accessories

On 04/12, Dong Aisheng wrote: > > Together with the err path handling for each clocks, it does make > things a bit ugly. > > Since we already have regulator_bulk_get accessories, i thought we > probably could introduce clk_bulk_get as well to handle such case to > ease the driver owners' life.

Re: [RFC PATCH 0/3] clk: introduce clk_bulk_get accessories

On 04/12, Dong Aisheng wrote: > > Together with the err path handling for each clocks, it does make > things a bit ugly. > > Since we already have regulator_bulk_get accessories, i thought we > probably could introduce clk_bulk_get as well to handle such case to > ease the driver owners' life.

Re: [RFC PATCH 2/3] clk: add managed version of clk_bulk_get

On 04/13, Dong Aisheng wrote: > On Wed, Apr 12, 2017 at 12:03:28PM +0800, Dong Aisheng wrote: > >drivers/built-in.o: In function `devm_clk_bulk_get': > >> (.text+0x1930e): undefined reference to `clk_bulk_get' >drivers/built-in.o: In function `devm_clk_bulk_release': > >>

Re: [RFC PATCH 2/3] clk: add managed version of clk_bulk_get

On 04/13, Dong Aisheng wrote: > On Wed, Apr 12, 2017 at 12:03:28PM +0800, Dong Aisheng wrote: > >drivers/built-in.o: In function `devm_clk_bulk_get': > >> (.text+0x1930e): undefined reference to `clk_bulk_get' >drivers/built-in.o: In function `devm_clk_bulk_release': > >>

Re: [RFC PATCH 2/3] clk: add managed version of clk_bulk_get

On 04/12, Dong Aisheng wrote: > diff --git a/include/linux/clk.h b/include/linux/clk.h > index 1d05b66..3fc6010 100644 > --- a/include/linux/clk.h > +++ b/include/linux/clk.h > @@ -278,11 +278,25 @@ struct clk *clk_get(struct device *dev, const char *id); > * > * clk_bulk_get should not be

Re: [RFC PATCH 2/3] clk: add managed version of clk_bulk_get

On 04/12, Dong Aisheng wrote: > diff --git a/include/linux/clk.h b/include/linux/clk.h > index 1d05b66..3fc6010 100644 > --- a/include/linux/clk.h > +++ b/include/linux/clk.h > @@ -278,11 +278,25 @@ struct clk *clk_get(struct device *dev, const char *id); > * > * clk_bulk_get should not be

Re: [PATCH v2 8/8] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

On Sat, Apr 22, 2017 at 1:34 AM, sathyanarayanan kuppuswamy wrote: > Thanks for brining it up. I was planning to ask either Andy or Lee regarding > this issue after all patches in the series are reviewed. Darren, I'm planning to review this soon.

Re: [PATCH v2 8/8] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

On Sat, Apr 22, 2017 at 1:34 AM, sathyanarayanan kuppuswamy wrote: > Thanks for brining it up. I was planning to ask either Andy or Lee regarding > this issue after all patches in the series are reviewed. Darren, I'm planning to review this soon. P.S. We have few series flying around regarding

Re: [PATCH 3/5] clk: mvebu: Use kcalloc() in two functions

On 04/19, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 19 Apr 2017 21:08:54 +0200 > > * Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding

[RFC][PATCH tip/sched/core] sched/rt: Simplify the IPI rt balancing logic

When a CPU lowers its priority (schedules out a high priority task for a lower priority one), a check is made to see if any other CPU has overloaded RT tasks (more than one). It checks the rto_mask to determine this and if so it will request to pull one of those tasks to itself if the non running

Re: [PATCH 3/5] clk: mvebu: Use kcalloc() in two functions

On 04/19, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 19 Apr 2017 21:08:54 +0200 > > * Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding function "kcalloc". > > This

[RFC][PATCH tip/sched/core] sched/rt: Simplify the IPI rt balancing logic

When a CPU lowers its priority (schedules out a high priority task for a lower priority one), a check is made to see if any other CPU has overloaded RT tasks (more than one). It checks the rto_mask to determine this and if so it will request to pull one of those tasks to itself if the non running

Re: [PATCH 1/5] clk: mvebu: Use kcalloc() in of_cpu_clk_setup()

On 04/19, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 19 Apr 2017 20:15:21 +0200 > > Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding function

Re: [PATCH 1/5] clk: mvebu: Use kcalloc() in of_cpu_clk_setup()

On 04/19, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 19 Apr 2017 20:15:21 +0200 > > Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding function "kcalloc". > > This issue was

Re: [PATCH 8/8] clk: nomadik: Delete error messages for a failed memory allocation in two functions

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 10:04:00 +0200 > > The script "checkpatch.pl" pointed information out like the following. > > WARNING: Possible unnecessary 'out of memory' message > > Thus remove such statements

Re: [PATCH 7/8] clk: nomadik: Use seq_puts() in nomadik_src_clk_show()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 09:45:04 +0200 > > A string which did not contain a data format specification should be put > into a sequence. Thus use the corresponding function "seq_puts". > > This issue was

Re: [PATCH 8/8] clk: nomadik: Delete error messages for a failed memory allocation in two functions

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 10:04:00 +0200 > > The script "checkpatch.pl" pointed information out like the following. > > WARNING: Possible unnecessary 'out of memory' message > > Thus remove such statements here. > > Link: >

Re: [PATCH 7/8] clk: nomadik: Use seq_puts() in nomadik_src_clk_show()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 09:45:04 +0200 > > A string which did not contain a data format specification should be put > into a sequence. Thus use the corresponding function "seq_puts". > > This issue was detected by using the Coccinelle

Re: [PATCH 6/8] clk: Improve a size determination in two functions

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 09:30:52 +0200 > > Replace the specification of two data structures by pointer dereferences > as the parameter for the operator "sizeof" to make the corresponding size >

Re: [PATCH 6/8] clk: Improve a size determination in two functions

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 09:30:52 +0200 > > Replace the specification of two data structures by pointer dereferences > as the parameter for the operator "sizeof" to make the corresponding size > determination a bit safer according to the

Re: [PATCH 4/8] clk: Replace four seq_printf() calls by seq_putc()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 08:45:43 +0200 > > Four single characters should be put into a sequence. > Thus use the corresponding function "seq_putc". > > This issue was detected by using the Coccinelle

Re: [PATCH 4/8] clk: Replace four seq_printf() calls by seq_putc()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 08:45:43 +0200 > > Four single characters should be put into a sequence. > Thus use the corresponding function "seq_putc". > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus

[PATCH v2] nfs/filelayout: fix NULL pointer dereference in fl_pnfs_update_layout()

Calling pnfs_put_lset on an IS_ERR pointer results in a NULL pointer dereference like the one below. At the same time the check of retvalue of filelayout_check_deviceid() sets lseg to error, but does not free it before that. [ 3000.636161] BUG: unable to handle kernel NULL pointer dereference at

Re: [PATCH 2/8] clk: si5351: Delete an error message for a failed memory allocation in si5351_i2c_probe()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 07:34:54 +0200 > > The script "checkpatch.pl" pointed information out like the following. > > * CHECK: Comparison to NULL could be written "!drvdata" > > Thus adjust this

[PATCH v2] nfs/filelayout: fix NULL pointer dereference in fl_pnfs_update_layout()

Calling pnfs_put_lset on an IS_ERR pointer results in a NULL pointer dereference like the one below. At the same time the check of retvalue of filelayout_check_deviceid() sets lseg to error, but does not free it before that. [ 3000.636161] BUG: unable to handle kernel NULL pointer dereference at

Re: [PATCH 2/8] clk: si5351: Delete an error message for a failed memory allocation in si5351_i2c_probe()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 20 Apr 2017 07:34:54 +0200 > > The script "checkpatch.pl" pointed information out like the following. > > * CHECK: Comparison to NULL could be written "!drvdata" > > Thus adjust this expression. > > > * WARNING:

Re: [PATCH 1/8] clk: si5351: Use devm_kcalloc() in si5351_i2c_probe()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 19 Apr 2017 22:37:30 +0200 > > Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding function

Re: [PATCH 1/8] clk: si5351: Use devm_kcalloc() in si5351_i2c_probe()

On 04/20, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 19 Apr 2017 22:37:30 +0200 > > Multiplications for the size determination of memory allocations > indicated that array data structures should be processed. > Thus use the corresponding function "devm_kcalloc". > > This issue

Re: [PATCH] clk: tegra: fix SS control on PLL enable/disable

On 04/20, Peter De Schrijver wrote: > PLL SS was only controlled when setting the PLL rate, not when the PLL > itself is enabled or disabled. This means that if the PLL rate was set > before the PLL is enabled, SS will not be enabled, even when configured. > > Signed-off-by: Peter De Schrijver

Re: [PATCH] clk: tegra: fix SS control on PLL enable/disable

On 04/20, Peter De Schrijver wrote: > PLL SS was only controlled when setting the PLL rate, not when the PLL > itself is enabled or disabled. This means that if the PLL rate was set > before the PLL is enabled, SS will not be enabled, even when configured. > > Signed-off-by: Peter De Schrijver

Re: [PATCH 2/2] clk: ti: fix building without legacy omap3

On 04/19, Arnd Bergmann wrote: > When CONFIG_ATAGS or CONFIG_OMAP3 is disabled, we get a build error: > > In file included from include/linux/clk-provider.h:15:0, > from drivers/clk/ti/clk.c:19: > drivers/clk/ti/clk.c: In function 'ti_clk_add_aliases': >

Re: [PATCH 2/2] clk: ti: fix building without legacy omap3

On 04/19, Arnd Bergmann wrote: > When CONFIG_ATAGS or CONFIG_OMAP3 is disabled, we get a build error: > > In file included from include/linux/clk-provider.h:15:0, > from drivers/clk/ti/clk.c:19: > drivers/clk/ti/clk.c: In function 'ti_clk_add_aliases': >

  1   2   3   4   5   6   7   8   9   10   >