On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
> diff --git a/mm/filemap.c b/mm/filemap.c
> index a497024..08f3042 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
> int __lock_page_or_retry(struct page
On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
> diff --git a/mm/filemap.c b/mm/filemap.c
> index a497024..08f3042 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
> int __lock_page_or_retry(struct page
On Wed, Aug 30, 2017 at 12:51:02AM +0530, harsha wrote:
> Fixes checkpatch.pl warning: Use WARN_ON() rather than BUG_ON() and BUG()
>
> Signed-off-by: harsha
> ---
> drivers/staging/android/ion/ion.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Wed, Aug 30, 2017 at 12:51:02AM +0530, harsha wrote:
> Fixes checkpatch.pl warning: Use WARN_ON() rather than BUG_ON() and BUG()
>
> Signed-off-by: harsha
> ---
> drivers/staging/android/ion/ion.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Currently the driver boots only via device tree hence add a
dependency on CONFIG_OF. This leaves with a bunch of unused code
so clean that up. This patch also makes use of probe_new function
in place of the probe function so as to avoid passing i2c_device_id.
Signed-off-by: Keerthy
Currently the driver boots only via device tree hence add a
dependency on CONFIG_OF. This leaves with a bunch of unused code
so clean that up. This patch also makes use of probe_new function
in place of the probe function so as to avoid passing i2c_device_id.
Signed-off-by: Keerthy
---
Changes
vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1
vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Aug 29, 2017 at 10:10:37PM +0200, Thomas Gleixner wrote:
> On Tue, 29 Aug 2017, Peter Zijlstra wrote:
> > So I have a patch _somewhere_ that preserves the event<->cpu relation
> > across hotplug and disable/enable would be sufficient. If you want I can
> > try and dig that out and make it
On Tue, Aug 29, 2017 at 10:10:37PM +0200, Thomas Gleixner wrote:
> On Tue, 29 Aug 2017, Peter Zijlstra wrote:
> > So I have a patch _somewhere_ that preserves the event<->cpu relation
> > across hotplug and disable/enable would be sufficient. If you want I can
> > try and dig that out and make it
On Thursday 08 June 2017 07:41 PM, Javier Martinez Canillas wrote:
> On Thu, Jun 8, 2017 at 3:32 PM, Enric Balletbo Serra
> wrote:
>> Hi Keerthy:
>>
>> 2017-06-08 12:46 GMT+02:00 Keerthy :
>>> Currently the driver boots only via device tree hence add a
>>>
On Thursday 08 June 2017 07:41 PM, Javier Martinez Canillas wrote:
> On Thu, Jun 8, 2017 at 3:32 PM, Enric Balletbo Serra
> wrote:
>> Hi Keerthy:
>>
>> 2017-06-08 12:46 GMT+02:00 Keerthy :
>>> Currently the driver boots only via device tree hence add a
>>> dependency on CONFIG_OF. This leaves
On Wed, Aug 30, 2017 at 02:20:37PM +0900, Sergey Senozhatsky wrote:
> Byungchul, a quick question.
Hello Sergey,
> have you measured the performance impact? somehow my linux-next is
Yeah, it might have performance impact inevitably.
> notably slower than earlier 4.13 linux-next. (e.g.
On Wed, Aug 30, 2017 at 02:20:37PM +0900, Sergey Senozhatsky wrote:
> Byungchul, a quick question.
Hello Sergey,
> have you measured the performance impact? somehow my linux-next is
Yeah, it might have performance impact inevitably.
> notably slower than earlier 4.13 linux-next. (e.g.
From: Samuel Mendoza-Jonas
Date: Wed, 30 Aug 2017 14:37:21 +1000
> On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
>> From: Samuel Mendoza-Jonas
>> Date: Mon, 28 Aug 2017 16:18:40 +1000
>>
>> > This series (mainly patch 2) adds VLAN
From: Samuel Mendoza-Jonas
Date: Wed, 30 Aug 2017 14:37:21 +1000
> On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
>> From: Samuel Mendoza-Jonas
>> Date: Mon, 28 Aug 2017 16:18:40 +1000
>>
>> > This series (mainly patch 2) adds VLAN filtering to the NCSI
>> > implementation.
>> > A
On (08/29/17 19:58), Joe Perches wrote:
> > >
> > > Why?
> > >
> > > What's wrong with a simple printk?
> > > It'd still do a log_store.
> >
> > sure, it will. but in separate logbuf entries, and between two
> > consequent printk calls on the same CPU a lot of stuff can happen:
>
> I think you
On (08/29/17 19:58), Joe Perches wrote:
> > >
> > > Why?
> > >
> > > What's wrong with a simple printk?
> > > It'd still do a log_store.
> >
> > sure, it will. but in separate logbuf entries, and between two
> > consequent printk calls on the same CPU a lot of stuff can happen:
>
> I think you
Hi,
On Tuesday 29 August 2017 06:42 PM, Antoine Tenart wrote:
> Hi Kishon,
>
> On Tue, Aug 29, 2017 at 05:55:06PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote:
>>> On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
On
Hi,
On Tuesday 29 August 2017 06:42 PM, Antoine Tenart wrote:
> Hi Kishon,
>
> On Tue, Aug 29, 2017 at 05:55:06PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote:
>>> On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
On
On 08/23/2017 07:04 PM, Mark Rutland wrote:
> On Wed, Aug 23, 2017 at 10:58:42AM -0600, Tycho Andersen wrote:
>> Hi Mark,
>>
>> On Mon, Aug 14, 2017 at 05:50:47PM +0100, Mark Rutland wrote:
>>> That said, is there any reason not to use flush_tlb_kernel_range()
>>> directly?
>>
>> So it turns out
On 08/23/2017 07:04 PM, Mark Rutland wrote:
> On Wed, Aug 23, 2017 at 10:58:42AM -0600, Tycho Andersen wrote:
>> Hi Mark,
>>
>> On Mon, Aug 14, 2017 at 05:50:47PM +0100, Mark Rutland wrote:
>>> That said, is there any reason not to use flush_tlb_kernel_range()
>>> directly?
>>
>> So it turns out
Fixed coding style issue
Signed-off-by: Harsha Sharma
---
drivers/staging/rtl8712/xmit_linux.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/xmit_linux.c
b/drivers/staging/rtl8712/xmit_linux.c
index
Fixed coding style issue
Signed-off-by: Harsha Sharma
---
drivers/staging/rtl8712/xmit_linux.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/xmit_linux.c
b/drivers/staging/rtl8712/xmit_linux.c
index d13fd15..03c6b0c 100644
---
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film
Corporation Located in the United State, is Soliciting for the Right to use
Your Photo/Face and Personality as One of the Semi -Major Role/ Character in
our Upcoming ANIMATED Stereoscope 3D Movie-The
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film
Corporation Located in the United State, is Soliciting for the Right to use
Your Photo/Face and Personality as One of the Semi -Major Role/ Character in
our Upcoming ANIMATED Stereoscope 3D Movie-The
On 08/27/2017 05:48 AM, Kirill A. Shutemov wrote:
>> +/* Transparent huge pages are not supported. */
>> +if (unlikely(pmd_trans_huge(*pmd)))
>> +goto out_walk;
> That's looks like a blocker to me.
>
> Is there any problem with making it supported (besides plain coding)?
IIUC
On 08/27/2017 05:48 AM, Kirill A. Shutemov wrote:
>> +/* Transparent huge pages are not supported. */
>> +if (unlikely(pmd_trans_huge(*pmd)))
>> +goto out_walk;
> That's looks like a blocker to me.
>
> Is there any problem with making it supported (besides plain coding)?
IIUC
From: Huang Ying
The optimized clear_huge_page() isn't easy to read and understand.
This is suggested by Michael Hocko to improve it.
Suggested-by: Michal Hocko
Signed-off-by: "Huang, Ying"
---
mm/memory.c | 11 +++
1 file
From: Huang Ying
The optimized clear_huge_page() isn't easy to read and understand.
This is suggested by Michael Hocko to improve it.
Suggested-by: Michal Hocko
Signed-off-by: "Huang, Ying"
---
mm/memory.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
Hi Antoine,
On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> On the CP110 unit, which can be found on various Marvell platforms such
> as the 7k and 8k (currently), a comphy (common PHYs) hardware block can
> be found. This block provides a number of PHYs which can be used in
> various
Hi Antoine,
On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> On the CP110 unit, which can be found on various Marvell platforms such
> as the 7k and 8k (currently), a comphy (common PHYs) hardware block can
> be found. This block provides a number of PHYs which can be used in
> various
On (08/23/17 09:03), Byungchul Park wrote:
[..]
> > Byungchul, did you add the crosslock checks to lockdep? Can you have a look
> > at
> > the above report? That report namely doesn't make sense to me.
>
> The report is talking about the following lockup:
>
> A work in a worker
On (08/23/17 09:03), Byungchul Park wrote:
[..]
> > Byungchul, did you add the crosslock checks to lockdep? Can you have a look
> > at
> > the above report? That report namely doesn't make sense to me.
>
> The report is talking about the following lockup:
>
> A work in a worker
On Wed, Aug 30, 2017 at 10:15:37AM +0800, Ming Lei wrote:
> Hi,
>
> On Tue, Aug 29, 2017 at 05:52:42PM +0200, Oleksandr Natalenko wrote:
> > Hello.
> >
> > Re-tested with v4.13-rc7 + proposed patch and got the same result.
>
> Maybe there is another issue, I didn't use dmcrypt on raid10, will
>
On Wed, Aug 30, 2017 at 10:15:37AM +0800, Ming Lei wrote:
> Hi,
>
> On Tue, Aug 29, 2017 at 05:52:42PM +0200, Oleksandr Natalenko wrote:
> > Hello.
> >
> > Re-tested with v4.13-rc7 + proposed patch and got the same result.
>
> Maybe there is another issue, I didn't use dmcrypt on raid10, will
>
Hi,
>> This is great to see. Is there a Linux implementation of the server side (in
>> Samba?) so that the client can be tested without needing a Windows server?
>
> I'm not aware of a Linux implementation on server side.
Here's a very early work in progress branch:
Hi,
>> This is great to see. Is there a Linux implementation of the server side (in
>> Samba?) so that the client can be tested without needing a Windows server?
>
> I'm not aware of a Linux implementation on server side.
Here's a very early work in progress branch:
On 08/29/2017 07:15 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 03:18:25PM +0200, Laurent Dufour wrote:
>> On 29/08/2017 14:04, Peter Zijlstra wrote:
>>> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
On 27/08/2017 02:18, Kirill A. Shutemov wrote:
>> +
>> +
On 08/29/2017 07:15 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 03:18:25PM +0200, Laurent Dufour wrote:
>> On 29/08/2017 14:04, Peter Zijlstra wrote:
>>> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
On 27/08/2017 02:18, Kirill A. Shutemov wrote:
>> +
>> +
On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
> disabled)?
Nogo.
...
[[0;32m OK [0m] Mounted /abuild.
[[0;32m OK [0m] Mounted /homer.
> On Aug 27, 2017, at 8:05 PM, Mathieu Desnoyers
> wrote:
>
> - On Aug 27, 2017, at 3:53 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>>> On Aug 27, 2017, at 1:50 PM, Mathieu Desnoyers
>>>
>>> wrote:
>>>
>>> Add a new
On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
> disabled)?
Nogo.
...
[[0;32m OK [0m] Mounted /abuild.
[[0;32m OK [0m] Mounted /homer.
> On Aug 27, 2017, at 8:05 PM, Mathieu Desnoyers
> wrote:
>
> - On Aug 27, 2017, at 3:53 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>>> On Aug 27, 2017, at 1:50 PM, Mathieu Desnoyers
>>>
>>> wrote:
>>>
>>> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
>>>
On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
> From: Samuel Mendoza-Jonas
> Date: Mon, 28 Aug 2017 16:18:40 +1000
>
> > This series (mainly patch 2) adds VLAN filtering to the NCSI implementation.
> > A fair amount of code already exists in the NCSI stack for
On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
> From: Samuel Mendoza-Jonas
> Date: Mon, 28 Aug 2017 16:18:40 +1000
>
> > This series (mainly patch 2) adds VLAN filtering to the NCSI implementation.
> > A fair amount of code already exists in the NCSI stack for VLAN filtering
> > but
>
From: "Ziqian SUN (Zamir)"
The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print
From: "Ziqian SUN (Zamir)"
The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and
On 08/30/2017 11:25 AM, Ziqian SUN (Zamir) wrote:
From: "Ziqian SUN (Zamir)"
The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer
On 08/30/2017 11:25 AM, Ziqian SUN (Zamir) wrote:
From: "Ziqian SUN (Zamir)"
The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as
Currently the device is kept in D0, there is an opportunity
to save power by enabling runtime pm.
Device can be daisy chained from PMIC and we can't rely on I2C core
for auto resume/suspend. Driver will decide when to resume/suspend.
Signed-off-by: Divagar Mohandass
Currently the device is kept in D0, there is an opportunity
to save power by enabling runtime pm.
Device can be daisy chained from PMIC and we can't rely on I2C core
for auto resume/suspend. Driver will decide when to resume/suspend.
Signed-off-by: Divagar Mohandass
---
Obtain the size of the EEPROM chip from DT if the "size" property is
specified for the device.
Signed-off-by: Divagar Mohandass
---
drivers/misc/eeprom/at24.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c
Obtain the size of the EEPROM chip from DT if the "size" property is
specified for the device.
Signed-off-by: Divagar Mohandass
---
drivers/misc/eeprom/at24.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 764ff5df..2199c42
This series adds support for eeprom "size" property which will be read by the
driver for eeprom size. The existing ACPI has a different default size which
can be overridden with a DSD property value provided by the platform FW.
This series also adds support for runtime PM. The eeprom driver
This series adds support for eeprom "size" property which will be read by the
driver for eeprom size. The existing ACPI has a different default size which
can be overridden with a DSD property value provided by the platform FW.
This series also adds support for runtime PM. The eeprom driver
This adds eeprom "size" as optional property for i2c eeproms.
The "size" property allows explicitly specifying the size of the
EEPROM chip in bytes.
Signed-off-by: Divagar Mohandass
---
Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
1 file changed, 2
This adds eeprom "size" as optional property for i2c eeproms.
The "size" property allows explicitly specifying the size of the
EEPROM chip in bytes.
Signed-off-by: Divagar Mohandass
---
Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi Sakari,
Thanks for your review comments.
My comments below.
---
^Divagar
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:26 PM
>To: Mohandass, Divagar
>Cc: robh...@kernel.org; mark.rutl...@arm.com;
Hi Sakari,
Thanks for your review comments.
My comments below.
---
^Divagar
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:26 PM
>To: Mohandass, Divagar
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
Hi Mathieu,
On Sun, Aug 27, 2017 at 01:50:35PM -0700, Mathieu Desnoyers wrote:
> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
> system call. It allows processes to register their intent to have their
> threads issue core serializing barriers in addition to memory barriers
Hi Mathieu,
On Sun, Aug 27, 2017 at 01:50:35PM -0700, Mathieu Desnoyers wrote:
> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
> system call. It allows processes to register their intent to have their
> threads issue core serializing barriers in addition to memory barriers
Hi Sakari,
Thanks for your review comments. Will address it in next patch version.
---
^Divagar
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:43 PM
>To: Mohandass, Divagar
>Cc: robh...@kernel.org;
Hi Sakari,
Thanks for your review comments. Will address it in next patch version.
---
^Divagar
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:43 PM
>To: Mohandass, Divagar
>Cc: robh...@kernel.org; mark.rutl...@arm.com;
Hi Sakari,
Thanks for your review comments. Will address it in next patch version.
---
^Divagar
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:41 PM
>To: Mohandass, Divagar
>Cc: robh...@kernel.org;
Hi Sakari,
Thanks for your review comments. Will address it in next patch version.
---
^Divagar
>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:41 PM
>To: Mohandass, Divagar
>Cc: robh...@kernel.org; mark.rutl...@arm.com;
On 08/29/2017 05:34 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
>> On 27/08/2017 02:18, Kirill A. Shutemov wrote:
+
+ if (unlikely(!vma->anon_vma))
+ goto unlock;
>>> It deserves a comment.
>> You're right I'll add it in the
On 08/29/2017 05:34 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
>> On 27/08/2017 02:18, Kirill A. Shutemov wrote:
+
+ if (unlikely(!vma->anon_vma))
+ goto unlock;
>>> It deserves a comment.
>> You're right I'll add it in the
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, August 29, 2017 6:31 PM
> To: Long Li
> Cc: KY Srinivasan ; Haiyang Zhang
> ; James E . J . Bottomley
>
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, August 29, 2017 6:31 PM
> To: Long Li
> Cc: KY Srinivasan ; Haiyang Zhang
> ; James E . J . Bottomley
> ; de...@linuxdriverproject.org; linux-
> s...@vger.kernel.org;
On Tue, 2017-08-29 at 13:08 +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 8/29/2017 12:20 PM, Chunfeng Yun wrote:
>
> > The mt8173-mtu3.txt actually holds the bindings for all mediatek
> > SoCs with usb3 DRD IP, so add a generic compatible and change the
> > name to mediatek,mtu3.txt.
> >
> >
On Tue, 2017-08-29 at 13:08 +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 8/29/2017 12:20 PM, Chunfeng Yun wrote:
>
> > The mt8173-mtu3.txt actually holds the bindings for all mediatek
> > SoCs with usb3 DRD IP, so add a generic compatible and change the
> > name to mediatek,mtu3.txt.
> >
> >
16bbc115a9 # 08:17 G 11
0 0 0 Merge tag 'perf-core-for-mingo-4.14-20170829' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
git bisect bad 8ea7c2d9a971f95ec9f6ffac60cb4847d35f0b36 # 08:27 B 0
3 16 0 manual merge of locking/core
git bisect
00 0 0day base guard for 'devel-catchup-201708300632'
git bisect good 1b2f76d77a277bb70d38ad0991ed7f16bbc115a9 # 08:17 G 11
00 0 Merge tag 'perf-core-for-mingo-4.14-20170829' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
git b
From: Eric Biggers
Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
write killable") made it possible to kill a forking task while it is
waiting to acquire its ->mmap_sem for write, in dup_mmap().
However, it was overlooked that this introduced an new
From: Eric Biggers
Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
write killable") made it possible to kill a forking task while it is
waiting to acquire its ->mmap_sem for write, in dup_mmap().
However, it was overlooked that this introduced an new error path before
the
On Sat, Aug 26, 2017 at 11:41:06AM +0530, Arvind Yadav wrote:
> mei_cl_device_id are not supposed to change at runtime. All functions
> working with mei_cl_device_id provided by work
> with const mei_cl_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
On Sat, Aug 26, 2017 at 11:41:06AM +0530, Arvind Yadav wrote:
> mei_cl_device_id are not supposed to change at runtime. All functions
> working with mei_cl_device_id provided by work
> with const mei_cl_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
On Wed, Aug 23, 2017 at 10:04:08PM +0530, Arvind Yadav wrote:
> amba_id are not supposed to change at runtime. All functions
> working with const amba_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
Reviewed-by: Guenter Roeck
On Wed, Aug 23, 2017 at 10:04:08PM +0530, Arvind Yadav wrote:
> amba_id are not supposed to change at runtime. All functions
> working with const amba_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
Reviewed-by: Guenter Roeck
> ---
> drivers/watchdog/sp805_wdt.c |
On Mon, Aug 21, 2017 at 10:18:38PM +0530, Arvind Yadav wrote:
> i2c_device_id are not supposed to change at runtime. All functions
> working with i2c_device_id provided by work with
> const i2c_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
On Mon, Aug 21, 2017 at 10:18:38PM +0530, Arvind Yadav wrote:
> i2c_device_id are not supposed to change at runtime. All functions
> working with i2c_device_id provided by work with
> const i2c_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
Reviewed-by:
From: "Ziqian SUN (Zamir)"
The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print
From: "Ziqian SUN (Zamir)"
The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and
On Wed, Aug 16, 2017 at 10:27:03AM +0530, Arvind Yadav wrote:
> pnp_device_id are not supposed to change at runtime. All functions
> working with pnp_device_id provided by work with
> const pnp_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
On Wed, Aug 16, 2017 at 10:27:03AM +0530, Arvind Yadav wrote:
> pnp_device_id are not supposed to change at runtime. All functions
> working with pnp_device_id provided by work with
> const pnp_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
Reviewed-by:
Nadav Amit wrote:
> Jerome Glisse wrote:
>
>> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>>> Jérôme Glisse wrote:
>>>
Replacing all mmu_notifier_invalidate_page() by
mmu_notifier_invalidat_range()
Nadav Amit wrote:
> Jerome Glisse wrote:
>
>> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>>> Jérôme Glisse wrote:
>>>
Replacing all mmu_notifier_invalidate_page() by
mmu_notifier_invalidat_range()
and making sure it is bracketed by call to
Jerome Glisse wrote:
> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>> Jérôme Glisse wrote:
>>
>>> Replacing all mmu_notifier_invalidate_page() by
>>> mmu_notifier_invalidat_range()
>>> and making sure it is bracketed by call to
>>>
Jerome Glisse wrote:
> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>> Jérôme Glisse wrote:
>>
>>> Replacing all mmu_notifier_invalidate_page() by
>>> mmu_notifier_invalidat_range()
>>> and making sure it is bracketed by call to
>>> mmu_notifier_invalidate_range_start/
>>>
Hi Robert,
Got it and thanks your reply.
Shaokun
On 2017/8/29 20:47, Robert Richter wrote:
> Shaokun,
>
> On 29.08.17 17:26:00, Zhangshaokun wrote:
>> On 2017/8/24 20:03, Ganapatrao Kulkarni wrote:
>>> This is not a full event list, but a short list of useful events.
>>>
>>> Signed-off-by:
Hi Robert,
Got it and thanks your reply.
Shaokun
On 2017/8/29 20:47, Robert Richter wrote:
> Shaokun,
>
> On 29.08.17 17:26:00, Zhangshaokun wrote:
>> On 2017/8/24 20:03, Ganapatrao Kulkarni wrote:
>>> This is not a full event list, but a short list of useful events.
>>>
>>> Signed-off-by:
Since the i2c driver of Spreadtrum can not be build as one module, thus
it should depend on CONFIG_I2C is build in.
Signed-off-by: Baolin Wang
---
drivers/i2c/busses/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Since the i2c driver of Spreadtrum can not be build as one module, thus
it should depend on CONFIG_I2C is build in.
Signed-off-by: Baolin Wang
---
drivers/i2c/busses/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig
v2: Undo the renaming of the dft_eps_id variable in hci_pdn_table_ind
to resolve a compiler error.
Signed-off-by: Nick Fox
---
drivers/staging/gdm724x/hci_packet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gdm724x/hci_packet.h
v2: Undo the renaming of the dft_eps_id variable in hci_pdn_table_ind
to resolve a compiler error.
Signed-off-by: Nick Fox
---
drivers/staging/gdm724x/hci_packet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gdm724x/hci_packet.h
From: Philipp Rossak
The Nanopi M1 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Signed-off-by: Philipp Rossak
---
arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git
From: Philipp Rossak
The Nanopi M1 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Signed-off-by: Philipp Rossak
---
arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
From: Philipp Rossak
This Patchseries enables the IR controller and the dwmac-sun8i
on the Friendlyarm Nanopi M1 and Friendlyarm Nanopi M1 Plus boards.
On the Nanopi M1 Plus additionally the BT/Wifi module is activated.
Philipp Rossak (7):
ARM: dts: sun8i: h3: nanopi-m1:
From: Philipp Rossak
This Patchseries enables the IR controller and the dwmac-sun8i
on the Friendlyarm Nanopi M1 and Friendlyarm Nanopi M1 Plus boards.
On the Nanopi M1 Plus additionally the BT/Wifi module is activated.
Philipp Rossak (7):
ARM: dts: sun8i: h3: nanopi-m1: Enable IR controller
1 - 100 of 1820 matches
Mail list logo