On Thu, Aug 9, 2018 at 2:03 PM, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
> by lockdep and irqsoff latency tracer. It made both use tracepoints. But the
> latency tracer is triggering warnings when
On Thu, Aug 9, 2018 at 2:03 PM, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
> by lockdep and irqsoff latency tracer. It made both use tracepoints. But the
> latency tracer is triggering warnings when
On Thu, Aug 9, 2018 at 2:03 PM, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
> by lockdep and irqsoff latency tracer. It made both use tracepoints. But it
> caused lockdep to trigger several false
On Thu, Aug 9, 2018 at 2:03 PM, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
> by lockdep and irqsoff latency tracer. It made both use tracepoints. But it
> caused lockdep to trigger several false
writes:
> ebied...@xmission.com writes
>> Subject: [PATCH v6 6/6] signal: Don't restart fork when signals come in.
>>
>> Wen Yang and majiang
>> report that a periodic signal received during fork can cause fork to
>> continually restart preventing an application from making progress.
>>
>>
writes:
> ebied...@xmission.com writes
>> Subject: [PATCH v6 6/6] signal: Don't restart fork when signals come in.
>>
>> Wen Yang and majiang
>> report that a periodic signal received during fork can cause fork to
>> continually restart preventing an application from making progress.
>>
>>
Note: It is a part time job that won't interrupt your present work or business.
Looking forward to your response.
Best Regards,
Liu Nianzu
HR(Representative Manager)
Beijing Shougang Company Ltd.
No 15,Pingguoyuan Road,Shijingshan District,Beijing
Website: www.sggf.com.cn
Note: It is a part time job that won't interrupt your present work or business.
Looking forward to your response.
Best Regards,
Liu Nianzu
HR(Representative Manager)
Beijing Shougang Company Ltd.
No 15,Pingguoyuan Road,Shijingshan District,Beijing
Website: www.sggf.com.cn
On Fri 10-08-18 11:51:54, Vlastimil Babka wrote:
> On 08/10/2018 01:36 AM, Yang Shi wrote:
> > Unmapping vmas, which have VM_HUGETLB | VM_PFNMAP flag set or
> > have uprobes set, need get done with write mmap_sem held since
> > they may update vm_flags.
> >
> > So, it might be not safe enough to
Hello,
syzbot found the following crash on:
HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
kernel config: https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
On Fri 10-08-18 11:51:54, Vlastimil Babka wrote:
> On 08/10/2018 01:36 AM, Yang Shi wrote:
> > Unmapping vmas, which have VM_HUGETLB | VM_PFNMAP flag set or
> > have uprobes set, need get done with write mmap_sem held since
> > they may update vm_flags.
> >
> > So, it might be not safe enough to
Hello,
syzbot found the following crash on:
HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
kernel config: https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
On Thu, 2018-08-09 at 16:22 +0800, Jianxin Pan wrote:
> Try to add basic DT support for the Amlogic's Meson-G12A S905D2 SoC,
> which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
> Timer, UART. It's capable of booting up into the serial console.
>
> Signed-off-by: Jianxin
Could
On Thu, 2018-08-09 at 16:22 +0800, Jianxin Pan wrote:
> Try to add basic DT support for the Amlogic's Meson-G12A S905D2 SoC,
> which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
> Timer, UART. It's capable of booting up into the serial console.
>
> Signed-off-by: Jianxin
Could
On Fri, Aug 10, 2018 at 01:21:18AM -0700, Stephane Eranian wrote:
> On Thu, Aug 9, 2018 at 1:07 AM Jiri Olsa wrote:
> >
> > On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> > > This patch fixes a bug in ordered_event.c:alloc_event().
> > > An ordered_event struct was not
On Fri, Aug 10, 2018 at 01:21:18AM -0700, Stephane Eranian wrote:
> On Thu, Aug 9, 2018 at 1:07 AM Jiri Olsa wrote:
> >
> > On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> > > This patch fixes a bug in ordered_event.c:alloc_event().
> > > An ordered_event struct was not
On 08/10, Oleg Nesterov wrote:
>
> @@ -920,7 +918,8 @@ probe_event_enable(struct trace_uprobe *
> ret = uprobe_register(tu->inode, tu->offset, >consumer);
> if (ret)
> goto err_buffer;
> -
> + add:
> + list_add_tail_rcu(>list, >tp.files);
if (link)
On 08/10, Oleg Nesterov wrote:
>
> @@ -920,7 +918,8 @@ probe_event_enable(struct trace_uprobe *
> ret = uprobe_register(tu->inode, tu->offset, >consumer);
> if (ret)
> goto err_buffer;
> -
> + add:
> + list_add_tail_rcu(>list, >tp.files);
if (link)
On Thu, 2018-08-09 at 17:17 -0700, Andrey Smirnov wrote:
> Add HID quirk driver for Xbox One S controller over bluetooth.
>
> This driver only adds support for rumble. Standard controller
> functionality is exposed by default HID driver.
Did you manage to make the joypad work without hacks in
On Thu, 2018-08-09 at 17:17 -0700, Andrey Smirnov wrote:
> Add HID quirk driver for Xbox One S controller over bluetooth.
>
> This driver only adds support for rumble. Standard controller
> functionality is exposed by default HID driver.
Did you manage to make the joypad work without hacks in
On 08/09, Steven Rostedt wrote:
>
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -952,7 +952,7 @@ probe_event_disable(struct trace_uprobe *tu, struct
> trace_event_file *file)
>
> list_del_rcu(>list);
> /* synchronize with
On 08/09, Steven Rostedt wrote:
>
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -952,7 +952,7 @@ probe_event_disable(struct trace_uprobe *tu, struct
> trace_event_file *file)
>
> list_del_rcu(>list);
> /* synchronize with
No no... I only gave it a Reviewed-by tag because I didn't want you to
resend again... :P
regards,
dan carpenter
No no... I only gave it a Reviewed-by tag because I didn't want you to
resend again... :P
regards,
dan carpenter
://github.com/0day-ci/linux/commits/Leonardo-Br-s/staging-fbtft-Moves-from-macro-definition-to-macro-usage/20180810-154004
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>
://github.com/0day-ci/linux/commits/Leonardo-Br-s/staging-fbtft-Moves-from-macro-definition-to-macro-usage/20180810-154004
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>
From: Rafael J. Wysocki
Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
with stopped tick) missed the case when the target residencies of
deep idle states of CPUs are above the tick boundary which may cause
the CPU to get stuck in a shallow idle state for a long time.
Say
From: Rafael J. Wysocki
Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
with stopped tick) missed the case when the target residencies of
deep idle states of CPUs are above the tick boundary which may cause
the CPU to get stuck in a shallow idle state for a long time.
Say
On Fri, 10 Aug 2018 12:49:08 +0200
Pierre Morel wrote:
> On 10/08/2018 11:14, Cornelia Huck wrote:
> > On Wed, 8 Aug 2018 10:44:27 -0400
> > Tony Krowiak wrote:
> >
> >> From: Tony Krowiak
> >>
> >> Let's call PAPQ(ZAPQ) to zeroize a queue:
> >>
> >> * For each queue configured for a
On Fri, 10 Aug 2018 12:49:08 +0200
Pierre Morel wrote:
> On 10/08/2018 11:14, Cornelia Huck wrote:
> > On Wed, 8 Aug 2018 10:44:27 -0400
> > Tony Krowiak wrote:
> >
> >> From: Tony Krowiak
> >>
> >> Let's call PAPQ(ZAPQ) to zeroize a queue:
> >>
> >> * For each queue configured for a
On Friday, August 10, 2018 11:12:18 AM CEST Quentin Perret wrote:
> On Friday 10 Aug 2018 at 10:41:56 (+0200), Rafael J. Wysocki wrote:
> > On Friday, August 10, 2018 10:15:39 AM CEST Quentin Perret wrote:
[cut]
> Agreed. EAS and IPA don't care about the absolute real power values, all
> they
On Friday, August 10, 2018 11:12:18 AM CEST Quentin Perret wrote:
> On Friday 10 Aug 2018 at 10:41:56 (+0200), Rafael J. Wysocki wrote:
> > On Friday, August 10, 2018 10:15:39 AM CEST Quentin Perret wrote:
[cut]
> Agreed. EAS and IPA don't care about the absolute real power values, all
> they
On Wed, 2018-08-08 at 16:27 +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 08, 2018 at 02:58:15PM +, Leonard Crestez wrote:
> > On Wed, 2018-08-08 at 15:19 +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Aug 08, 2018 at 11:37:14AM +, Leonard Crestez wrote:
> > > > On Wed, 2018-08-08 at 12:14
On Wed, 2018-08-08 at 16:27 +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 08, 2018 at 02:58:15PM +, Leonard Crestez wrote:
> > On Wed, 2018-08-08 at 15:19 +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Aug 08, 2018 at 11:37:14AM +, Leonard Crestez wrote:
> > > > On Wed, 2018-08-08 at 12:14
On Fri, Aug 10, 2018 at 11:20 AM wrote:
>
> On Fri, Aug 10, 2018 at 09:57:18AM +0200, Rafael J . Wysocki wrote:
> > From: Rafael J. Wysocki
> > Subject: [PATCH] cpuidle: menu: Handle stopped tick more aggressively
> >
> > Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
> >
On Fri, Aug 10, 2018 at 11:20 AM wrote:
>
> On Fri, Aug 10, 2018 at 09:57:18AM +0200, Rafael J . Wysocki wrote:
> > From: Rafael J. Wysocki
> > Subject: [PATCH] cpuidle: menu: Handle stopped tick more aggressively
> >
> > Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
> >
Hi!
> * Pavel Machek [180727 11:35]:
> > Hi!
> > > > > high even before modem (and thus USB) is enabled.
> > > > >
> > > > > Interestingly, CyanogenMod and Jolla seem to have higher power
> > > > > consumption than stock operating system.
> > > > >
> > > > > (My Linux can survive for 10 hours,
Hi!
> * Pavel Machek [180727 11:35]:
> > Hi!
> > > > > high even before modem (and thus USB) is enabled.
> > > > >
> > > > > Interestingly, CyanogenMod and Jolla seem to have higher power
> > > > > consumption than stock operating system.
> > > > >
> > > > > (My Linux can survive for 10 hours,
Linus,
here is a driver bugfix for I2C. The bug was found by systematically
stress testing the driver, so I am confident to merge it that late in
the cycle although it is probably unusually large.
Please pull.
Thanks,
Wolfram
The following changes since commit
Linus,
here is a driver bugfix for I2C. The bug was found by systematically
stress testing the driver, so I am confident to merge it that late in
the cycle although it is probably unusually large.
Please pull.
Thanks,
Wolfram
The following changes since commit
On Thu, Aug 09, 2018 at 11:03:55AM -0700, Doug Anderson wrote:
> On Fri, Aug 3, 2018 at 5:18 AM, wrote:
> > Also, spi core framework will set the transfer speed to controller max
> > frequency
> > if transfer frequency is greater than controller max frequency.
> > Please mention if you have a
On Thu, Aug 09, 2018 at 11:03:55AM -0700, Doug Anderson wrote:
> On Fri, Aug 3, 2018 at 5:18 AM, wrote:
> > Also, spi core framework will set the transfer speed to controller max
> > frequency
> > if transfer frequency is greater than controller max frequency.
> > Please mention if you have a
Use is_multicast_ether_addr instead of custom IS_MCAST in
core/rtw_security.c. In all uses the address array is properly
aligned.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
v2: checked that in all uses of is_multicast_ether_addr
the address array/memory is properly
Remove the now unused IS_MCAST.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
drivers/staging/rtl8188eu/include/wifi.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/wifi.h
b/drivers/staging/rtl8188eu/include/wifi.h
index
Use is_multicast_ether_addr instead of custom IS_MCAST in
core/rtw_recv.c. In all uses the address array/memory is
properly aligned.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
drivers/staging/rtl8188eu/core/rtw_recv.c | 35 ---
1 file changed, 18
Use is_multicast_ether_addr instead of custom IS_MCAST in
core/rtw_security.c. In all uses the address array is properly
aligned.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
v2: checked that in all uses of is_multicast_ether_addr
the address array/memory is properly
Remove the now unused IS_MCAST.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
drivers/staging/rtl8188eu/include/wifi.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/wifi.h
b/drivers/staging/rtl8188eu/include/wifi.h
index
Use is_multicast_ether_addr instead of custom IS_MCAST in
core/rtw_recv.c. In all uses the address array/memory is
properly aligned.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
drivers/staging/rtl8188eu/core/rtw_recv.c | 35 ---
1 file changed, 18
Use rtlwifi/phydm/phydm_reg.h instead of odm_reg.h and
remove the now unused odm_reg.h.
All defines from odm_reg.h are defined with the same values
in rtlwifi/phydm/phydm_reg.h.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
.../staging/rtl8188eu/include/odm_precomp.h | 2
Use rtlwifi/phydm/phydm_reg.h instead of odm_reg.h and
remove the now unused odm_reg.h.
All defines from odm_reg.h are defined with the same values
in rtlwifi/phydm/phydm_reg.h.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
.../staging/rtl8188eu/include/odm_precomp.h | 2
Use is_multicast_ether_addr instead of custom IS_MCAST in
core/rtw_xmit.c. In all uses the address array is properly
aligned.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
drivers/staging/rtl8188eu/core/rtw_xmit.c | 35 +++
1 file changed, 16 insertions(+),
Use is_multicast_ether_addr instead of custom IS_MCAST in
core/rtw_xmit.c. In all uses the address array is properly
aligned.
Signed-off-by: Michael Straube
Reviewed-by: Dan Carpenter
---
drivers/staging/rtl8188eu/core/rtw_xmit.c | 35 +++
1 file changed, 16 insertions(+),
On 10/08/2018 11:14, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:27 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Let's call PAPQ(ZAPQ) to zeroize a queue:
* For each queue configured for a mediated matrix device
when it is released.
Zeroizing a queue resets the queue, clears all
On 10/08/2018 11:14, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:27 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Let's call PAPQ(ZAPQ) to zeroize a queue:
* For each queue configured for a mediated matrix device
when it is released.
Zeroizing a queue resets the queue, clears all
On 08/10/2018 01:36 AM, Yang Shi wrote:
> Unmapping vmas, which have VM_HUGETLB | VM_PFNMAP flag set or
> have uprobes set, need get done with write mmap_sem held since
> they may update vm_flags.
>
> So, it might be not safe enough to deal with these kind of special
> mappings with read
On 08/10/2018 01:36 AM, Yang Shi wrote:
> Unmapping vmas, which have VM_HUGETLB | VM_PFNMAP flag set or
> have uprobes set, need get done with write mmap_sem held since
> they may update vm_flags.
>
> So, it might be not safe enough to deal with these kind of special
> mappings with read
We can safely enable the breakpoint back for both the fail
and success paths by checking only the bp->attr.disabled,
which either holds the new 'requested' disabled state or
the original breakpoint state.
Suggested-by: Oleg Nesterov
Link:
We can safely enable the breakpoint back for both the fail
and success paths by checking only the bp->attr.disabled,
which either holds the new 'requested' disabled state or
the original breakpoint state.
Suggested-by: Oleg Nesterov
Link:
Once the breakpoint was succesfully modified, the attr->disabled
value is in bp->attr.disabled. So there's no reason to set it
again, removing that.
Acked-by: Oleg Nesterov
Link: http://lkml.kernel.org/n/tip-v5oaellzsmyszv3rfucux...@git.kernel.org
Signed-off-by: Jiri Olsa
---
Currently we enable the breakpoint back only if the breakpoint
modification was successful. If it fails we can leave the
breakpoint in disabled state with attr->disabled == 0.
We can safely enable the breakpoint back for both the fail
and success paths by checking the bp->attr.disabled, which
Adding to tests that aims on kernel breakpoint
modification bugs.
First test creates HW breakpoint, tries to change
it and checks it was properly changed. It aims
on kernel issue that prevents HW breakpoint to
be changed via ptrace interface.
The first test forks, the child sets itself as ptrace
We need to change the breakpoint even if the attr with
new fields has disabled set to true.
Current code prevents following user code to change
the breakpoint address:
ptrace(PTRACE_POKEUSER, child, offsetof(struct user, u_debugreg[0]), addr_1)
ptrace(PTRACE_POKEUSER, child, offsetof(struct
hi,
Milind reported that modify_user_hw_breakpoint wouldn't
allow the breakpoint changing if the new attr had 'disabled'
set to true.
I found a case where it actualy prevents ptrace user interface
to change the breakpoint. It's described in patch 1 as perf test,
patch 2 is the breakpoint code
Once the breakpoint was succesfully modified, the attr->disabled
value is in bp->attr.disabled. So there's no reason to set it
again, removing that.
Acked-by: Oleg Nesterov
Link: http://lkml.kernel.org/n/tip-v5oaellzsmyszv3rfucux...@git.kernel.org
Signed-off-by: Jiri Olsa
---
Currently we enable the breakpoint back only if the breakpoint
modification was successful. If it fails we can leave the
breakpoint in disabled state with attr->disabled == 0.
We can safely enable the breakpoint back for both the fail
and success paths by checking the bp->attr.disabled, which
Adding to tests that aims on kernel breakpoint
modification bugs.
First test creates HW breakpoint, tries to change
it and checks it was properly changed. It aims
on kernel issue that prevents HW breakpoint to
be changed via ptrace interface.
The first test forks, the child sets itself as ptrace
We need to change the breakpoint even if the attr with
new fields has disabled set to true.
Current code prevents following user code to change
the breakpoint address:
ptrace(PTRACE_POKEUSER, child, offsetof(struct user, u_debugreg[0]), addr_1)
ptrace(PTRACE_POKEUSER, child, offsetof(struct
hi,
Milind reported that modify_user_hw_breakpoint wouldn't
allow the breakpoint changing if the new attr had 'disabled'
set to true.
I found a case where it actualy prevents ptrace user interface
to change the breakpoint. It's described in patch 1 as perf test,
patch 2 is the breakpoint code
Hi!
On droid4, "sudo poweroff" reboots the system... which is not exactly
welcome, because mainline kernel will discharge the battery in 10
hours.
I learned to reboot into stock Motorola Android (lasts few days), but
that takes some clicking; easier solution is powering it off in
SafeStrap ...
Hi!
On droid4, "sudo poweroff" reboots the system... which is not exactly
welcome, because mainline kernel will discharge the battery in 10
hours.
I learned to reboot into stock Motorola Android (lasts few days), but
that takes some clicking; easier solution is powering it off in
SafeStrap ...
On 10.08.18 11:44, Dan Carpenter wrote:
Looks good. Thanks! I reviewed the series.
Reviewed-by: Dan Carpenter
Thanks,
Michael
On 10.08.18 11:44, Dan Carpenter wrote:
Looks good. Thanks! I reviewed the series.
Reviewed-by: Dan Carpenter
Thanks,
Michael
On Wed 2018-08-08 02:05:12, Tony Lindgren wrote:
> * Pavel Machek [180727 11:35]:
> > Hi!
> > > > > high even before modem (and thus USB) is enabled.
> > > > >
> > > > > Interestingly, CyanogenMod and Jolla seem to have higher power
> > > > > consumption than stock operating system.
> > > > >
> >
On Wed 2018-08-08 02:05:12, Tony Lindgren wrote:
> * Pavel Machek [180727 11:35]:
> > Hi!
> > > > > high even before modem (and thus USB) is enabled.
> > > > >
> > > > > Interestingly, CyanogenMod and Jolla seem to have higher power
> > > > > consumption than stock operating system.
> > > > >
> >
On Fri, Aug 10, 2018 at 11:46:20AM +0300, Stefan Popa wrote:
> From: Crestez Dan Leonard
>
> The regmap API usually assumes that bulk read operations will read a
> range of registers but some I2C/SPI devices have certain registers for
> which a such a read operation will return data from an
On Fri, Aug 10, 2018 at 11:46:20AM +0300, Stefan Popa wrote:
> From: Crestez Dan Leonard
>
> The regmap API usually assumes that bulk read operations will read a
> range of registers but some I2C/SPI devices have certain registers for
> which a such a read operation will return data from an
On 08/10/18 at 04:45pm, Dave Young wrote:
> On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> > When booting with efi=noruntime, we call efi_runtime_map_copy() while
> > loading the kdump kernel, and trip over a NULL efi.memmap.map. Avoid
> > that and a useless allocation when the only mapping we
On 08/10/18 at 04:45pm, Dave Young wrote:
> On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> > When booting with efi=noruntime, we call efi_runtime_map_copy() while
> > loading the kdump kernel, and trip over a NULL efi.memmap.map. Avoid
> > that and a useless allocation when the only mapping we
On Thu, Aug 9, 2018 at 11:14 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Aug 09, 2018 at 08:40:06PM -0700, John Joseph wrote:
> > Acked-by: John Joseph
>
> Why are you acking something you supposidly already signed-off on?
Sorry, my fault, wasn't sure what the protocol was for these so I
suggested
On Thu, Aug 9, 2018 at 11:14 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Aug 09, 2018 at 08:40:06PM -0700, John Joseph wrote:
> > Acked-by: John Joseph
>
> Why are you acking something you supposidly already signed-off on?
Sorry, my fault, wasn't sure what the protocol was for these so I
suggested
On 08/10/2018 01:36 AM, Yang Shi wrote:
> Introduces three new helper functions:
> * addr_ok()
> * munmap_lookup_vma()
> * munlock_vmas()
>
> They will be used by do_munmap() and the new do_munmap with zapping
> large mapping early in the later patch.
>
> There is no functional change,
On 08/10/2018 01:36 AM, Yang Shi wrote:
> Introduces three new helper functions:
> * addr_ok()
> * munmap_lookup_vma()
> * munlock_vmas()
>
> They will be used by do_munmap() and the new do_munmap with zapping
> large mapping early in the later patch.
>
> There is no functional change,
On Fri, 2018-08-10 at 16:45 +0800, Dave Young wrote:
>
> BTW, this patch only fix the kexec load phase problem, even if kexec
> load successfully with the fix, the 2nd kernel can not boot because efi
> memmap info is not correct and usable.
Hm. I didn't do anything else with kexec, but did
On Fri, 2018-08-10 at 16:45 +0800, Dave Young wrote:
>
> BTW, this patch only fix the kexec load phase problem, even if kexec
> load successfully with the fix, the 2nd kernel can not boot because efi
> memmap info is not correct and usable.
Hm. I didn't do anything else with kexec, but did
On Fri, Aug 10, 2018 at 03:43:02PM +0900, Seung-Woo Kim wrote:
> On 2018년 08월 08일 19:06, Seung-Woo Kim wrote:
> > On 2018년 07월 05일 09:52, Al Viro wrote:
> >> On Mon, Jul 02, 2018 at 10:01:25PM -0700, Linus Torvalds wrote:
> >>> On Mon, Jul 2, 2018 at 9:43 PM Seung-Woo Kim
> >>> wrote:
>
>
On Fri, Aug 10, 2018 at 03:43:02PM +0900, Seung-Woo Kim wrote:
> On 2018년 08월 08일 19:06, Seung-Woo Kim wrote:
> > On 2018년 07월 05일 09:52, Al Viro wrote:
> >> On Mon, Jul 02, 2018 at 10:01:25PM -0700, Linus Torvalds wrote:
> >>> On Mon, Jul 2, 2018 at 9:43 PM Seung-Woo Kim
> >>> wrote:
>
>
On Wednesday 08 August 2018 10:27 PM, Lorenzo Pieralisi wrote:
> On Tue, Jul 24, 2018 at 11:01:46PM +0530, Vignesh R wrote:
>> Make workaround for errata i870 applicable in Host mode as
>> well(previously it was enabled only for EP mode) as per errata
>> documentation:
On Wednesday 08 August 2018 10:27 PM, Lorenzo Pieralisi wrote:
> On Tue, Jul 24, 2018 at 11:01:46PM +0530, Vignesh R wrote:
>> Make workaround for errata i870 applicable in Host mode as
>> well(previously it was enabled only for EP mode) as per errata
>> documentation:
Add a Clock driver for Always-On part of
the Amlogic Meson-G12A SoC.
-The patch depends on "clk: meson-g12a: Add EE clock controller driver" patch
[1]
the parent clock of ao_clk81 is clk81 clock which provided in EE controller
driver;
the file of Makefile modify based on EE controller driver
Add a Clock driver for Always-On part of
the Amlogic Meson-G12A SoC.
-The patch depends on "clk: meson-g12a: Add EE clock controller driver" patch
[1]
the parent clock of ao_clk81 is clk81 clock which provided in EE controller
driver;
the file of Makefile modify based on EE controller driver
Add a Clock driver for the ALways-On part
of the Amlogic Meson-G12A SoC.
Signed-off-by: Jian Hu
---
drivers/clk/meson/Makefile | 2 +-
drivers/clk/meson/g12a-aoclk.c | 170 +
drivers/clk/meson/g12a-aoclk.h | 36 +
3 files changed, 207
Add a Clock driver for the ALways-On part
of the Amlogic Meson-G12A SoC.
Signed-off-by: Jian Hu
---
drivers/clk/meson/Makefile | 2 +-
drivers/clk/meson/g12a-aoclk.c | 170 +
drivers/clk/meson/g12a-aoclk.h | 36 +
3 files changed, 207
Add new clock controller compatible and dt-bingdings headers
for the Always-On domain of the g12a SoC
Signed-off-by: Jian Hu
---
.../bindings/clock/amlogic,gxbb-aoclkc.txt | 1 +
include/dt-bindings/clock/g12a-aoclkc.h| 28 ++
2 files changed, 29
Add new clock controller compatible and dt-bingdings headers
for the Always-On domain of the g12a SoC
Signed-off-by: Jian Hu
---
.../bindings/clock/amlogic,gxbb-aoclkc.txt | 1 +
include/dt-bindings/clock/g12a-aoclkc.h| 28 ++
2 files changed, 29
On 08/10/2018 01:36 AM, Yang Shi wrote:
> Unmapping vmas, which have VM_HUGETLB | VM_PFNMAP flag set or
> have uprobes set, need get done with write mmap_sem held since
> they may update vm_flags.
>
> So, it might be not safe enough to deal with these kind of special
> mappings with read
On 08/10/2018 01:36 AM, Yang Shi wrote:
> Unmapping vmas, which have VM_HUGETLB | VM_PFNMAP flag set or
> have uprobes set, need get done with write mmap_sem held since
> they may update vm_flags.
>
> So, it might be not safe enough to deal with these kind of special
> mappings with read
Add Reset Management Unit (RMU) support for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/actions/owl-s900.c | 82 ++
1 file changed, 82 insertions(+)
diff --git a/drivers/clk/actions/owl-s900.c b/drivers/clk/actions/owl-s900.c
Add Reset Management Unit (RMU) support for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/actions/owl-s900.c | 82 ++
1 file changed, 82 insertions(+)
diff --git a/drivers/clk/actions/owl-s900.c b/drivers/clk/actions/owl-s900.c
Add Reset Management Unit (RMU) support for Actions Semi S700 SoC.
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/actions/owl-s700.c | 51 ++
1 file changed, 51 insertions(+)
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
Add Reset Management Unit (RMU) support for Actions Semi S700 SoC.
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/actions/owl-s700.c | 51 ++
1 file changed, 51 insertions(+)
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
601 - 700 of 854 matches
Mail list logo
