Now that CONFIG_RETPOLINE hard depends on compiler support, there is no
reason for minimal stuff to still exist.
This change is based on suggestion in https://lkml.org/lkml/2018/9/18/1016
Signed-off-by: Zhenzhong Duan
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: David
From: Subbaraya Sundeep
As per the spec, bridges with EA capability work
with fixed secondary and subordinate bus numbers.
Hence assign bus numbers to bridges from EA if the
capability exists.
Signed-off-by: Subbaraya Sundeep
---
drivers/pci/probe.c | 58
According to Peter Zijlstra's suggestion in
https://lkml.org/lkml/2018/9/18/1016,
hard bind retpoline with compiler support and remove minimal stuff.
Tested with both CONFIG_RETPOLINE enabled and disabled.
-v2:
Add compiler support check in Kconfig [Masahiro]
Drop 3rd patch as
Now that CONFIG_RETPOLINE hard depends on compiler support, there is no
reason for minimal stuff to still exist.
This change is based on suggestion in https://lkml.org/lkml/2018/9/18/1016
Signed-off-by: Zhenzhong Duan
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: David
From: Subbaraya Sundeep
As per the spec, bridges with EA capability work
with fixed secondary and subordinate bus numbers.
Hence assign bus numbers to bridges from EA if the
capability exists.
Signed-off-by: Subbaraya Sundeep
---
drivers/pci/probe.c | 58
According to Peter Zijlstra's suggestion in
https://lkml.org/lkml/2018/9/18/1016,
hard bind retpoline with compiler support and remove minimal stuff.
Tested with both CONFIG_RETPOLINE enabled and disabled.
-v2:
Add compiler support check in Kconfig [Masahiro]
Drop 3rd patch as
Peter,
On Thu, Nov 01, 2018 at 09:11:52AM +0800, kbuild test robot wrote:
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5b7449810ae6d652629c550d3974c8453836d229
> commit:
Peter,
On Thu, Nov 01, 2018 at 09:11:52AM +0800, kbuild test robot wrote:
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5b7449810ae6d652629c550d3974c8453836d229
> commit:
On Thu 01-11-18 17:10:55, Baoquan He wrote:
> Hi,
>
> A hot removal failure was met on one bare metal system with 8 nodes, and
> node1~7 are all hotpluggable and 'movable_node' is set. When try to check
> value of /sys/devices/system/node/node1/memory*/removable, found some of
> them are 0,
On Thu 01-11-18 17:10:55, Baoquan He wrote:
> Hi,
>
> A hot removal failure was met on one bare metal system with 8 nodes, and
> node1~7 are all hotpluggable and 'movable_node' is set. When try to check
> value of /sys/devices/system/node/node1/memory*/removable, found some of
> them are 0,
On 2018/11/1 16:56, Peter Zijlstra wrote:
On Thu, Nov 01, 2018 at 10:02:14AM +0800, Zhenzhong Duan wrote:
Hmm, what about the case where we have RETPOLINE runtime disabled? Then
the CALL_NOSPEC alternative patches in an indirect call again, and the
retpolines are gone.
Is RETPOLINE runtime
On 2018/11/1 16:56, Peter Zijlstra wrote:
On Thu, Nov 01, 2018 at 10:02:14AM +0800, Zhenzhong Duan wrote:
Hmm, what about the case where we have RETPOLINE runtime disabled? Then
the CALL_NOSPEC alternative patches in an indirect call again, and the
retpolines are gone.
Is RETPOLINE runtime
On Wed, Oct 31, 2018 at 09:14:58AM +0100, Daniel Wagner wrote:
> From: Daniel Wagner
>
> Sebastian writes:
>
> """
> We reproducibly observe cache line starvation on a Core2Duo E6850 (2
> cores), a i5-6400 SKL (4 cores) and on a NXP LS2044A ARM Cortex-A72 (4
> cores).
>
> The problem can be
On Wed, Oct 31, 2018 at 09:14:58AM +0100, Daniel Wagner wrote:
> From: Daniel Wagner
>
> Sebastian writes:
>
> """
> We reproducibly observe cache line starvation on a Core2Duo E6850 (2
> cores), a i5-6400 SKL (4 cores) and on a NXP LS2044A ARM Cortex-A72 (4
> cores).
>
> The problem can be
Allocations over PAGE_SIZE << MAX_ORDER could be served only by vmalloc.
Signed-off-by: Konstantin Khlebnikov
---
[Thu Nov 1 08:43:56 2018] [ cut here ]
[Thu Nov 1 08:43:56 2018] WARNING: CPU: 0 PID: 6676 at mm/vmstat.c:986
__fragmentation_index+0x54/0x60
[Thu Nov 1
Allocations over PAGE_SIZE << MAX_ORDER could be served only by vmalloc.
Signed-off-by: Konstantin Khlebnikov
---
[Thu Nov 1 08:43:56 2018] [ cut here ]
[Thu Nov 1 08:43:56 2018] WARNING: CPU: 0 PID: 6676 at mm/vmstat.c:986
__fragmentation_index+0x54/0x60
[Thu Nov 1
On Wed, 31 Oct 2018, Daniel Wagner wrote:
> Backporting all qspinlock related patches is very likely to introduce
> regressions on v4.4. Therefore, the recommended solution by Peter and
> Thomas is to drop back to ticket spinlocks for v4.4.
>
> Link
On Wed, 31 Oct 2018, Daniel Wagner wrote:
> Backporting all qspinlock related patches is very likely to introduce
> regressions on v4.4. Therefore, the recommended solution by Peter and
> Thomas is to drop back to ticket spinlocks for v4.4.
>
> Link
Hi Marc,
On 11/1/18 11:00 AM, Marc Zyngier wrote:
> On Thu, 01 Nov 2018 07:55:12 +,
> Peter Ujfalusi wrote:
>>
>> Lokesh,
>>
>> On 10/29/18 3:04 PM, Lokesh Vutla wrote:
> With the above information, linux should send a message to
> system-controller using TISCI protocol. After
Hi Marc,
On 11/1/18 11:00 AM, Marc Zyngier wrote:
> On Thu, 01 Nov 2018 07:55:12 +,
> Peter Ujfalusi wrote:
>>
>> Lokesh,
>>
>> On 10/29/18 3:04 PM, Lokesh Vutla wrote:
> With the above information, linux should send a message to
> system-controller using TISCI protocol. After
Am Donnerstag, 1. November 2018, 09:55:53 CET schrieb Rafał Miłecki:
> On Sun, 28 Oct 2018 at 22:44, Richard Weinberger wrote:
> > UBIFS's recovery code strictly assumes that a deleted inode will never
> > come back, therefore it removes all data which belongs to that inode
> > as soon it faces
Am Donnerstag, 1. November 2018, 09:55:53 CET schrieb Rafał Miłecki:
> On Sun, 28 Oct 2018 at 22:44, Richard Weinberger wrote:
> > UBIFS's recovery code strictly assumes that a deleted inode will never
> > come back, therefore it removes all data which belongs to that inode
> > as soon it faces
[apologies if you get this twice -- my GPU hung (!) whilst sending my
previous response]
On Wed, Oct 31, 2018 at 06:14:56PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 31, 2018 at 07:08:29PM +0100, Daniel Borkmann escreveu:
> > On 10/31/2018 06:44 PM, Will Deacon wrote:
> > > Diff
[apologies if you get this twice -- my GPU hung (!) whilst sending my
previous response]
On Wed, Oct 31, 2018 at 06:14:56PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 31, 2018 at 07:08:29PM +0100, Daniel Borkmann escreveu:
> > On 10/31/2018 06:44 PM, Will Deacon wrote:
> > > Diff
Hi,
A hot removal failure was met on one bare metal system with 8 nodes, and
node1~7 are all hotpluggable and 'movable_node' is set. When try to check
value of /sys/devices/system/node/node1/memory*/removable, found some of
them are 0, namely un-removable. And a back trace will always be seen.
Hi,
A hot removal failure was met on one bare metal system with 8 nodes, and
node1~7 are all hotpluggable and 'movable_node' is set. When try to check
value of /sys/devices/system/node/node1/memory*/removable, found some of
them are 0, namely un-removable. And a back trace will always be seen.
Hi Marc,
On 10/31/18 8:21 PM, Marc Zyngier wrote:
> Well, I'm convinced that we do not want a networking driver to be tied
> to an interrupt architecture, and that the two should be completely
> independent. But that's my own opinion. I can only see two solutions
> moving forward:
>
> 1) You
Hi Marc,
On 10/31/18 8:21 PM, Marc Zyngier wrote:
> Well, I'm convinced that we do not want a networking driver to be tied
> to an interrupt architecture, and that the two should be completely
> independent. But that's my own opinion. I can only see two solutions
> moving forward:
>
> 1) You
On Do, 2018-11-01 at 09:03 +0100, Maximilian Heyne wrote:
> On 10/31/18 10:24 AM, Shah, Amit wrote:
> >
> > On Di, 2018-10-30 at 21:57 +, Maximilian Heyne wrote:
> > >
> > > [...]
> > >
> > > diff --git a/fs/direct-io.c b/fs/direct-io.c
> > > index 093fb54cd316..199146036093 100644
> > >
On Do, 2018-11-01 at 09:03 +0100, Maximilian Heyne wrote:
> On 10/31/18 10:24 AM, Shah, Amit wrote:
> >
> > On Di, 2018-10-30 at 21:57 +, Maximilian Heyne wrote:
> > >
> > > [...]
> > >
> > > diff --git a/fs/direct-io.c b/fs/direct-io.c
> > > index 093fb54cd316..199146036093 100644
> > >
Commit-ID: 57f01796f14fecf00d330fe39c8d2477ced9cd79
Gitweb: https://git.kernel.org/tip/57f01796f14fecf00d330fe39c8d2477ced9cd79
Author: Michael Kelley
AuthorDate: Thu, 1 Nov 2018 00:35:05 +
Committer: Thomas Gleixner
CommitDate: Thu, 1 Nov 2018 10:00:38 +0100
irq/matrix: Fix
Commit-ID: 57f01796f14fecf00d330fe39c8d2477ced9cd79
Gitweb: https://git.kernel.org/tip/57f01796f14fecf00d330fe39c8d2477ced9cd79
Author: Michael Kelley
AuthorDate: Thu, 1 Nov 2018 00:35:05 +
Committer: Thomas Gleixner
CommitDate: Thu, 1 Nov 2018 10:00:38 +0100
irq/matrix: Fix
On Thu, 01 Nov 2018 07:55:12 +,
Peter Ujfalusi wrote:
>
> Lokesh,
>
> On 10/29/18 3:04 PM, Lokesh Vutla wrote:
> >>> With the above information, linux should send a message to
> >>> system-controller using TISCI protocol. After policing the given
> >>> information, system-controller does
On Thu, 01 Nov 2018 07:55:12 +,
Peter Ujfalusi wrote:
>
> Lokesh,
>
> On 10/29/18 3:04 PM, Lokesh Vutla wrote:
> >>> With the above information, linux should send a message to
> >>> system-controller using TISCI protocol. After policing the given
> >>> information, system-controller does
On Thu, Nov 01, 2018 at 11:20:21AM +0800, Yi Sun wrote:
> On 18-10-31 18:15:39, Peter Zijlstra wrote:
> > So Yi, are you actually seeing a problem? If so, can you give details?
>
> Where does the patch come from? I cannot find it through google.
What patch!? The one I posted:
On Thu, Nov 01, 2018 at 11:20:21AM +0800, Yi Sun wrote:
> On 18-10-31 18:15:39, Peter Zijlstra wrote:
> > So Yi, are you actually seeing a problem? If so, can you give details?
>
> Where does the patch come from? I cannot find it through google.
What patch!? The one I posted:
Commit-ID: bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6
Gitweb: https://git.kernel.org/tip/bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6
Author: Josh Poimboeuf
AuthorDate: Wed, 31 Oct 2018 21:57:30 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 1 Nov 2018 09:55:38 +0100
objtool: Support GCC
Commit-ID: bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6
Gitweb: https://git.kernel.org/tip/bcb6fb5da77c2a228adf07cc9cb1a0c2aa2001c6
Author: Josh Poimboeuf
AuthorDate: Wed, 31 Oct 2018 21:57:30 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 1 Nov 2018 09:55:38 +0100
objtool: Support GCC
On Thu, Nov 01, 2018 at 10:02:14AM +0800, Zhenzhong Duan wrote:
> > Hmm, what about the case where we have RETPOLINE runtime disabled? Then
> > the CALL_NOSPEC alternative patches in an indirect call again, and the
> > retpolines are gone.
>
> Is RETPOLINE runtime toggle supported in upstream? I
On Thu, Nov 01, 2018 at 10:02:14AM +0800, Zhenzhong Duan wrote:
> > Hmm, what about the case where we have RETPOLINE runtime disabled? Then
> > the CALL_NOSPEC alternative patches in an indirect call again, and the
> > retpolines are gone.
>
> Is RETPOLINE runtime toggle supported in upstream? I
On Sun, 28 Oct 2018 at 22:44, Richard Weinberger wrote:
> UBIFS's recovery code strictly assumes that a deleted inode will never
> come back, therefore it removes all data which belongs to that inode
> as soon it faces an inode with link count 0 in the replay list.
> Before O_TMPFILE this
On Sun, 28 Oct 2018 at 22:44, Richard Weinberger wrote:
> UBIFS's recovery code strictly assumes that a deleted inode will never
> come back, therefore it removes all data which belongs to that inode
> as soon it faces an inode with link count 0 in the replay list.
> Before O_TMPFILE this
Hi Nathan,
thank you for your patch.
On 11/01/2018 02:52 AM, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another:
>
> drivers/pinctrl/pinctrl-lpc18xx.c:643:29: warning: implicit conversion
> from enumeration type 'enum lpc18xx_pin_config_param' to
Hi Nathan,
thank you for your patch.
On 11/01/2018 02:52 AM, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another:
>
> drivers/pinctrl/pinctrl-lpc18xx.c:643:29: warning: implicit conversion
> from enumeration type 'enum lpc18xx_pin_config_param' to
Long,
On Thu, 1 Nov 2018, Long Li wrote:
> On a large system with multiple devices of the same class (e.g. NVMe disks,
> using managed IRQs), the kernel tends to concentrate their IRQs on several
> CPUs.
>
> The issue is that when NVMe calls irq_matrix_alloc_managed(), the assigned
> CPU tends
Long,
On Thu, 1 Nov 2018, Long Li wrote:
> On a large system with multiple devices of the same class (e.g. NVMe disks,
> using managed IRQs), the kernel tends to concentrate their IRQs on several
> CPUs.
>
> The issue is that when NVMe calls irq_matrix_alloc_managed(), the assigned
> CPU tends
On Thu, Nov 01, 2018 at 02:52:29AM +0100, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> As UARTB and VFIR share their clock enable bit it is rather unwise for
> the kernel to turn off the VFIR one should that be unused (and
> potentially vice versa but so far there anyway is no VFIR
On Thu, Nov 01, 2018 at 02:52:29AM +0100, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> As UARTB and VFIR share their clock enable bit it is rather unwise for
> the kernel to turn off the VFIR one should that be unused (and
> potentially vice versa but so far there anyway is no VFIR
On Thu, 1 Nov 2018 at 14:36, Chunyan Zhang wrote:
>
> Hi Arnd,
>
> I guess you may have missed this pull request.
>
> Thanks,
> Chunyan
> On Thu, 18 Oct 2018 at 17:19, Chunyan Zhang wrote:
> >
> > Hi Arnd,
> >
> > For 4.20-rc1 there's one patch only for sprd devicetree, please pull from
> > my
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 problems[1] -- since return values are only
available with
This is effectively a reversion of commit 76094a2cf46e ("ftrace:
distinguish kretprobe'd functions in trace logs"), as the checking of
kretprobe_trampoline *for tracing* is no longer necessary with the new
kretprobe stack trace changes.
Signed-off-by: Aleksa Sarai
---
On Thu, 1 Nov 2018 at 14:36, Chunyan Zhang wrote:
>
> Hi Arnd,
>
> I guess you may have missed this pull request.
>
> Thanks,
> Chunyan
> On Thu, 18 Oct 2018 at 17:19, Chunyan Zhang wrote:
> >
> > Hi Arnd,
> >
> > For 4.20-rc1 there's one patch only for sprd devicetree, please pull from
> > my
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 problems[1] -- since return values are only
available with
This is effectively a reversion of commit 76094a2cf46e ("ftrace:
distinguish kretprobe'd functions in trace logs"), as the checking of
kretprobe_trampoline *for tracing* is no longer necessary with the new
kretprobe stack trace changes.
Signed-off-by: Aleksa Sarai
---
Good day,
My name is Annable Katherine Grosvenor, I'm 57yrs old, a widow, no kids, from
the United Kingdom, I'm very sorry to bother you with this message but it is
very important for me that I send out this message because I am very sick and
at the point of death, I'm diagnosed with Ovarian
Good day,
My name is Annable Katherine Grosvenor, I'm 57yrs old, a widow, no kids, from
the United Kingdom, I'm very sorry to bother you with this message but it is
very important for me that I send out this message because I am very sick and
at the point of death, I'm diagnosed with Ovarian
Am 01.11.18 um 01:46 schrieb Nathan Chancellor:
> Clang warns when one enumerated type is implicitly converted to another:
>
> drivers/pinctrl/bcm/pinctrl-bcm2835.c:707:40: warning: implicit
> conversion from enumeration type 'enum bcm2835_pinconf_param' to
> different enumeration type 'enum
Am 01.11.18 um 01:46 schrieb Nathan Chancellor:
> Clang warns when one enumerated type is implicitly converted to another:
>
> drivers/pinctrl/bcm/pinctrl-bcm2835.c:707:40: warning: implicit
> conversion from enumeration type 'enum bcm2835_pinconf_param' to
> different enumeration type 'enum
On Thu 2018-11-01 10:48:21, Sergey Senozhatsky wrote:
> On (10/31/18 13:27), Petr Mladek wrote:
> > >
> > > Signed-off-by: Sergey Senozhatsky
> >
> > The patch makes sense to me. The locks should stay busted also for
> > console_flush_on_panic().
> >
> > With the added #include :
> >
> >
On Thu 2018-11-01 10:48:21, Sergey Senozhatsky wrote:
> On (10/31/18 13:27), Petr Mladek wrote:
> > >
> > > Signed-off-by: Sergey Senozhatsky
> >
> > The patch makes sense to me. The locks should stay busted also for
> > console_flush_on_panic().
> >
> > With the added #include :
> >
> >
On Wed, 31 Oct 2018, Dan O'Donovan wrote:
> UP Squared (UP2) is a x86 SBC from AAEON based on Intel Apollo Lake. It
> features a MAX 10 FPGA that routes lines from both SoC and on-board
> devices to two I/O headers:
>
> ++
>
On Wed, 31 Oct 2018, Dan O'Donovan wrote:
> UP Squared (UP2) is a x86 SBC from AAEON based on Intel Apollo Lake. It
> features a MAX 10 FPGA that routes lines from both SoC and on-board
> devices to two I/O headers:
>
> ++
>
On Tue, 30 Oct 2018 14:19:53 +1100
Aleksa Sarai wrote:
> 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
On Tue, 30 Oct 2018 14:19:53 +1100
Aleksa Sarai wrote:
> 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
On 10/31/18 10:24 AM, Shah, Amit wrote:
On Di, 2018-10-30 at 21:57 +, Maximilian Heyne wrote:
[...]
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 093fb54cd316..199146036093 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -325,8 +325,8 @@ static ssize_t dio_complete(struct dio
On 10/31/18 10:24 AM, Shah, Amit wrote:
On Di, 2018-10-30 at 21:57 +, Maximilian Heyne wrote:
[...]
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 093fb54cd316..199146036093 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -325,8 +325,8 @@ static ssize_t dio_complete(struct dio
On 11/01/2018 09:09 AM, Randy Dunlap wrote:
On 10/31/18 5:48 PM, kbuild test robot wrote:
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit:
On 11/01/2018 09:09 AM, Randy Dunlap wrote:
On 10/31/18 5:48 PM, kbuild test robot wrote:
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit:
Lokesh,
On 10/29/18 3:04 PM, Lokesh Vutla wrote:
>>> With the above information, linux should send a message to
>>> system-controller using TISCI protocol. After policing the given
>>> information, system-controller does the following:
>>> - Attaches the interrupt(INTA input) to the device
Lokesh,
On 10/29/18 3:04 PM, Lokesh Vutla wrote:
>>> With the above information, linux should send a message to
>>> system-controller using TISCI protocol. After policing the given
>>> information, system-controller does the following:
>>> - Attaches the interrupt(INTA input) to the device
On Thu, 01 Nov 2018 08:37:47 +0100,
Takashi Iwai wrote:
>
> At the next submission, could you give a proper cover letter (PATCH
> 0/3) and submit together with other patches? git-format-patch will
> give you a nice template with --cover-letter option.
... and don't forget to put "v2" prefix, so
On Thu, 01 Nov 2018 08:37:47 +0100,
Takashi Iwai wrote:
>
> At the next submission, could you give a proper cover letter (PATCH
> 0/3) and submit together with other patches? git-format-patch will
> give you a nice template with --cover-letter option.
... and don't forget to put "v2" prefix, so
On Wed, 31 Oct 2018 21:08:18 +0100,
wrote:
>
> This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
> https://bugzilla.kernel.org/show_bug.cgi?id=200501
The information should be put in the patch description.
thanks,
Takashi
>
> On Wed, 2018-10-31 at 15:20 -0400, Ayman
On Wed, 31 Oct 2018 21:08:18 +0100,
wrote:
>
> This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
> https://bugzilla.kernel.org/show_bug.cgi?id=200501
The information should be put in the patch description.
thanks,
Takashi
>
> On Wed, 2018-10-31 at 15:20 -0400, Ayman
On Wed, 31 Oct 2018 20:20:38 +0100,
Ayman Bagabas wrote:
>
> Some of Huawei laptops come with a LED in the mic mute key. This patch
> enables and disable this LED when the internal microphone status is
> changed.
>
> Signed-off-by: Ayman Bagabas
> ---
> include/linux/huawei_wmi.h| 7
On Wed, 31 Oct 2018 20:20:38 +0100,
Ayman Bagabas wrote:
>
> Some of Huawei laptops come with a LED in the mic mute key. This patch
> enables and disable this LED when the internal microphone status is
> changed.
>
> Signed-off-by: Ayman Bagabas
> ---
> include/linux/huawei_wmi.h| 7
Good morning!
On 11/1/18 5:53 AM, Michael Schmitz wrote:
> my fix is evidently incomplete - I just crashed elgar trying to remove the
> pata_buddha module, sorry. Must've done something silly.
I'll reboot him in about 2-3 hours when I'm in the office.
Adrian
--
.''`. John Paul Adrian
Good morning!
On 11/1/18 5:53 AM, Michael Schmitz wrote:
> my fix is evidently incomplete - I just crashed elgar trying to remove the
> pata_buddha module, sorry. Must've done something silly.
I'll reboot him in about 2-3 hours when I'm in the office.
Adrian
--
.''`. John Paul Adrian
Hi Quentin,
On 29 October 2018 at 22:48, Quentin Schulz wrote:
> Hi all,
>
> Just chiming in, hopefully I got the message header fine as I don't have
> the original of the mail.
>
>>
>> We have introduced some battery properties to present the OCV table
>> temperatures and OCV capacity table
Hi Quentin,
On 29 October 2018 at 22:48, Quentin Schulz wrote:
> Hi all,
>
> Just chiming in, hopefully I got the message header fine as I don't have
> the original of the mail.
>
>>
>> We have introduced some battery properties to present the OCV table
>> temperatures and OCV capacity table
With Due Respect,
I know that this mail will come to you as a surprise as we have never met
before, but need not to worry as I am contacting you independently of my
investigation and no one is informed of this communication. I need your urgent
assistance in transferring the sum of $10.5million
With Due Respect,
I know that this mail will come to you as a surprise as we have never met
before, but need not to worry as I am contacting you independently of my
investigation and no one is informed of this communication. I need your urgent
assistance in transferring the sum of $10.5million
_FP_ROUND_ZERO is defined as 0 and used as a statemente in macro
_FP_ROUND. This generates "error: statement with no effect
[-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to
fix it.
This modification is quoted from glibc 'commit
(8ed1e7d5894000c155acbd06f)'
Signed-off-by:
Patch series adding managed clkdev and of_provider registrations
Few clk drivers appear to be leaking clkdev lookup registrations at
driver remove. The patch series adds devm versions of lookup
registrations and cleans up few drivers. Driver clean-up patches have
not been tested as I lack the HW.
This patch set contains basic components for supporting the nds32 FPU,
such as exception handlers and context switch for FPU registers. By
default, the lazy FPU scheme is supported and the user can configure it via
CONFIG_LZAY_FPU.
Signed-off-by: Vincent Chen
---
arch/nds32/Kconfig
_FP_ROUND_ZERO is defined as 0 and used as a statemente in macro
_FP_ROUND. This generates "error: statement with no effect
[-Werror=unused-value]" from gcc. Defining _FP_ROUND_ZERO as (void)0 to
fix it.
This modification is quoted from glibc 'commit
(8ed1e7d5894000c155acbd06f)'
Signed-off-by:
Patch series adding managed clkdev and of_provider registrations
Few clk drivers appear to be leaking clkdev lookup registrations at
driver remove. The patch series adds devm versions of lookup
registrations and cleans up few drivers. Driver clean-up patches have
not been tested as I lack the HW.
This patch set contains basic components for supporting the nds32 FPU,
such as exception handlers and context switch for FPU registers. By
default, the lazy FPU scheme is supported and the user can configure it via
CONFIG_LZAY_FPU.
Signed-off-by: Vincent Chen
---
arch/nds32/Kconfig
This modification is quoted from glibc 'commit <
sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.c: Moved to>
(fe0b1e854ad32a69b260)'
Signed-off-by: Vincent Chen
---
include/math-emu/op-2.h | 97 ++
1 files changed, 46 insertions(+), 51
This modification is quoted from glibc 'commit <
sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.c: Moved to>
(fe0b1e854ad32a69b260)'
Signed-off-by: Vincent Chen
---
include/math-emu/op-2.h | 97 ++
1 files changed, 46 insertions(+), 51
Currently, the nds32 FPU dose not support the arithmetic of denormalized
number. When the nds32 FPU finds the result of the instruction is a
denormlized number, the nds32 FPU considers it to be an underflow condition
and rounds the result to an appropriate number. It may causes some loss
of
Currently, the nds32 FPU dose not support the arithmetic of denormalized
number. When the nds32 FPU finds the result of the instruction is a
denormlized number, the nds32 FPU considers it to be an underflow condition
and rounds the result to an appropriate number. It may causes some loss
of
The Andes FPU coprocessor does not support denormalized number handling.
According to the specification, FPU generates a denorm input exception
that requires the kernel to deal with this instrution operation when it
encounters denormalized operands. Hence an nds32 FPU ISA emulator in the
kernel is
This patch set contains basic components for supporting the nds32 FPU,
such as exception handlers and context switch for FPU registers. By
default, the lazy FPU scheme is supported and the user can configure it
via CONFIG_LZAY_FPU. In addition, a floating point emulator is required
to handle all
The Andes FPU coprocessor does not support denormalized number handling.
According to the specification, FPU generates a denorm input exception
that requires the kernel to deal with this instrution operation when it
encounters denormalized operands. Hence an nds32 FPU ISA emulator in the
kernel is
This patch set contains basic components for supporting the nds32 FPU,
such as exception handlers and context switch for FPU registers. By
default, the lazy FPU scheme is supported and the user can configure it
via CONFIG_LZAY_FPU. In addition, a floating point emulator is required
to handle all
On 2018-11-01, Aleksa Sarai wrote:
> On 2018-10-29, Daniel Colascione wrote:
> > This patch adds a new file under /proc/pid, /proc/pid/exithand.
> > Attempting to read from an exithand file will block until the
> > corresponding process exits, at which point the read will successfully
> >
On 2018-11-01, Aleksa Sarai wrote:
> On 2018-10-29, Daniel Colascione wrote:
> > This patch adds a new file under /proc/pid, /proc/pid/exithand.
> > Attempting to read from an exithand file will block until the
> > corresponding process exits, at which point the read will successfully
> >
On 2018-10-29, Daniel Colascione wrote:
> This patch adds a new file under /proc/pid, /proc/pid/exithand.
> Attempting to read from an exithand file will block until the
> corresponding process exits, at which point the read will successfully
> complete with EOF. The file descriptor supports
On 2018-10-29, Daniel Colascione wrote:
> This patch adds a new file under /proc/pid, /proc/pid/exithand.
> Attempting to read from an exithand file will block until the
> corresponding process exits, at which point the read will successfully
> complete with EOF. The file descriptor supports
901 - 1000 of 1024 matches
Mail list logo
