On Mon, Oct 29, 2018 at 9:54 PM Daniel Lezcano
wrote:
>
> The mutex protects a per_cpu variable access. The potential race can
> happen only when the cpufreq governor module is loaded and at the same
> time the cpu capacity is changed in the sysfs.
>
> There is no real interest of using a mutex
On Mon, Oct 29, 2018 at 9:54 PM Daniel Lezcano
wrote:
>
> The mutex protects a per_cpu variable access. The potential race can
> happen only when the cpufreq governor module is loaded and at the same
> time the cpu capacity is changed in the sysfs.
>
> There is no real interest of using a mutex
Hi,
On 2018/10/30 14:04, Gao Xiang wrote:
> It is better to use wrapped smp_cond_load_relaxed
> instead of open-coded busy waiting for bit_spinlock.
>
> Signed-off-by: Gao Xiang
> ---
>
> change log v2:
> - fix the incorrect expression !(VAL >> (bitnum & (BITS_PER_LONG-1)))
> - the test
Hi,
On 2018/10/30 14:04, Gao Xiang wrote:
> It is better to use wrapped smp_cond_load_relaxed
> instead of open-coded busy waiting for bit_spinlock.
>
> Signed-off-by: Gao Xiang
> ---
>
> change log v2:
> - fix the incorrect expression !(VAL >> (bitnum & (BITS_PER_LONG-1)))
> - the test
It is better to use wrapped smp_cond_load_relaxed
instead of open-coded busy waiting for bit_spinlock.
Signed-off-by: Gao Xiang
---
change log v2:
- fix the incorrect expression !(VAL >> (bitnum & (BITS_PER_LONG-1)))
- the test result is described in the following reply.
Thanks,
Gao Xiang
It is better to use wrapped smp_cond_load_relaxed
instead of open-coded busy waiting for bit_spinlock.
Signed-off-by: Gao Xiang
---
change log v2:
- fix the incorrect expression !(VAL >> (bitnum & (BITS_PER_LONG-1)))
- the test result is described in the following reply.
Thanks,
Gao Xiang
On Mon, Oct 29, 2018 at 9:56 PM Daniel Lezcano
wrote:
Would have been better if I was cc'd on all the patches since I was
looking at this
stuff actively this week :)
> The function 'register_cpufreq_notifier' registers the
> init_cpu_capacity_notifier() only if raw_capacity is not NULL.
>
>
On Mon, Oct 29, 2018 at 9:56 PM Daniel Lezcano
wrote:
Would have been better if I was cc'd on all the patches since I was
looking at this
stuff actively this week :)
> The function 'register_cpufreq_notifier' registers the
> init_cpu_capacity_notifier() only if raw_capacity is not NULL.
>
>
GPIOs 0 through 3 and 81 through 84 are configured to not be accessible
from the application CPUs. Mark them as reserved to allow the MSM8998
MTP to boot after the introduction of 3edfb7bd76bd ("gpiolib: Show
correct direction from the beginning").
Signed-off-by: Bjorn Andersson
---
GPIOs 0 through 3 and 81 through 84 are configured to not be accessible
from the application CPUs. Mark them as reserved to allow the MSM8998
MTP to boot after the introduction of 3edfb7bd76bd ("gpiolib: Show
correct direction from the beginning").
Signed-off-by: Bjorn Andersson
---
The stallwarn document incorrectly mentions 'fps=' instead of 'fqs='.
Correct that.
Signed-off-by: Joel Fernandes (Google)
---
Documentation/RCU/stallwarn.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
The stallwarn document incorrectly mentions 'fps=' instead of 'fqs='.
Correct that.
Signed-off-by: Joel Fernandes (Google)
---
Documentation/RCU/stallwarn.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
Hi all,
Please do not add any v4.21/v5.1 code to your linux-next included trees
until after the merge window closes.
Changes since 20181029:
My fixes tree contains this:
"drivers: net: include linux/ip.h for iphdr"
The compiler-attributes tree gained a conflict against the k
Hi all,
Please do not add any v4.21/v5.1 code to your linux-next included trees
until after the merge window closes.
Changes since 20181029:
My fixes tree contains this:
"drivers: net: include linux/ip.h for iphdr"
The compiler-attributes tree gained a conflict against the k
On 2018-10-29, Daniel Colascione wrote:
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works like kill(2),
On 2018-10-29, Daniel Colascione wrote:
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works like kill(2),
Michal Hocko wrote:
> @@ -3156,6 +3166,13 @@ void exit_mmap(struct mm_struct *mm)
> vma = remove_vma(vma);
> }
> vm_unacct_memory(nr_accounted);
> +
> + /*
> +* Now that the full address space is torn down, make sure the
> +* OOM killer skips
Michal Hocko wrote:
> @@ -3156,6 +3166,13 @@ void exit_mmap(struct mm_struct *mm)
> vma = remove_vma(vma);
> }
> vm_unacct_memory(nr_accounted);
> +
> + /*
> +* Now that the full address space is torn down, make sure the
> +* OOM killer skips
Instead of specifying target/source pairs, let's list patterns that we
want to handle as single targets. This slightly changes the behavior;
the top Makefile previously checked the presence of a source file,
now Kbuild will descend into a subdirectory anyway to find out what to
do there.
Instead of specifying target/source pairs, let's list patterns that we
want to handle as single targets. This slightly changes the behavior;
the top Makefile previously checked the presence of a source file,
now Kbuild will descend into a subdirectory anyway to find out what to
do there.
There is one more user of $(cc-name) in the top Makefile. It is supposed
to detect Clang before invoking Kconfig, so it should still be there
in the $(shell ...) form. All the other users of $(cc-name) have been
replaced with $(CONFIG_CC_IS_CLANG). Hence, scripts/Kbuild.include does
not need to
On Mon, Oct 29, 2018 at 06:37:53AM +, Peng15 Wang 王鹏 wrote:
>
>
> >From: Kees Cook
> >Sent: Monday, October 29, 2018 0:03
> >To: Peng15 Wang 王鹏
> >Cc: an...@enomsg.org; ccr...@android.com; tony.l...@intel.com;
> >linux-kernel@vger.kernel.org; Joel
There is one more user of $(cc-name) in the top Makefile. It is supposed
to detect Clang before invoking Kconfig, so it should still be there
in the $(shell ...) form. All the other users of $(cc-name) have been
replaced with $(CONFIG_CC_IS_CLANG). Hence, scripts/Kbuild.include does
not need to
On Mon, Oct 29, 2018 at 06:37:53AM +, Peng15 Wang 王鹏 wrote:
>
>
> >From: Kees Cook
> >Sent: Monday, October 29, 2018 0:03
> >To: Peng15 Wang 王鹏
> >Cc: an...@enomsg.org; ccr...@android.com; tony.l...@intel.com;
> >linux-kernel@vger.kernel.org; Joel
On Mon, Oct 29, 2018 at 07:27:35AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 29, 2018 at 11:24:42AM +, Ran Rozenstein wrote:
> > Hi Paul and all,
> >
> > > -Original Message-
> > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > > ow...@vger.kernel.org] On Behalf
On Mon, Oct 29, 2018 at 07:27:35AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 29, 2018 at 11:24:42AM +, Ran Rozenstein wrote:
> > Hi Paul and all,
> >
> > > -Original Message-
> > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > > ow...@vger.kernel.org] On Behalf
On Mon, Oct 29, 2018 at 3:11 PM Daniel Colascione wrote:
>
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works
On Mon, Oct 29, 2018 at 3:11 PM Daniel Colascione wrote:
>
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works
On 2018-10-30, Masami Hiramatsu wrote:
> > Historically, kretprobe has always produced unusable stack traces
> > (kretprobe_trampoline is the only entry in most cases, because of the
> > funky stack pointer overwriting). This has caused quite a few annoyances
> > when using tracing to debug
On 2018-10-30, Masami Hiramatsu wrote:
> > Historically, kretprobe has always produced unusable stack traces
> > (kretprobe_trampoline is the only entry in most cases, because of the
> > funky stack pointer overwriting). This has caused quite a few annoyances
> > when using tracing to debug
Hi Duncan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on soc-thermal/next]
[also build test ERROR on v4.19]
[cannot apply to next-20181029]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Duncan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on soc-thermal/next]
[also build test ERROR on v4.19]
[cannot apply to next-20181029]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Mon, 2018-10-29 at 21:49 +, Roman Gushchin wrote:
> On Mon, Oct 29, 2018 at 09:46:54PM +0100, Mike Galbraith wrote:
>
> > Ah, I have cgroup_disable=memory on the command line, which turns out
> > to be why your box doesn't explode, while mine does.
>
> Yeah, here it is. I'll send the fix
On Mon, 2018-10-29 at 21:49 +, Roman Gushchin wrote:
> On Mon, Oct 29, 2018 at 09:46:54PM +0100, Mike Galbraith wrote:
>
> > Ah, I have cgroup_disable=memory on the command line, which turns out
> > to be why your box doesn't explode, while mine does.
>
> Yeah, here it is. I'll send the fix
On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione wrote:
>
> Thanks for taking a look.
>
> On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes wrote:
> >
> > On Mon, Oct 29, 2018 at 10:53 AM Daniel Colascione
> > wrote:
> > >
> > > This patch adds a new file under /proc/pid, /proc/pid/exithand.
>
On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione wrote:
>
> Thanks for taking a look.
>
> On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes wrote:
> >
> > On Mon, Oct 29, 2018 at 10:53 AM Daniel Colascione
> > wrote:
> > >
> > > This patch adds a new file under /proc/pid, /proc/pid/exithand.
>
On 10/29/2018 08:18 PM, Will Deacon wrote:
> On Mon, Oct 29, 2018 at 06:15:42PM +0530, Anshuman Khandual wrote:
>> On 10/29/2018 06:02 PM, John Garry wrote:
>>> On 29/10/2018 12:16, Will Deacon wrote:
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> On 29/10/2018 11:25,
On Mon, Oct 29, 2018 at 12:29:22PM -0600, Alex Williamson wrote:
> On Mon, 29 Oct 2018 17:14:46 +0800
> Jason Wang wrote:
>
> > On 2018/10/29 上午10:42, Simon Guo wrote:
> > > Hi,
> > >
> > > I am using network device pass through mode with qemu x86(-device
> > > vfio-pci,host=:xx:yy.z)
> > >
On 10/29/2018 08:18 PM, Will Deacon wrote:
> On Mon, Oct 29, 2018 at 06:15:42PM +0530, Anshuman Khandual wrote:
>> On 10/29/2018 06:02 PM, John Garry wrote:
>>> On 29/10/2018 12:16, Will Deacon wrote:
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> On 29/10/2018 11:25,
On Mon, Oct 29, 2018 at 12:29:22PM -0600, Alex Williamson wrote:
> On Mon, 29 Oct 2018 17:14:46 +0800
> Jason Wang wrote:
>
> > On 2018/10/29 上午10:42, Simon Guo wrote:
> > > Hi,
> > >
> > > I am using network device pass through mode with qemu x86(-device
> > > vfio-pci,host=:xx:yy.z)
> > >
Hello,
I'm trying to use a GPIO as an interrupt on an mt7620 (using OpenWRT
drivers) and I can't seem to figure out how to glue my two-celled
interrupt description (including the trigger) to the device tree code.
This is the gpio driver I'm using:
Hello,
I'm trying to use a GPIO as an interrupt on an mt7620 (using OpenWRT
drivers) and I can't seem to figure out how to glue my two-celled
interrupt description (including the trigger) to the device tree code.
This is the gpio driver I'm using:
On 10/29/2018 08:14 PM, John Garry wrote:
>
> I think we should either factor out the sanity check
>> into a core helper or make the core code robust to these funny
>> configurations.
>
> OK, so to me it would make sense to factor out a sanity check into a core
>
On 10/29/2018 08:14 PM, John Garry wrote:
>
> I think we should either factor out the sanity check
>> into a core helper or make the core code robust to these funny
>> configurations.
>
> OK, so to me it would make sense to factor out a sanity check into a core
>
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
On Mon, Oct 29, 2018 at 6:01 PM Rik van Riel wrote:
>
> On Mon, 2018-10-29 at 17:50 -0700, Shakeel Butt wrote:
> > On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
> > >
> > > Mike Galbraith reported a regression caused by the commit
> > > 9b6f7e163cd0
> > > ("mm: rework memcg kernel stack
On Mon, Oct 29, 2018 at 6:01 PM Rik van Riel wrote:
>
> On Mon, 2018-10-29 at 17:50 -0700, Shakeel Butt wrote:
> > On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
> > >
> > > Mike Galbraith reported a regression caused by the commit
> > > 9b6f7e163cd0
> > > ("mm: rework memcg kernel stack
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
Remove duplicated include.
Signed-off-by: YueHaibing
---
arch/nds32/kernel/pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/nds32/kernel/pm.c b/arch/nds32/kernel/pm.c
index 6989560..ffa8040 100644
--- a/arch/nds32/kernel/pm.c
+++ b/arch/nds32/kernel/pm.c
@@ -5,7 +5,6 @@
#include
Remove duplicated include.
Signed-off-by: YueHaibing
---
arch/nds32/kernel/pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/nds32/kernel/pm.c b/arch/nds32/kernel/pm.c
index 6989560..ffa8040 100644
--- a/arch/nds32/kernel/pm.c
+++ b/arch/nds32/kernel/pm.c
@@ -5,7 +5,6 @@
#include
On Mon, Oct 29, 2018 at 11:31:00PM +, Serge E. Hallyn wrote:
> On Mon, Oct 29, 2018 at 04:40:31PM -0600, Tycho Andersen wrote:
> > + if (req->data.nr != __NR_mount) {
> > + fprintf(stderr, "huh? trapped something besides mknod? %d\n",
> > req->data.nr);
>
> 'besides mount' ?
On Mon, Oct 29, 2018 at 11:31:00PM +, Serge E. Hallyn wrote:
> On Mon, Oct 29, 2018 at 04:40:31PM -0600, Tycho Andersen wrote:
> > + if (req->data.nr != __NR_mount) {
> > + fprintf(stderr, "huh? trapped something besides mknod? %d\n",
> > req->data.nr);
>
> 'besides mount' ?
Hi Laurence,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-sof-driver/master]
[also build test ERROR on v4.19 next-20181029]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
Hi Laurence,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-sof-driver/master]
[also build test ERROR on v4.19 next-20181029]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On 10/29/2018 6:42 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
- struct annotation_options *annotation_options
__maybe_unused)
+ struct annotation_options *annotation_options __maybe_unused,
+
On 10/29/2018 6:42 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
- struct annotation_options *annotation_options
__maybe_unused)
+ struct annotation_options *annotation_options __maybe_unused,
+
From: Kan Liang
The main event processing thread may hang if the ring buffer event
processing timeouts.
Analysis from David Miller:
"It hangs the event thread, because the ui call waits for a keypress
but the display thread will eat them up and the event thread thus
hangs in select()."
The
From: Kan Liang
The main event processing thread may hang if the ring buffer event
processing timeouts.
Analysis from David Miller:
"It hangs the event thread, because the ui call waits for a keypress
but the display thread will eat them up and the event thread thus
hangs in select()."
The
Hi Peter,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 7aa54be2976550f17c11a1c3e3630002dea39303 locking/qspinlock, x86:
Provide liveness guarantee
date: 13 days
On 2018/10/30 1:59, Will Deacon wrote:
> On Sat, Oct 20, 2018 at 03:36:54PM +0800, Zhen Lei wrote:
>> The standard GITS_TRANSLATER register in ITS is only 4 bytes, but
>> Hisilicon expands the next 4 bytes to carry some IMPDEF information. That
>> means, total 8 bytes data will be written to
Hi Peter,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 7aa54be2976550f17c11a1c3e3630002dea39303 locking/qspinlock, x86:
Provide liveness guarantee
date: 13 days
On 2018/10/30 1:59, Will Deacon wrote:
> On Sat, Oct 20, 2018 at 03:36:54PM +0800, Zhen Lei wrote:
>> The standard GITS_TRANSLATER register in ITS is only 4 bytes, but
>> Hisilicon expands the next 4 bytes to carry some IMPDEF information. That
>> means, total 8 bytes data will be written to
Hi Akshu,
On Mon, Oct 29, 2018 at 1:39 AM Agrawal, Akshu wrote:
>
> During simultaneous running of playback and capture, we
> got hit by incorrect value write on common register. This was due
> to race condition between 2 streams.
> Fixing this by locking the common register access.
Nice
Hi Akshu,
On Mon, Oct 29, 2018 at 1:39 AM Agrawal, Akshu wrote:
>
> During simultaneous running of playback and capture, we
> got hit by incorrect value write on common register. This was due
> to race condition between 2 streams.
> Fixing this by locking the common register access.
Nice
On Mon, 2018-10-29 at 09:17 +0100, Michal Hocko wrote:
> On Mon 29-10-18 09:07:08, Michal Hocko wrote:
> [...]
> > Besides that, the following doesn't make much sense to me. It simply
> > makes no sense to use vmalloc for sub page allocation regardless of
> > HIGHMEM.
>
> OK, it is still early
On Mon, 2018-10-29 at 09:17 +0100, Michal Hocko wrote:
> On Mon 29-10-18 09:07:08, Michal Hocko wrote:
> [...]
> > Besides that, the following doesn't make much sense to me. It simply
> > makes no sense to use vmalloc for sub page allocation regardless of
> > HIGHMEM.
>
> OK, it is still early
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/compat_ioctl.c
between commit:
77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()")
from Linus' tree and commit:
69374d063be0 ("compat_ioctl: remove pointless HCI... ioctls")
from the vfs
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/compat_ioctl.c
between commit:
77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()")
from Linus' tree and commit:
69374d063be0 ("compat_ioctl: remove pointless HCI... ioctls")
from the vfs
Hi Rob,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree
dtb build rules
date: 4 weeks ago
Hi Rob,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree
dtb build rules
date: 4 weeks ago
make[1]: Entering directory '/usr/src/linux-4.19'
CC [M] /tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.o
/tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.c:816:22: error:
initialization of ‘u16 (*)(struct net_device *, struct sk_buff *,
struct net_device *, u16 (*)(struct net_device *,
make[1]: Entering directory '/usr/src/linux-4.19'
CC [M] /tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.o
/tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.c:816:22: error:
initialization of ‘u16 (*)(struct net_device *, struct sk_buff *,
struct net_device *, u16 (*)(struct net_device *,
Hi Aleksa,
On Sat, 27 Oct 2018 00:22:10 +1100
Aleksa Sarai wrote:
> Historically, kretprobe has always produced unusable stack traces
> (kretprobe_trampoline is the only entry in most cases, because of the
> funky stack pointer overwriting). This has caused quite a few annoyances
> when using
Hi Aleksa,
On Sat, 27 Oct 2018 00:22:10 +1100
Aleksa Sarai wrote:
> Historically, kretprobe has always produced unusable stack traces
> (kretprobe_trampoline is the only entry in most cases, because of the
> funky stack pointer overwriting). This has caused quite a few annoyances
> when using
From: Yuantian Tang
The QorIQ Layerscape SoC has several thermal sensors but the current
driver only supports one.
Massage the code to be sensor oriented and allow the support for
multiple sensors.
Signed-off-by: Yuantian Tang
Reviewed-by: Daniel Lezcano
---
v3:
- add Reviewed-by
v2:
-
From: Yuantian Tang
The QorIQ Layerscape SoC has several thermal sensors but the current
driver only supports one.
Massage the code to be sensor oriented and allow the support for
multiple sensors.
Signed-off-by: Yuantian Tang
Reviewed-by: Daniel Lezcano
---
v3:
- add Reviewed-by
v2:
-
On Mon, 2018-10-29 at 17:50 -0700, Shakeel Butt wrote:
> On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
> >
> > Mike Galbraith reported a regression caused by the commit
> > 9b6f7e163cd0
> > ("mm: rework memcg kernel stack accounting") on a system with
> > "cgroup_disable=memory" boot
On Mon, 2018-10-29 at 17:50 -0700, Shakeel Butt wrote:
> On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
> >
> > Mike Galbraith reported a regression caused by the commit
> > 9b6f7e163cd0
> > ("mm: rework memcg kernel stack accounting") on a system with
> > "cgroup_disable=memory" boot
On Mon, Oct 29, 2018 at 11:04:45PM +, Daniel Colascione wrote:
> On Mon, Oct 29, 2018 at 7:25 PM, Davidlohr Bueso wrote:
> > This patch introduces a new /proc/stat2 file that is identical to the
> > regular 'stat' except that it zeroes all hard irq statistics. The new
> > file is a drop in
On Mon, Oct 29, 2018 at 11:04:45PM +, Daniel Colascione wrote:
> On Mon, Oct 29, 2018 at 7:25 PM, Davidlohr Bueso wrote:
> > This patch introduces a new /proc/stat2 file that is identical to the
> > regular 'stat' except that it zeroes all hard irq statistics. The new
> > file is a drop in
On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
>
> Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0
> ("mm: rework memcg kernel stack accounting") on a system with
> "cgroup_disable=memory" boot option: the system panics with the
> following stack trace:
>
>
On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
>
> Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0
> ("mm: rework memcg kernel stack accounting") on a system with
> "cgroup_disable=memory" boot option: the system panics with the
> following stack trace:
>
>
Hi Arnd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 21924765862a0871908a35cb0e53e2e1c169b888 SUNRPC: use cmpxchg64() in
gss_seq_send64_fetch_and_inc()
date: 3
Hi Arnd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 21924765862a0871908a35cb0e53e2e1c169b888 SUNRPC: use cmpxchg64() in
gss_seq_send64_fetch_and_inc()
date: 3
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b42745211af552f170f38a1b97f4a112b5da6b2
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
Thank you!
On Sun, Oct 28, 2018 at 1:38 PM Masahiro Yamada
wrote:
>
> On Tue, Oct 23, 2018 at 10:11 AM Leonardo Brás wrote:
> >
> > Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> > macro, allowing usage of a variable name other than the struct element name.
> > Also,
Thank you!
On Sun, Oct 28, 2018 at 1:38 PM Masahiro Yamada
wrote:
>
> On Tue, Oct 23, 2018 at 10:11 AM Leonardo Brás wrote:
> >
> > Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> > macro, allowing usage of a variable name other than the struct element name.
> > Also,
Sorry, I will take care next time.
Thank you,
Leonardo Bras
On Sun, Oct 28, 2018 at 1:37 PM Masahiro Yamada
wrote:
>
> On Wed, Oct 24, 2018 at 1:04 PM Leonardo Bras wrote:
> >
> > Removes an unnecessary shadowed local variable (start).
> > It was used only once, with the same value it was
Sorry, I will take care next time.
Thank you,
Leonardo Bras
On Sun, Oct 28, 2018 at 1:37 PM Masahiro Yamada
wrote:
>
> On Wed, Oct 24, 2018 at 1:04 PM Leonardo Bras wrote:
> >
> > Removes an unnecessary shadowed local variable (start).
> > It was used only once, with the same value it was
+christ...@brauner.io
On Sun, Oct 28, 2018 at 7:29 PM chouryzhou(周威) wrote:
...
>
> > It's not obvious from this patch where this dependency comes
> > from...why is SYSVIPC required? I'd like to not have to require IPC_NS
> > either for devices.
>
> Yes, the patch is not highly dependent on
+christ...@brauner.io
On Sun, Oct 28, 2018 at 7:29 PM chouryzhou(周威) wrote:
...
>
> > It's not obvious from this patch where this dependency comes
> > from...why is SYSVIPC required? I'd like to not have to require IPC_NS
> > either for devices.
>
> Yes, the patch is not highly dependent on
Dear RT folks!
I'm pleased to announce the v4.19-rt1 patch set.
Changes since v4.18.16-rt9:
- rebase to v4.19
Known issues
- A warning triggered in "rcu_note_context_switch" originated from
SyS_timer_gettime(). The issue was always there, it is now
visible. Reported by
Dear RT folks!
I'm pleased to announce the v4.19-rt1 patch set.
Changes since v4.18.16-rt9:
- rebase to v4.19
Known issues
- A warning triggered in "rcu_note_context_switch" originated from
SyS_timer_gettime(). The issue was always there, it is now
visible. Reported by
On Mon, Oct 29, 2018 at 4:30 PM Bjorn Andersson
wrote:
>
> rpmsg updates for v4.20
Pulled (along with the remoteproc branch),
Linus
On Mon, Oct 29, 2018 at 4:30 PM Bjorn Andersson
wrote:
>
> rpmsg updates for v4.20
Pulled (along with the remoteproc branch),
Linus
On Mon, Oct 29, 2018 at 11:40:47PM +, Daniel Colascione wrote:
> On Mon, Oct 29, 2018 at 11:34 PM, Alexey Dobriyan wrote:
> >> I'd much rather move to a model in which userspace *explicitly* tells
> >> the kernel which fields it wants, with the kernel replying with just
> >> those particular
On Mon, Oct 29, 2018 at 11:40:47PM +, Daniel Colascione wrote:
> On Mon, Oct 29, 2018 at 11:34 PM, Alexey Dobriyan wrote:
> >> I'd much rather move to a model in which userspace *explicitly* tells
> >> the kernel which fields it wants, with the kernel replying with just
> >> those particular
1 - 100 of 1126 matches
Mail list logo
