The patch
regulator: as3711: convert to SPDX identifiers
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
regulator: as3711: convert to SPDX identifiers
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
regulator: bd9571mwv: convert to SPDX identifiers
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: bd9571mwv: convert to SPDX identifiers
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: pcm3060: Add DT property for single-ended output
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: pcm3060: Add DT property for single-ended output
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
On 7/3/18 6:04 PM, Rafael Tinoco wrote:
BUG: https://bugs.linaro.org/show_bug.cgi?id=3731
During Linaro's Kernel Functional tests, we have observed the
following situation:
[ 52.651490] DEBUG_LOCKS_WARN_ON(sem->owner != ((struct task_struct *)1UL))
[ 52.651506] WARNING: CPU: 2 PID: 1457 at
On 7/3/18 6:04 PM, Rafael Tinoco wrote:
BUG: https://bugs.linaro.org/show_bug.cgi?id=3731
During Linaro's Kernel Functional tests, we have observed the
following situation:
[ 52.651490] DEBUG_LOCKS_WARN_ON(sem->owner != ((struct task_struct *)1UL))
[ 52.651506] WARNING: CPU: 2 PID: 1457 at
syzbot has found a reproducer for the following crash on:
HEAD commit:ccda4af0f4b9 Linux 4.20-rc2
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13b4e77b40
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link:
syzbot has found a reproducer for the following crash on:
HEAD commit:ccda4af0f4b9 Linux 4.20-rc2
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13b4e77b40
kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link:
On Tue, Nov 06, 2018 at 05:35:25PM +0530, Balakrishna Godavarthi wrote:
> wcn3990 requires a power pulse to turn ON/OFF along with
> regulators. Sometimes we are observing the power pulses are sent
> out with some time delay, due to queuing these commands. This is
> causing synchronization issues
On Tue, Nov 06, 2018 at 05:35:25PM +0530, Balakrishna Godavarthi wrote:
> wcn3990 requires a power pulse to turn ON/OFF along with
> regulators. Sometimes we are observing the power pulses are sent
> out with some time delay, due to queuing these commands. This is
> causing synchronization issues
On 2018년 11월 14일 08:36, Christophe JAILLET wrote:
> In case of error, we return 0.
> This is spurious and not consistent with the other functions of the driver.
> Commit e115a2bf1426 has modified more than what is said in the commit
> message. Reverse part of it znd return an error when needed, as
On 2018년 11월 14일 08:36, Christophe JAILLET wrote:
> In case of error, we return 0.
> This is spurious and not consistent with the other functions of the driver.
> Commit e115a2bf1426 has modified more than what is said in the commit
> message. Reverse part of it znd return an error when needed, as
On 11/14/18 12:32 AM, Andrew Morton wrote:
> On Wed, 14 Nov 2018 00:23:28 +0100 Vlastimil Babka wrote:
>
>> On 11/14/18 12:15 AM, Andrew Morton wrote:
>>> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>>>
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4364,6 +4353,15 @@
On 11/14/18 12:32 AM, Andrew Morton wrote:
> On Wed, 14 Nov 2018 00:23:28 +0100 Vlastimil Babka wrote:
>
>> On 11/14/18 12:15 AM, Andrew Morton wrote:
>>> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>>>
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4364,6 +4353,15 @@
diff --git a/Makefile b/Makefile
index 79b8f3a44f74..41fe3014b712 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 136
+SUBLEVEL = 137
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
diff --git a/Makefile b/Makefile
index 79b8f3a44f74..41fe3014b712 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 136
+SUBLEVEL = 137
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
I'm announcing the release of the 4.18.19 kernel.
All users of the 4.18 kernel series must upgrade.
The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.18.y
and can be browsed at the normal kernel.org git web
On 2018년 11월 14일 00:38, Marek Szyprowski wrote:
> MAX8997 driver disables automatic path selection from MicroUSB connector
> and manually sets path to either UART or USB lines. However the code for
> setting USB path worked only for USB host mode (when ID pin is set
> to ground). When standard USB
I'm announcing the release of the 4.9.137 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.18.19 kernel.
All users of the 4.18 kernel series must upgrade.
The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.18.y
and can be browsed at the normal kernel.org git web
On 2018년 11월 14일 00:38, Marek Szyprowski wrote:
> MAX8997 driver disables automatic path selection from MicroUSB connector
> and manually sets path to either UART or USB lines. However the code for
> setting USB path worked only for USB host mode (when ID pin is set
> to ground). When standard USB
I'm announcing the release of the 4.9.137 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.14.81 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
I'm announcing the release of the 4.14.81 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
I'm announcing the release of the 4.19.2 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.19.2 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
> On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
>
> > On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> > >
> > > You could remove the old arch_gettimeoffset API without dropping any
> > > platforms.
> > >
> > > If
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
> On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
>
> > On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> > >
> > > You could remove the old arch_gettimeoffset API without dropping any
> > > platforms.
> > >
> > > If
In case of error, we return 0.
This is spurious and not consistent with the other functions of the driver.
Commit e115a2bf1426 has modified more than what is said in the commit
message. Reverse part of it znd return an error when needed, as it was
previously.
Fixes: e115a2bf1426 ("rtc: max77686:
In case of error, we return 0.
This is spurious and not consistent with the other functions of the driver.
Commit e115a2bf1426 has modified more than what is said in the commit
message. Reverse part of it znd return an error when needed, as it was
previously.
Fixes: e115a2bf1426 ("rtc: max77686:
On Wed, 14 Nov 2018 00:23:28 +0100 Vlastimil Babka wrote:
> On 11/14/18 12:15 AM, Andrew Morton wrote:
> > On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
> >
> >> --- a/mm/page_alloc.c
> >> +++ b/mm/page_alloc.c
> >> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask,
On Wed, 14 Nov 2018 00:23:28 +0100 Vlastimil Babka wrote:
> On 11/14/18 12:15 AM, Andrew Morton wrote:
> > On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
> >
> >> --- a/mm/page_alloc.c
> >> +++ b/mm/page_alloc.c
> >> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask,
On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
> From: Michal Hocko
> Date: Fri, 9 Nov 2018 09:35:29 +0100
> Subject: [PATCH] mm, page_alloc: check for max order in hot path
>
> Konstantin has noticed that kvmalloc might trigger the following warning
> [Thu Nov 1 08:43:56 2018]
On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
> From: Michal Hocko
> Date: Fri, 9 Nov 2018 09:35:29 +0100
> Subject: [PATCH] mm, page_alloc: check for max order in hot path
>
> Konstantin has noticed that kvmalloc might trigger the following warning
> [Thu Nov 1 08:43:56 2018]
On 11/14/18 12:15 AM, Andrew Morton wrote:
> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int
>> order, int preferred_nid,
>> gfp_t alloc_mask; /* The
On 11/14/18 12:15 AM, Andrew Morton wrote:
> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4364,6 +4353,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int
>> order, int preferred_nid,
>> gfp_t alloc_mask; /* The
Use d_instantiate() rather than d_add() and don't d_drop() in
afs_vnode_new_inode(). The dentry shouldn't be removed as it's not
changing its name.
Reported-by: Al Viro
Signed-off-by: David Howells
---
fs/afs/dir.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
When afs_validate() is called to validate a vnode (inode), there are two
unhandled cases in the fastpath at the top of the function:
(1) If the vnode is promised (AFS_VNODE_CB_PROMISED is set), the break
counters match and the data has expired, then there's an implicit case
in which
Use d_instantiate() rather than d_add() and don't d_drop() in
afs_vnode_new_inode(). The dentry shouldn't be removed as it's not
changing its name.
Reported-by: Al Viro
Signed-off-by: David Howells
---
fs/afs/dir.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
When afs_validate() is called to validate a vnode (inode), there are two
unhandled cases in the fastpath at the top of the function:
(1) If the vnode is promised (AFS_VNODE_CB_PROMISED is set), the break
counters match and the data has expired, then there's an implicit case
in which
kAFS can be given certain network errors (EADDRNOTAVAIL, EHOSTDOWN and
ERFKILL) that it doesn't handle in its server/address rotation algorithms.
They cause the probing and rotation to abort immediately rather than
rotating.
Fix this by:
(1) Abstracting out the error prioritisation from the VL
kAFS can be given certain network errors (EADDRNOTAVAIL, EHOSTDOWN and
ERFKILL) that it doesn't handle in its server/address rotation algorithms.
They cause the probing and rotation to abort immediately rather than
rotating.
Fix this by:
(1) Abstracting out the error prioritisation from the VL
Hi Al,
Here's a set of fixes for AFS if you could pass them on to Linus:
(1) Fix the interaction between vnode (inode) state validation and
callback-break. There are some unhandled cases that lead to kafs
transmitting a FetchStatus request on every validate call after the
Hi Al,
Here's a set of fixes for AFS if you could pass them on to Linus:
(1) Fix the interaction between vnode (inode) state validation and
callback-break. There are some unhandled cases that lead to kafs
transmitting a FetchStatus request on every validate call after the
On Thu, Nov 08, 2018 at 09:32:18AM -0800, Dan Williams wrote:
> On Thu, Nov 8, 2018 at 8:32 AM Mark Brown wrote:
> > I'm not 100% sure that people will pick up that the topic is about a
> > handbook for working with maintainers rather than a handbook for being a
> > maintainer from that title...
On Thu, Nov 08, 2018 at 09:32:18AM -0800, Dan Williams wrote:
> On Thu, Nov 8, 2018 at 8:32 AM Mark Brown wrote:
> > I'm not 100% sure that people will pick up that the topic is about a
> > handbook for working with maintainers rather than a handbook for being a
> > maintainer from that title...
On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
> Konstantin has noticed that kvmalloc might trigger the following warning
> [Thu Nov 1 08:43:56 2018] WARNING: CPU: 0 PID: 6676 at mm/vmstat.c:986
> __fragmentation_index+0x54/0x60
> [...]
> [Thu Nov 1 08:43:56 2018] Call Trace:
> [Thu
On Mon, Nov 12, 2018 at 1:02 PM Masahiro Yamada
wrote:
>
> Make is lenient enough to ignore missing rules as long as they are marked
> as PHONY. Remove dummy targets.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
>
> Makefile | 3 ---
> 1 file changed, 3 deletions(-)
>
>
On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko wrote:
> Konstantin has noticed that kvmalloc might trigger the following warning
> [Thu Nov 1 08:43:56 2018] WARNING: CPU: 0 PID: 6676 at mm/vmstat.c:986
> __fragmentation_index+0x54/0x60
> [...]
> [Thu Nov 1 08:43:56 2018] Call Trace:
> [Thu
On Mon, Nov 12, 2018 at 1:02 PM Masahiro Yamada
wrote:
>
> Make is lenient enough to ignore missing rules as long as they are marked
> as PHONY. Remove dummy targets.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
>
> Makefile | 3 ---
> 1 file changed, 3 deletions(-)
>
>
On Mon, Nov 12, 2018 at 10:09 AM, Oleg Nesterov wrote:
> get_arg_page() checks bprm->rlim_stack.rlim_cur and re-calculates the
> "extra" size for argv/envp pointers every time, this is a bit ugly and
> even not strictly correct: acct_arg_size() must not account this size.
>
> Remove all the
On Mon, Nov 12, 2018 at 10:09 AM, Oleg Nesterov wrote:
> get_arg_page() checks bprm->rlim_stack.rlim_cur and re-calculates the
> "extra" size for argv/envp pointers every time, this is a bit ugly and
> even not strictly correct: acct_arg_size() must not account this size.
>
> Remove all the
The patch
ASoC: qcom: Set dai_link id to each dai_link
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
The patch
ASoC: qcom: Set dai_link id to each dai_link
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to
On Tue 2018-11-13 14:23:17, Steven Rostedt wrote:
> On Tue, 13 Nov 2018 13:58:18 -0500
> Qian Cai wrote:
>
> > > Care to print the len and name parameters before this line?
> > len = 60612; name =
>
> How big are pages on arm64? Because we shouldn't get to this path if
> the string is bigger
On Tue 2018-11-13 14:23:17, Steven Rostedt wrote:
> On Tue, 13 Nov 2018 13:58:18 -0500
> Qian Cai wrote:
>
> > > Care to print the len and name parameters before this line?
> > len = 60612; name =
>
> How big are pages on arm64? Because we shouldn't get to this path if
> the string is bigger
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 110
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 110
On Mon, Nov 12, 2018 at 5:39 PM Anders Roxell wrote:
>
> In today's merge_config.sh the order of the config fragment files dictates
> the output of a config option. With this approach we will get different
> .config files depending on the order of the config fragment files.
>
> So doing something
On Mon, Nov 12, 2018 at 5:39 PM Anders Roxell wrote:
>
> In today's merge_config.sh the order of the config fragment files dictates
> the output of a config option. With this approach we will get different
> .config files depending on the order of the config fragment files.
>
> So doing something
On Thu, Nov 08, 2018 at 01:49:33PM +0100, Clément Péron wrote:
This looks mostly good, a few small things below but nothing too major:
> --- /dev/null
> +++ b/sound/soc/codecs/ak4118.c
> @@ -0,0 +1,449 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ak4118.c -- Asahi Kasei ALSA Soc Audio
On Thu, Nov 08, 2018 at 01:49:33PM +0100, Clément Péron wrote:
This looks mostly good, a few small things below but nothing too major:
> --- /dev/null
> +++ b/sound/soc/codecs/ak4118.c
> @@ -0,0 +1,449 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ak4118.c -- Asahi Kasei ALSA Soc Audio
On Thu, Nov 08, 2018 at 10:37:45AM +0200, Peter Ujfalusi wrote:
> Hi,
>
> This RFC series is on top of the omap-mcbsp cleanup series:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2018-November/141604.html
This is all fine by me.
signature.asc
Description: PGP signature
On Thu, Nov 08, 2018 at 10:37:45AM +0200, Peter Ujfalusi wrote:
> Hi,
>
> This RFC series is on top of the omap-mcbsp cleanup series:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2018-November/141604.html
This is all fine by me.
signature.asc
Description: PGP signature
On 10/25/18 10:55 AM, Florian Fainelli wrote:
> Hi all,
>
> I just painfully learned that perf would segfault when
> CONFIG_KUSER_HELPERS is disabled because it unconditionally makes use of
> it. This patch series adds an ARM test for that by leveraging the
> existing find_vdso_map() function and
On 10/25/18 10:55 AM, Florian Fainelli wrote:
> Hi all,
>
> I just painfully learned that perf would segfault when
> CONFIG_KUSER_HELPERS is disabled because it unconditionally makes use of
> it. This patch series adds an ARM test for that by leveraging the
> existing find_vdso_map() function and
Hi,
This mini patch series enables correct support for DMA in the presence of
memory outside the 32-bit address range with the Broadcom SiByte SOCs and
the relevant development boards.
There is a quirk in the BCM1250, BCM1125 and BCM1125H SOCs in that their
onchip 32-bit PCI host bridge
The LittleSur board is marked for high memory support and therefore
clearly must provide a way to have enough memory installed for some to
be present outside the low 4GiB physical address range. With the memory
map of the BCM1250 SOC it has been built around it means over 1GiB of
actual DRAM,
The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit
Hi,
This mini patch series enables correct support for DMA in the presence of
memory outside the 32-bit address range with the Broadcom SiByte SOCs and
the relevant development boards.
There is a quirk in the BCM1250, BCM1125 and BCM1125H SOCs in that their
onchip 32-bit PCI host bridge
The LittleSur board is marked for high memory support and therefore
clearly must provide a way to have enough memory installed for some to
be present outside the low 4GiB physical address range. With the memory
map of the BCM1250 SOC it has been built around it means over 1GiB of
actual DRAM,
The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit
The Broadcom SiByte BCM1250, BCM1125H and BCM1125 SOCs have an onchip
32-bit PCI host bridge, and the two former SOCs also have an onchip HT
host bridge. The HT host bridge, where present, appears in the PCI
configuration space as if it was a device on the 32-bit PCI bus behind
the PCI host
The Broadcom SiByte BCM1250, BCM1125H and BCM1125 SOCs have an onchip
32-bit PCI host bridge, and the two former SOCs also have an onchip HT
host bridge. The HT host bridge, where present, appears in the PCI
configuration space as if it was a device on the 32-bit PCI bus behind
the PCI host
On Tue, Nov 13, 2018 at 08:48:43PM +0100, Emil Renner Berthing wrote:
> On Tue, 13 Nov 2018 at 19:35, Mark Brown wrote:
> > On Mon, Nov 12, 2018 at 03:27:36PM +0100, Emil Renner Berthing wrote:
> > > I know the discussions about the sifive devicetree compatible
> > > strings haven't come to a
On Tue, Nov 13, 2018 at 08:48:43PM +0100, Emil Renner Berthing wrote:
> On Tue, 13 Nov 2018 at 19:35, Mark Brown wrote:
> > On Mon, Nov 12, 2018 at 03:27:36PM +0100, Emil Renner Berthing wrote:
> > > I know the discussions about the sifive devicetree compatible
> > > strings haven't come to a
> Wait, what? Can you name specific ones? Nowadays, enabling KSM for
> untrusted VMs seems like a terrible idea to me, security-wise.
Of course it is not used to share data among different
customers/tenants, as far as I know it is used by Oracle Cloud to
merge the same pages in clear containers.
> Wait, what? Can you name specific ones? Nowadays, enabling KSM for
> untrusted VMs seems like a terrible idea to me, security-wise.
Of course it is not used to share data among different
customers/tenants, as far as I know it is used by Oracle Cloud to
merge the same pages in clear containers.
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
I ran the vtpm proxy test suite on this series and got this error when
running it with 'make
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
I ran the vtpm proxy test suite on this series and got this error when
running it with 'make
On Tue, 13 Nov 2018, Thomas Gleixner wrote:
> On Wed, 14 Nov 2018, Finn Thain wrote:
> >
> > What I mean by that is, the interrupt level (IPL) prevents interrupt
> > handlers from being re-entered. But a handler can still get
> > interrupted by a higher priority interrupt request. In the past
On Tue, 13 Nov 2018, Thomas Gleixner wrote:
> On Wed, 14 Nov 2018, Finn Thain wrote:
> >
> > What I mean by that is, the interrupt level (IPL) prevents interrupt
> > handlers from being re-entered. But a handler can still get
> > interrupted by a higher priority interrupt request. In the past
Include linux/hw_random.h header file to silence the following
Wmissing-prototypes gcc warning:
drivers/char/random.c:2346:6: warning: no previous prototype for
‘add_hwgenerator_randomness’ [-Wmissing-prototypes]
Signed-off-by: Paolo Cretaro
---
drivers/char/random.c | 1 +
1 file changed, 1
Include linux/hw_random.h header file to silence the following
Wmissing-prototypes gcc warning:
drivers/char/random.c:2346:6: warning: no previous prototype for
‘add_hwgenerator_randomness’ [-Wmissing-prototypes]
Signed-off-by: Paolo Cretaro
---
drivers/char/random.c | 1 +
1 file changed, 1
Hello,
Paul Burton wrote:
> Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is
> configured for a pre-MIPS32r1 CPU, rather than defining its equivalent
> in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.
>
> The latter only works if a platform has an
Hello,
Maksym Kokhan wrote:
> CONFIG_BUILTIN_DTB and CONFIG_LIBFDT selection is duplicated
> in menu "Machine selection" under MIPS_MALTA.
>
> Signed-off-by: Maksym Kokhan
> Signed-off-by: Andrii Bordunov
Series applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if
Hello,
Paul Burton wrote:
> Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is
> configured for a pre-MIPS32r1 CPU, rather than defining its equivalent
> in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.
>
> The latter only works if a platform has an
Hello,
Maksym Kokhan wrote:
> CONFIG_BUILTIN_DTB and CONFIG_LIBFDT selection is duplicated
> in menu "Machine selection" under MIPS_MALTA.
>
> Signed-off-by: Maksym Kokhan
> Signed-off-by: Andrii Bordunov
Series applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if
Hello,
Aaro Koskinen wrote:
> Re-enable OCTEON USB driver which is needed on older hardware
> (e.g. EdgeRouter Lite) for mass storage etc. This got accidentally
> deleted when config options were changed for OCTEON2/3 USB.
>
> Fixes: f922bc0ad08b ("MIPS: Octeon: cavium_octeon_defconfig: Enable
Hello,
Aaro Koskinen wrote:
> Re-enable OCTEON USB driver which is needed on older hardware
> (e.g. EdgeRouter Lite) for mass storage etc. This got accidentally
> deleted when config options were changed for OCTEON2/3 USB.
>
> Fixes: f922bc0ad08b ("MIPS: Octeon: cavium_octeon_defconfig: Enable
On Tue, 13 Nov 2018, Michael Schmitz wrote:
>
> Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
> hardware emulation is a little more complete.
>
You mean, 40 us resolution, right?
> Using that for initial tests, I can confirm that timer resolution is
> reduced to
On Tue, 13 Nov 2018 16:16:29 +0100 "Uladzislau Rezki (Sony)"
wrote:
> This adds a new kernel module for analysis of vmalloc allocator. It is
> only enabled as a module. There are two main reasons this module should
> be used for. Those are performance evaluation and stressing of vmalloc
>
On Wed, 14 Nov 2018, Finn Thain wrote:
> On Tue, 13 Nov 2018, I wrote:
>
> > On Mon, 12 Nov 2018, Thomas Gleixner wrote:
> >
> > > > +static u32 clk_total;
> > > > +
> > > > +#define PCC_TIMER_CLOCK_FREQ 100
> > > > +#define PCC_TIMER_CYCLES (PCC_TIMER_CLOCK_FREQ / HZ)
> > > > +
> > > >
On Tue, 13 Nov 2018, Michael Schmitz wrote:
>
> Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
> hardware emulation is a little more complete.
>
You mean, 40 us resolution, right?
> Using that for initial tests, I can confirm that timer resolution is
> reduced to
On Tue, 13 Nov 2018 16:16:29 +0100 "Uladzislau Rezki (Sony)"
wrote:
> This adds a new kernel module for analysis of vmalloc allocator. It is
> only enabled as a module. There are two main reasons this module should
> be used for. Those are performance evaluation and stressing of vmalloc
>
On Wed, 14 Nov 2018, Finn Thain wrote:
> On Tue, 13 Nov 2018, I wrote:
>
> > On Mon, 12 Nov 2018, Thomas Gleixner wrote:
> >
> > > > +static u32 clk_total;
> > > > +
> > > > +#define PCC_TIMER_CLOCK_FREQ 100
> > > > +#define PCC_TIMER_CYCLES (PCC_TIMER_CLOCK_FREQ / HZ)
> > > > +
> > > >
On Tue, Nov 13, 2018 at 06:26:09PM +0100, Lubomir Rintel wrote:
> Hi,
>
> first of all -- thanks for such a careful review. It is very helpful.
>
> Wherever I don't respond to you, I'm just following what you wrote. It
> would perhaps be tiresome to respond to "Yes, will fix in next version"
>
On Tue, Nov 13, 2018 at 06:26:09PM +0100, Lubomir Rintel wrote:
> Hi,
>
> first of all -- thanks for such a careful review. It is very helpful.
>
> Wherever I don't respond to you, I'm just following what you wrote. It
> would perhaps be tiresome to respond to "Yes, will fix in next version"
>
201 - 300 of 1256 matches
Mail list logo
