On Sat, Oct 7, 2017 at 7:24 AM Thomas Meyer wrote:
> Bool initializations should use true and false. Bool tests don't need
> comparisons.
>
> Signed-off-by: Thomas Meyer
I totally missed this email (now over a year ago!)
However, since it's still correct and applies, I've taken it for -next
On Sat, Oct 7, 2017 at 7:24 AM Thomas Meyer wrote:
> Bool initializations should use true and false. Bool tests don't need
> comparisons.
>
> Signed-off-by: Thomas Meyer
I totally missed this email (now over a year ago!)
However, since it's still correct and applies, I've taken it for -next
Hi,
has anyone else had a chance to look at this yet?
There is a small conflict now due to
SUNRPC: Fix a bogus get/put in generic_key_to_expire()
Should I resend with that fixed up?
Thanks,
NeilBrown
On Wed, Nov 07 2018, NeilBrown wrote:
> This is an updated version of a series I
Hi Kamil,
On 2018년 11월 30일 00:51, Kamil Konieczny wrote:
> Add imem clock for exynos5433. This will enable to use crypto Security
s/clock/clocks
> SubSystem (in short SSS) and SlimSSS IP blocks.
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/clk/samsung/clk-exynos5433.c | 189
Hi,
has anyone else had a chance to look at this yet?
There is a small conflict now due to
SUNRPC: Fix a bogus get/put in generic_key_to_expire()
Should I resend with that fixed up?
Thanks,
NeilBrown
On Wed, Nov 07 2018, NeilBrown wrote:
> This is an updated version of a series I
Hi Kamil,
On 2018년 11월 30일 00:51, Kamil Konieczny wrote:
> Add imem clock for exynos5433. This will enable to use crypto Security
s/clock/clocks
> SubSystem (in short SSS) and SlimSSS IP blocks.
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/clk/samsung/clk-exynos5433.c | 189
From: Colin Ian King
Don't populate the const array read_ver_cmd on the stack but instead
make it static. Makes the object code smaller by 42 bytes:
Before:
textdata bss dec hex filename
172626928 192 243825f3e drivers/misc/ti-st/st_kim.o
After:
text
From: Colin Ian King
Don't populate the const array read_ver_cmd on the stack but instead
make it static. Makes the object code smaller by 42 bytes:
Before:
textdata bss dec hex filename
172626928 192 243825f3e drivers/misc/ti-st/st_kim.o
After:
text
Hi Linus,
Please pull this pstore fix for v4.20-rc5.
Thanks!
-Kees
The following changes since commit 1227daa43bce1318ff6fb54e6cd862b4f60245c7:
pstore/ram: Clarify resource reservation labels (2018-10-22 07:11:58 -0700)
are available in the Git repository at:
Hi Linus,
Please pull this pstore fix for v4.20-rc5.
Thanks!
-Kees
The following changes since commit 1227daa43bce1318ff6fb54e6cd862b4f60245c7:
pstore/ram: Clarify resource reservation labels (2018-10-22 07:11:58 -0700)
are available in the Git repository at:
From: Peng Wang
When initialing a prz, if invalid data is found (no PERSISTENT_RAM_SIG),
the function call path looks like this:
ramoops_init_prz ->
persistent_ram_new -> persistent_ram_post_init -> persistent_ram_zap
persistent_ram_zap
As we can see, persistent_ram_zap() is called
From: Peng Wang
When initialing a prz, if invalid data is found (no PERSISTENT_RAM_SIG),
the function call path looks like this:
ramoops_init_prz ->
persistent_ram_new -> persistent_ram_post_init -> persistent_ram_zap
persistent_ram_zap
As we can see, persistent_ram_zap() is called
The actual number of bytes stored in a PRZ is smaller than the
bytes requested by platform data, since there is a header on each
PRZ. Additionally, if ECC is enabled, there are trailing bytes used
as well. Normally this mismatch doesn't matter since PRZs are circular
buffers and the leading
The actual number of bytes stored in a PRZ is smaller than the
bytes requested by platform data, since there is a header on each
PRZ. Additionally, if ECC is enabled, there are trailing bytes used
as well. Normally this mismatch doesn't matter since PRZs are circular
buffers and the leading
The struct persistent_ram_zone wasn't well documented. This adds kern-doc
for it.
Signed-off-by: Kees Cook
---
fs/pstore/ram_core.c | 10 +
include/linux/pstore_ram.h | 46 +++---
2 files changed, 53 insertions(+), 3 deletions(-)
diff --git
With both ram.c and ram_core.c built into ramoops.ko, it doesn't make
sense to have differing pr_fmt prefixes. This fixes ram_core.c to use
the module name (as ram.c already does). Additionally improves region
reservation error to include the region name.
Signed-off-by: Kees Cook
---
Hi Greg,
On Thu, Nov 29, 2018 at 08:49:36AM +0100, Greg KH wrote:
> On Wed, Nov 28, 2018 at 03:01:16PM -0700, Mathieu Poirier wrote:
> > This patch uses the PMU driver configuration held in event::hw::drv_config
> > to select a sink for each event that is created (the old sysFS way of
> > working
The struct persistent_ram_zone wasn't well documented. This adds kern-doc
for it.
Signed-off-by: Kees Cook
---
fs/pstore/ram_core.c | 10 +
include/linux/pstore_ram.h | 46 +++---
2 files changed, 53 insertions(+), 3 deletions(-)
diff --git
With both ram.c and ram_core.c built into ramoops.ko, it doesn't make
sense to have differing pr_fmt prefixes. This fixes ram_core.c to use
the module name (as ram.c already does). Additionally improves region
reservation error to include the region name.
Signed-off-by: Kees Cook
---
Hi Greg,
On Thu, Nov 29, 2018 at 08:49:36AM +0100, Greg KH wrote:
> On Wed, Nov 28, 2018 at 03:01:16PM -0700, Mathieu Poirier wrote:
> > This patch uses the PMU driver configuration held in event::hw::drv_config
> > to select a sink for each event that is created (the old sysFS way of
> > working
This improves and updates some comments:
- dump handler comment out of sync from calling convention
- fix kern-doc typo
and improves status output:
- reminder that only kernel crash dumps are compressed
- do not be silent about ECC infrastructure failures
Signed-off-by: Kees Cook
---
In order to more easily perform automated regression testing, this
adds pr_debug() calls to report each prz allocation which can then be
verified against persistent storage. Specifically, seeing the dividing
line between header, data, any ECC bytes. (And the general assignment
output is updated to
The pull request you sent on Thu, 29 Nov 2018 11:48:40 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
> tags/selinux-pr-20181129
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f92a2ebb3d5588720a33d4f22d55b4ba24f94da6
Thank you!
--
From: Colin Ian King
Don't populate the const array dummy on the stack but instead
make it static. Makes the object code smaller by 26 bytes:
Before:
textdata bss dec hex filename
73712032 0940324bb drivers/fpga/altera-ps-spi.o
After:
textdata
The pull request you sent on Thu, 29 Nov 2018 13:16:38 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-4.20-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3578f19143b0a792bcd0ecb19f9295e2da563b54
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Thu, 29 Nov 2018 11:22:45 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> tags/sound-4.20-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b905e2db5cc42e64f8169474448f16083c535abe
Thank you!
--
Deet-doot-dot,
This improves and updates some comments:
- dump handler comment out of sync from calling convention
- fix kern-doc typo
and improves status output:
- reminder that only kernel crash dumps are compressed
- do not be silent about ECC infrastructure failures
Signed-off-by: Kees Cook
---
In order to more easily perform automated regression testing, this
adds pr_debug() calls to report each prz allocation which can then be
verified against persistent storage. Specifically, seeing the dividing
line between header, data, any ECC bytes. (And the general assignment
output is updated to
The pull request you sent on Thu, 29 Nov 2018 11:48:40 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
> tags/selinux-pr-20181129
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f92a2ebb3d5588720a33d4f22d55b4ba24f94da6
Thank you!
--
From: Colin Ian King
Don't populate the const array dummy on the stack but instead
make it static. Makes the object code smaller by 26 bytes:
Before:
textdata bss dec hex filename
73712032 0940324bb drivers/fpga/altera-ps-spi.o
After:
textdata
The pull request you sent on Thu, 29 Nov 2018 13:16:38 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-4.20-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3578f19143b0a792bcd0ecb19f9295e2da563b54
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Thu, 29 Nov 2018 11:22:45 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> tags/sound-4.20-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b905e2db5cc42e64f8169474448f16083c535abe
Thank you!
--
Deet-doot-dot,
From: Sudeep Holla
The current ARM DT topology description provides the operating system
with a topological view of the system that is based on leaf nodes
representing either cores or threads (in an SMT system) and a
hierarchical set of cluster nodes that creates a hierarchical topology
view of
From: "Joel Fernandes (Google)"
In later patches we will need to map types to names, so create a
constant table for that which can also be used in different parts of
old and new code. This saves the type in the PRZ which will be useful
in later patches.
Instead of having an explicit
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU topology.
Thus, both cpu-map DT binding and topology parsing code can be
moved to a common location so that RISC-V or
From: "Joel Fernandes (Google)"
In later patches we will need to map types to names, so create a
constant table for that which can also be used in different parts of
old and new code. This saves the type in the PRZ which will be useful
in later patches.
Instead of having an explicit
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU topology.
Thus, both cpu-map DT binding and topology parsing code can be
moved to a common location so that RISC-V or
From: Sudeep Holla
The current ARM DT topology description provides the operating system
with a topological view of the system that is based on leaf nodes
representing either cores or threads (in an SMT system) and a
hierarchical set of cluster nodes that creates a hierarchical topology
view of
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.
The relevant discussion can be found here.
https://lkml.org/lkml/2018/11/6/19
Signed-off-by: Atish Patra
---
.../{arm/topology.txt =>
Both RISC-V & ARM64 are using cpu-map device tree to describe
their cpu topology. It's better to move the relevant code to
a common place instead of duplicate code.
Signed-off-by: Atish Patra
---
arch/arm64/include/asm/topology.h | 22 ---
arch/arm64/kernel/topology.c | 303
Currently, there are no topology defined for RISC-V.
Parse the cpu-map node from device tree and setup the
cpu topology.
CPU topology after applying the patch.
$cat /sys/devices/system/cpu/cpu2/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/core_siblings_list
0-3
$cat
Currently, there are no topology defined for RISC-V.
Parse the cpu-map node from device tree and setup the
cpu topology.
CPU topology after applying the patch.
$cat /sys/devices/system/cpu/cpu2/topology/core_siblings_list
0-3
$cat /sys/devices/system/cpu/cpu3/topology/core_siblings_list
0-3
$cat
cpu-map binding can be used to described cpu topology for both
RISC-V & ARM. It makes more sense to move the binding to document
to a common place.
The relevant discussion can be found here.
https://lkml.org/lkml/2018/11/6/19
Signed-off-by: Atish Patra
---
.../{arm/topology.txt =>
Both RISC-V & ARM64 are using cpu-map device tree to describe
their cpu topology. It's better to move the relevant code to
a common place instead of duplicate code.
Signed-off-by: Atish Patra
---
arch/arm64/include/asm/topology.h | 22 ---
arch/arm64/kernel/topology.c | 303
Since the console writer does not use the preallocated crash dump buffer
any more, there is no reason to perform locking around it.
Fixes: 70ad35db3321 ("pstore: Convert console write to use ->write_buf")
Signed-off-by: Kees Cook
Reviewed-by: Joel Fernandes (Google)
---
fs/pstore/platform.c |
The pre-allocated compression buffer used for crash dumping was also
being used for decompression. This isn't technically safe, since it's
possible the kernel may attempt a crashdump while pstore is populating the
pstore filesystem (and performing decompression). Instead, just allocate
a separate
Since the console writer does not use the preallocated crash dump buffer
any more, there is no reason to perform locking around it.
Fixes: 70ad35db3321 ("pstore: Convert console write to use ->write_buf")
Signed-off-by: Kees Cook
Reviewed-by: Joel Fernandes (Google)
---
fs/pstore/platform.c |
The pre-allocated compression buffer used for crash dumping was also
being used for decompression. This isn't technically safe, since it's
possible the kernel may attempt a crashdump while pstore is populating the
pstore filesystem (and performing decompression). Instead, just allocate
a separate
From: "Joel Fernandes (Google)"
(1) remove type argument from ramoops_get_next_prz()
Since we store the type of the prz when we initialize it, we no longer
need to pass it again in ramoops_get_next_prz() since we can just use
that to setup the pstore record. So lets remove it from the argument
From: "Joel Fernandes (Google)"
The ramoops backend currently calls persistent_ram_save_old() even
if a buffer is empty. While this appears to work, it is does not seem
like the right thing to do and could lead to future bugs so lets avoid
that. It also prevents misleading prints in the logs
Minor clean-up to use BIT() (as already done in pstore_ram.h).
Signed-off-by: Kees Cook
---
include/linux/pstore.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 81669aa80027..f46e5df76b58 100644
---
From: "Joel Fernandes (Google)"
(1) remove type argument from ramoops_get_next_prz()
Since we store the type of the prz when we initialize it, we no longer
need to pass it again in ramoops_get_next_prz() since we can just use
that to setup the pstore record. So lets remove it from the argument
From: "Joel Fernandes (Google)"
The ramoops backend currently calls persistent_ram_save_old() even
if a buffer is empty. While this appears to work, it is does not seem
like the right thing to do and could lead to future bugs so lets avoid
that. It also prevents misleading prints in the logs
Minor clean-up to use BIT() (as already done in pstore_ram.h).
Signed-off-by: Kees Cook
---
include/linux/pstore.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 81669aa80027..f46e5df76b58 100644
---
This is a collection of clean-ups from Joel Fernandes, Peng Wang, and
myself. I wanted to put the entire series up for review since they've
changed a bit from their earlier incarnations. I intend to push them to
next shortly...
Thanks!
-Kees
Joel Fernandes (Google) (3):
pstore: Map
This is a collection of clean-ups from Joel Fernandes, Peng Wang, and
myself. I wanted to put the entire series up for review since they've
changed a bit from their earlier incarnations. I intend to push them to
next shortly...
Thanks!
-Kees
Joel Fernandes (Google) (3):
pstore: Map
On Mon, Oct 29, 2018 at 04:40:30PM -0600, Tycho Andersen wrote:
> + resp.id = req.id;
> + resp.error = -512; /* -ERESTARTSYS */
> + resp.val = 0;
> +
> + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, ), 0);
So, it turns out this *doesn't* work, and the reason this test was
On Mon, Oct 29, 2018 at 04:40:30PM -0600, Tycho Andersen wrote:
> + resp.id = req.id;
> + resp.error = -512; /* -ERESTARTSYS */
> + resp.val = 0;
> +
> + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, ), 0);
So, it turns out this *doesn't* work, and the reason this test was
Currently, a lock can block pending requests, but all pending
requests are equal. If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail. This can hurt performance.
So we will allow pending requests to block other requests.
Only the
Both locks_remove_posix() and locks_remove_flock() use a
struct file_lock without calling locks_init_lock() on it.
This means the various list_heads are not initialized, which
will become a problem with a later patch.
So change them both to initialize properly. For flock locks,
this involves
Currently, a lock can block pending requests, but all pending
requests are equal. If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail. This can hurt performance.
So we will allow pending requests to block other requests.
Only the
Both locks_remove_posix() and locks_remove_flock() use a
struct file_lock without calling locks_init_lock() on it.
This means the various list_heads are not initialized, which
will become a problem with a later patch.
So change them both to initialize properly. For flock locks,
this involves
When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list. When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending
posix_unblock_lock() is not specific to posix locks, and behaves
nearly identically to locks_delete_block() - the former returning a
status while the later doesn't.
So discard posix_unblock_lock() and use locks_delete_block() instead,
after giving that function an appropriate return value.
When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list. When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending
posix_unblock_lock() is not specific to posix locks, and behaves
nearly identically to locks_delete_block() - the former returning a
status while the later doesn't.
So discard posix_unblock_lock() and use locks_delete_block() instead,
after giving that function an appropriate return value.
- spaces before tabs,
- spaces at the end of lines,
- multiple blank lines,
- blank lines before EXPORT_SYMBOL,
can all go.
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
fs/locks.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff
- spaces before tabs,
- spaces at the end of lines,
- multiple blank lines,
- blank lines before EXPORT_SYMBOL,
can all go.
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
fs/locks.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff
Now that requests can block other requests, we
need to be careful to always clean up those blocked
requests.
Any time that we wait for a request, we might have
other requests attached, and when we stop waiting,
we must clean them up.
If the lock was granted, the requests might have been
moved to
Rather than assuming all-zeros is sufficient, use the available API to
initialize the file_lock structure use for unlock. VFS-level changes
will soon make it important that the list_heads in file_lock are
always properly initialized.
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
Using memcpy() to copy lock requests leaves the various
list_head in an inconsistent state.
As we will soon attach a list of conflicting request to
another pending request, we need these lists to be consistent.
So change NFS to use locks_init_lock/locks_copy_lock instead
of memcpy.
Signed-off-by:
Rather than assuming all-zeros is sufficient, use the available API to
initialize the file_lock structure use for unlock. VFS-level changes
will soon make it important that the list_heads in file_lock are
always properly initialized.
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
posix_locks_conflict() and flock_locks_conflict() both return int.
leases_conflict() returns bool.
This inconsistency will cause problems for the next patch if not
fixed.
So change posix_locks_conflict() and flock_locks_conflict() to return
bool.
Also change the locks_conflict() helper.
And
Using memcpy() to copy lock requests leaves the various
list_head in an inconsistent state.
As we will soon attach a list of conflicting request to
another pending request, we need these lists to be consistent.
So change NFS to use locks_init_lock/locks_copy_lock instead
of memcpy.
Signed-off-by:
Rather than assuming all-zeros is sufficient, use the available API to
initialize the file_lock structure use for unlock. VFS-level changes
will soon make it important that the list_heads in file_lock are
always properly initialized.
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
posix_locks_conflict() and flock_locks_conflict() both return int.
leases_conflict() returns bool.
This inconsistency will cause problems for the next patch if not
fixed.
So change posix_locks_conflict() and flock_locks_conflict() to return
bool.
Also change the locks_conflict() helper.
And
Now that requests can block other requests, we
need to be careful to always clean up those blocked
requests.
Any time that we wait for a request, we might have
other requests attached, and when we stop waiting,
we must clean them up.
If the lock was granted, the requests might have been
moved to
Rather than assuming all-zeros is sufficient, use the available API to
initialize the file_lock structure use for unlock. VFS-level changes
will soon make it important that the list_heads in file_lock are
always properly initialized.
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
Reviewed-by: J. Bruce Fields
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for. So rename it to fl_blocker.
The fl_blocked list_head in an active lock is the head of a list of
blocked requests. In a request it is a node in that list.
These are two
struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for. So rename it to fl_blocker.
The fl_blocked list_head in an active lock is the head of a list of
blocked requests. In a request it is a node in that list.
These are two
This series has the fixes for the recently reported performance
regressions merged into the patches which caused them.
It also has a couple of little fixes that have been mentioned on the
list, and that Jeff had merged into his copy.
Thanks,
NeilBrown
---
NeilBrown (12):
fs/locks: rename
This series has the fixes for the recently reported performance
regressions merged into the patches which caused them.
It also has a couple of little fixes that have been mentioned on the
list, and that Jeff had merged into his copy.
Thanks,
NeilBrown
---
NeilBrown (12):
fs/locks: rename
On Thu, Nov 29, 2018 at 08:13:12PM +0100, Lukas Wunner wrote:
> On Thu, Nov 29, 2018 at 06:57:37PM +, alex_gagn...@dellteam.com wrote:
> > On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> > > On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> > >> A warning is generated when a
On Thu, Nov 29, 2018 at 08:13:12PM +0100, Lukas Wunner wrote:
> On Thu, Nov 29, 2018 at 06:57:37PM +, alex_gagn...@dellteam.com wrote:
> > On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> > > On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> > >> A warning is generated when a
From: Colin Ian King
Don't populate the array cpcap_battery_irqs on the stack but instead
make it static. Makes the object code smaller by 99 bytes:
Before:
textdata bss dec hex filename
136732448 0 161213ef9 cpcap-battery.o
After:
textdata bss
On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote:
>
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> >
> > I propose a different solution:
> >
> > As in this patch set, we have a direct and an indirect version. The
> > indirect version remains exactly the same as in this
Hello,
This series optimizes the Adiantum encryption mode for x86_64 by adding
SSE2 and AVX2 accelerated implementations of NHPoly1305, specifically
the NH part; and by modifying the existing x86_64 SSSE3/AVX2/AVX-512VL
ChaCha20 implementation to support XChaCha20 and XChaCha12.
This greatly
From: Colin Ian King
Don't populate the array cpcap_battery_irqs on the stack but instead
make it static. Makes the object code smaller by 99 bytes:
Before:
textdata bss dec hex filename
136732448 0 161213ef9 cpcap-battery.o
After:
textdata bss
On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote:
>
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> >
> > I propose a different solution:
> >
> > As in this patch set, we have a direct and an indirect version. The
> > indirect version remains exactly the same as in this
Hello,
This series optimizes the Adiantum encryption mode for x86_64 by adding
SSE2 and AVX2 accelerated implementations of NHPoly1305, specifically
the NH part; and by modifying the existing x86_64 SSSE3/AVX2/AVX-512VL
ChaCha20 implementation to support XChaCha20 and XChaCha12.
This greatly
> Chanho Min wrote:
> >
> > > > > On Mon, 26 Nov 2018 06:36:37 +0100,
> > > > > Chanho Min wrote:
> > > > > >
> > > > > > Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-
> atomic
> > > > > > PCM
> > > > > > stream") fixes deadlock for non-atomic PCM stream. But, This
> patch
> > > > >
> Chanho Min wrote:
> >
> > > > > On Mon, 26 Nov 2018 06:36:37 +0100,
> > > > > Chanho Min wrote:
> > > > > >
> > > > > > Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-
> atomic
> > > > > > PCM
> > > > > > stream") fixes deadlock for non-atomic PCM stream. But, This
> patch
> > > > >
This series enables CPU frequency scaling on Meson8 and Meson8b. On
these SoCs all CPU cores are using the same clock, so all cores will
always run at the same frequency.
On Meson8b this is pretty straight-forward by taking the frequency and
voltage table from Amlogic's 3.10 vendor kernel and
This series enables CPU frequency scaling on Meson8 and Meson8b. On
these SoCs all CPU cores are using the same clock, so all cores will
always run at the same frequency.
On Meson8b this is pretty straight-forward by taking the frequency and
voltage table from Amlogic's 3.10 vendor kernel and
The values are taken from Amlogic's 3.10 kernel sources.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b.dtsi | 66 ++
1 file changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index
The values are taken from Amlogic's 3.10 kernel sources.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b.dtsi | 66 ++
1 file changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index
The values are taken from Amlogic's 3.10 kernel sources. Their sources
have a "meson8m2_n200_2G.dtd" which defines a different voltage table:
- 0.86V for 96MHz
- (values in between omitted)
- 1.14V for 1.992GHz
The reason for this is simply the hardware design because the voltage
regulator on
The values are taken from Amlogic's 3.10 kernel sources. Their sources
have a "meson8m2_n200_2G.dtd" which defines a different voltage table:
- 0.86V for 96MHz
- (values in between omitted)
- 1.14V for 1.992GHz
The reason for this is simply the hardware design because the voltage
regulator on
401 - 500 of 2748 matches
Mail list logo
