Re: [PATCH 2/2] PM: docs: Delete the obsolete states.txt document
> Am 20.08.2017 um 18:06 schrieb Rafael J. Wysocki : > > From: Rafael J. Wysocki > > The Documentation/power/states.txt document is now redundant and > sonewhat outdated, so delete it. > > Signed-off-by: Rafael J. Wysocki > --- > Documentation/power/states.txt | 127 > - > 1 file changed, 127 deletions(-) strange, I tried to apply the series, 1/2 applied but with 2/2 I get a "sha1 information is lacking or useless", did I miss something? -- Markus -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: > Hi all, > > Please give feedback on these patches which extends the PWM > framework in order to support multiple PWM signal types. > Since I didn't receive any inputs on RFC series I'm resending it as > normal patch series. > > The current patch series add the following PWM signal types: > - PWM complementary signals > - PWM push-pull signal > > Definition of PWM complementary mode: > For a PWM controllers with more than one outputs per PWM channel, > e.g. with 2 outputs per PWM channels, the PWM complementary signals > have opposite levels, same duration and same starting times, > as in the following diagram: > > ________ > PWMH __| |__| |__| |__| |__ > __________ > PWML |__| |__| |__| |__| ><--T--> > Where T is the signal period. > > Definition of PWM push-pull mode: > For PWM controllers with more than one outputs per PWM channel, > e.g. with 2 outputs per PWM channel, the PWM push-pull signals > have same levels, same duration and are delayed until the begining > of the next period, as in the following diagram: > > __ __ > PWMH __| || | > __ __ > PWML | || |__ ><--T--> > > Where T is the signal period. > > These output signals could be configured by setting PWM mode > (a new input in sysfs has been added in order to support this > operation). > > root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# > ls -l > -r--r--r--1 root root 4096 Feb 9 10:54 capture > -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle > -rw-r--r--1 root root 4096 Feb 9 10:54 enable > -rw-r--r--1 root root 4096 Feb 9 10:54 mode > -rw-r--r--1 root root 4096 Feb 9 10:54 period > -rw-r--r--1 root root 4096 Feb 9 10:55 polarity > drwxr-xr-x2 root root 0 Feb 9 10:54 power > -rw-r--r--1 root root 4096 Feb 9 10:54 uevent > > The PWM push-pull mode could be usefull in applications like > half bridge converters. Sorry for taking an absurdly long time to get back to you on this. One problem I see with this is that the PWM framework is built on the assumption that we have a single output per PWM channel. This becomes important when you start adding features such as this because now the users have no way of determining whether or not the PWM they retrieve will actually be able to do what they want. For example, let's say you have a half bridge converter driver in the kernel and it does a pwm_get() to obtain a PWM to use. There's nothing preventing it from using a simple one-output PWM and there's no way to check that we're actually doing something wrong. I think any in-kernel API would have to be more fully-featured, otherwise we're bound to run into problems. At the very least I think we'd have to expose some sort of capabilities list. A possibly simpler approach might be to restrict this to the driver that you need this for. It looks like you will be mainly using this via sysfs and in that case you might be able to just extend what information is exposed in sysfs for the particular PWM you're dealing with. Thierry signature.asc Description: PGP signature
Re: [PATCH 1/2] docs: Standardise capitalisation of section headers in core.rst
On Sat, 19 Aug 2017, Josh Holland wrote: > The table of contents in security/keys/core.rst had different > capitalisation to the section headers, which broke case-sensitive > search. > > Signed-off-by: Josh Holland > --- > Documentation/security/keys/core.rst | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/Documentation/security/keys/core.rst > b/Documentation/security/keys/core.rst > index 1648fa80b..7c39c595c 100644 > --- a/Documentation/security/keys/core.rst > +++ b/Documentation/security/keys/core.rst > @@ -16,17 +16,17 @@ The key service can be configured on by enabling: > > This document has the following sections: > > - - Key overview > - - Key service overview > - - Key access permissions > - - SELinux support > - - New procfs files > - - Userspace system call interface > - - Kernel services > - - Notes on accessing payload contents > - - Defining a key type > - - Request-key callback service > - - Garbage collection > + - Key Overview > + - Key Service Overview > + - Key Access Permissions > + - SELinux Support > + - New ProcFS Files > + - Userspace System Call Interface > + - Kernel Services > + - Notes On Accessing Payload Contents > + - Defining a Key Type > + - Request-Key Callback Service > + - Garbage Collection If you want to retain the contents in .rst for the benefit of reading this as plain text, this is fine. However, if you want to sphinxify things a little, you could make the resulting html a little bit nicer with automatic links, and document maintenance a little bit easier, by replacing the hand written contents with: .. contents:: :local: The maintainer's call, obviously. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: sunxi: add support for R40 SoC
Hi,
On Sun, Aug 20, 2017 at 01:29:57PM +0800, Icenowy Zheng wrote:
> Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
> like A20.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng
> ---
> Documentation/arm/sunxi/README | 6 ++
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
> arch/arm/mach-sunxi/sunxi.c | 1 +
> 3 files changed, 8 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index d7b1f016bd62..4fa836782e46 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -75,6 +75,12 @@ SunXi family
> + Datasheet
>http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
>
> + - Allwinner R40 (sun8i)
> ++ Datasheet
> +
> https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf
> ++ User Manual
> +
> https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf
> +
Please sort it by alphabetical order.
> * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
>- Allwinner A80
> + Datasheet
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
> b/Documentation/devicetree/bindings/arm/sunxi.txt
> index f35c6ada5a65..e4beec3d9ad3 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>allwinner,sun8i-a83t
>allwinner,sun8i-h2-plus
>allwinner,sun8i-h3
> + allwinner-sun8i-r40
>allwinner,sun8i-v3s
>allwinner,sun9i-a80
>allwinner,sun50i-a64
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 7ab353fb25f2..311e6c4fc4f4 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = {
> "allwinner,sun8i-h2-plus",
> "allwinner,sun8i-h3",
> "allwinner,sun8i-v3s",
> + "allwinner,sun8i-r40",
And same thing here.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [v5 2/4] mm, oom: cgroup-aware OOM killer
On Sun, Aug 20, 2017 at 05:50:27PM -0700, David Rientjes wrote: > On Wed, 16 Aug 2017, Roman Gushchin wrote: > > > It's natural to expect that inside a container there are their own sshd, > > "activity manager" or some other stuff, which can play with oom_score_adj. > > If it can override the upper cgroup-level settings, the whole delegation > > model > > is broken. > > > > I don't think any delegation model related to core cgroups or memory > cgroup is broken, I think it's based on how memory.oom_kill_all_tasks is > defined. It could very well behave as memory.oom_kill_all_eligible_tasks > when enacted upon. > > > You can think about the oom_kill_all_tasks like the panic_on_oom, > > but on a cgroup level. It should _guarantee_, that in case of oom > > the whole cgroup will be destroyed completely, and will not remain > > in a non-consistent state. > > > > Only CAP_SYS_ADMIN has this ability to set /proc/pid/oom_score_adj to CAP_SYS_RESOURCE > OOM_SCORE_ADJ_MIN, so it preserves the ability to change that setting, if > needed, when it sets memory.oom_kill_all_tasks. If a user gains > permissions to change memory.oom_kill_all_tasks, I disagree it should > override the CAP_SYS_ADMIN setting of /proc/pid/oom_score_adj. > > I would prefer not to exclude oom disabled processes to their own sibling > cgroups because they would require their own reservation with cgroup v2 > and it makes the single hierarchy model much more difficult to arrange > alongside cpusets, for example. > > > The model you're describing is based on a trust given to these > > oom-unkillable > > processes on system level. But we can't really trust some unknown processes > > inside a cgroup that they will be able to do some useful work and finish > > in a reasonable time; especially in case of a global memory shortage. > > Yes, we prefer to panic instead of sshd, for example, being oom killed. > We trust that sshd, as well as our own activity manager and security > daemons are trusted to do useful work and that we never want the kernel to > do this. I'm not sure why you are describing processes that CAP_SYS_ADMIN > has set to be oom disabled as unknown processes. > > I'd be interested in hearing the opinions of others related to a per-memcg > knob being allowed to override the setting of the sysadmin. Sure, me too. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states
Hi Rafael, great work, helps me and the world saving fossil fuels ;) > Am 20.08.2017 um 18:05 schrieb Rafael J. Wysocki : > > From: Rafael J. Wysocki > > Reorganize the power management part of admin-guide by adding a > description of major power management strategies supported by the > kernel (system-wide and working-state power management) to it and > dividing the rest of the material into the system-wide PM and > working-state PM chapters. > > On top of that, add a description of system sleep states to the > system-wide PM chapter. > > Signed-off-by: Rafael J. Wysocki > --- > Documentation/admin-guide/pm/index.rst |5 > Documentation/admin-guide/pm/sleep-states.rst | 234 > + > Documentation/admin-guide/pm/strategies.rst| 52 + > Documentation/admin-guide/pm/system-wide.rst | 15 + > Documentation/admin-guide/pm/working-state.rst | 16 + > 5 files changed, 320 insertions(+), 2 deletions(-) > > Index: linux-pm/Documentation/admin-guide/pm/index.rst > === > --- linux-pm.orig/Documentation/admin-guide/pm/index.rst > +++ linux-pm/Documentation/admin-guide/pm/index.rst > @@ -5,8 +5,9 @@ Power Management > .. toctree:: >:maxdepth: 2 > > - cpufreq > - intel_pstate > + strategies > + system-wide > + working-state > > .. only:: subproject and html BTW: lets drop this C&P 'only' block here. Subprojects are only where a Documentation/*/conf.py exists. The build does not have sub-sub-projects at Documentation/*/*/conf.py level. > Index: linux-pm/Documentation/admin-guide/pm/sleep-states.rst > === > --- /dev/null > +++ linux-pm/Documentation/admin-guide/pm/sleep-states.rst > @@ -0,0 +1,234 @@ > +=== > +System Sleep States > +=== > + > +:: > + > + Copyright (c) 2017 Intel Corp., Rafael J. Wysocki > > + > +Sleep states are global low-power states of the entire system in which user > +space code cannot be executed and the overall system activity is > significantly > +reduced. > + > + > + [...] > Index: linux-pm/Documentation/admin-guide/pm/system-wide.rst > === > --- /dev/null > +++ linux-pm/Documentation/admin-guide/pm/system-wide.rst > @@ -0,0 +1,15 @@ > + > +System-Wide Power Management > + > + > +.. toctree:: > + :maxdepth: 2 > + > + sleep-states > + > +.. only:: subproject and html > + > + Indices > + === > + > + * :ref:`genindex` Same here, lets drop the 'only' block. > Index: linux-pm/Documentation/admin-guide/pm/working-state.rst > === > --- /dev/null > +++ linux-pm/Documentation/admin-guide/pm/working-state.rst > @@ -0,0 +1,16 @@ > +== > +Working-State Power Management > +== > + > +.. toctree:: > + :maxdepth: 2 > + > + cpufreq > + intel_pstate > + > +.. only:: subproject and html > + > + Indices > + === > + > + * :ref:`genindex` Same here, lets drop the 'only' block. > Index: linux-pm/Documentation/admin-guide/pm/strategies.rst > === > --- /dev/null > +++ linux-pm/Documentation/admin-guide/pm/strategies.rst > @@ -0,0 +1,52 @@ > +=== > +Power Management Strategies > +=== > + > +:: > + > + Copyright (c) 2017 Intel Corp., Rafael J. Wysocki > > + > +The Linux kernel supports two major high-level power management strategies. > + > +One of them is based on using global low-power states of the whole system in > +which user space code cannot be executed and the overall system activity is > +significantly reduced, referred to as :doc:`sleep states `. > The > +kernel puts the system into one of these states when requested by user space > +and the system stays in it until a special signal is received from one of > +designated devices, triggering a transition to the ``working state`` in which > +user space code can run. Because sleep states are global and the whole > system > +is affected by the state changes, this strategy is referred to as the > +:doc:`system-wide power management `. I really appreciate your hyper-ref markup using :doc:`Foo ` and `Bar`_ it is very clear when reading the raw text files in the source tree. I think this has its value, but it also has its drawbacks when chapters are renamed or moved from one file to another. Thats, why I recommend using explicitly anchors / may be the maintainer Jon can give us his assessment. What I mean:: .. _foo: Foo === lorem see :ref:`bar` .. _bar: Bar === ipsum see :ref:`foo` With explicitly anchors: - there is no need to track when a chapter is renamed - or moved to another file, - same to renaming files - with intersphinx [1] othe
Re: [PATCH v8 00/20] ILP32 for ARM64
On Tue, Aug 08, 2017 at 02:34:11PM +0100, Catalin Marinas wrote:
> On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:
> > This is the 4.12 and linux-next - based kernel patches:
> > https://github.com/norov/linux/tree/ilp32-4.12
> > https://github.com/norov/linux/tree/ilp32-20170724
>
> I published the 4.12 branch here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=staging/ilp32-4.12
>
> (or git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> staging/ilp32-4.12)
>
> There are two patches on top, one to fix SET_PERSONALITY and the other
> to make ILP32 default y since you'd expect people using this branch to
> need such option enabled.
>
> I'll publish a 4.13-based branch when the corresponding kernel version
> is released.
Hi Catalin,
This is the rc-6 based ilp32 series:
https://github.com/norov/linux/tree/ilp32-4.13-rc6
It includes latest version of SET_PERSONALITY() rework:
https://www.spinics.net/lists/arm-kernel/msg602005.html
All patches prior to 3fc85ee96eb8 ("arm64: ilp32: add documentation on
the ILP32 ABI for ARM64") are looking not ilp32-specific and may be
applied independently.
It also includes your patch "arm64: ilp32: Make the Kconfig option
default y" on the top of series.
Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
Hi Thierry, Thank you for your response. I added few comments below. Thank you, Claudiu On 21.08.2017 11:25, Thierry Reding wrote: > On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: >> Hi all, >> >> Please give feedback on these patches which extends the PWM >> framework in order to support multiple PWM signal types. >> Since I didn't receive any inputs on RFC series I'm resending it as >> normal patch series. >> >> The current patch series add the following PWM signal types: >> - PWM complementary signals >> - PWM push-pull signal >> >> Definition of PWM complementary mode: >> For a PWM controllers with more than one outputs per PWM channel, >> e.g. with 2 outputs per PWM channels, the PWM complementary signals >> have opposite levels, same duration and same starting times, >> as in the following diagram: >> >> ________ >> PWMH __| |__| |__| |__| |__ >> __________ >> PWML |__| |__| |__| |__| >><--T--> >> Where T is the signal period. >> >> Definition of PWM push-pull mode: >> For PWM controllers with more than one outputs per PWM channel, >> e.g. with 2 outputs per PWM channel, the PWM push-pull signals >> have same levels, same duration and are delayed until the begining >> of the next period, as in the following diagram: >> >> __ __ >> PWMH __| || | >> __ __ >> PWML | || |__ >><--T--> >> >> Where T is the signal period. >> >> These output signals could be configured by setting PWM mode >> (a new input in sysfs has been added in order to support this >> operation). >> >> root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# >> ls -l >> -r--r--r--1 root root 4096 Feb 9 10:54 capture >> -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle >> -rw-r--r--1 root root 4096 Feb 9 10:54 enable >> -rw-r--r--1 root root 4096 Feb 9 10:54 mode >> -rw-r--r--1 root root 4096 Feb 9 10:54 period >> -rw-r--r--1 root root 4096 Feb 9 10:55 polarity >> drwxr-xr-x2 root root 0 Feb 9 10:54 power >> -rw-r--r--1 root root 4096 Feb 9 10:54 uevent >> >> The PWM push-pull mode could be usefull in applications like >> half bridge converters. > > Sorry for taking an absurdly long time to get back to you on this. > > One problem I see with this is that the PWM framework is built on the > assumption that we have a single output per PWM channel. This becomes > important when you start adding features such as this because now the > users have no way of determining whether or not the PWM they retrieve > will actually be able to do what they want. I was thinking that the framework is there to offer support in configuring the underlying hardware without taking into account how many outputs per PWM channels are actually present. It is true I only worked with Atmel/Microchip PWM controllers which for instance, SAMA5 SoC has a PWM controller with 2 outputs per PWM channel. Taking into account that the driver is already mainlined I though that the user is aware of what he is using (either a one output per PWM channel controller, or 2 outputs or more than 2) and about the underlying hardware support. I understand your position on this. I'm just explaining myself on the approach I've chose for this implementation. > > For example, let's say you have a half bridge converter driver in the > kernel and it does a pwm_get() to obtain a PWM to use. There's nothing > preventing it from using a simple one-output PWM and there's no way to > check that we're actually doing something wrong. I understand your position here. I've chose this approach taking into account that the user of the PWM will be aware of the capabilities of the underlying hardware because I worked on a controller which already has a mainlined driver and which has more than one output per PWM channel and I believe there are also other controllers with this kind of capability and with already mainlined driver (e.g. reading the code of STM32 PWM driver I saw a bool type variable in driver specific data structure (struct stm32_pwm): "bool have_complementary_output" which let me think that their controller also could support more than one output per PWM channel (I will also try to find the controller specific datasheet). At a first look I saw that also TI ECAP PWM controller supports this (it is true that I am not aware of how it is initialized in kernel, I need to check the datasheet, if it is public). > > I think any in-kernel API would have to be more fully-featured, > otherwise we're bound to run into problems. At the very least I think > we'd have to expose some sort of capabilities list. About the exposing of these capabilities would you prefer to have the supported PWM modes registered in driver probe as a new field mask in "struct pwm_chip". e.
Re: [PATCH v7 3/4] lib/cmdline.c Remove quotes symmetrically.
On 08/17/17 at 10:14pm, Michal Suchanek wrote:
> Remove quotes from argument value only if there is qoute on both sides.
>
> Signed-off-by: Michal Suchanek
Sounds reasonable. Just for curiosity, do we have chance to pass in
option with a single '"'?
> ---
> arch/powerpc/kernel/fadump.c | 6 ++
> lib/cmdline.c| 7 ++-
> 2 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index a1614d9b8a21..d7da4ce9f7ae 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -489,10 +489,8 @@ static void __init fadump_update_params(struct
> param_info *param_info,
> *tgt++ = ' ';
>
> /* next_arg removes one leading and one trailing '"' */
> - if (*tgt == '"')
> - shortening += 1;
> - if (*(tgt + vallen + shortening) == '"')
> - shortening += 1;
> + if ((*tgt == '"') && (*(tgt + vallen + shortening) == '"'))
> + shortening += 2;
>
> /* remove one leading and one trailing quote if both are present */
> if ((val[0] == '"') && (val[vallen - 1] == '"')) {
> diff --git a/lib/cmdline.c b/lib/cmdline.c
> index 4c0888c4a68d..01e701b2afe8 100644
> --- a/lib/cmdline.c
> +++ b/lib/cmdline.c
> @@ -227,14 +227,11 @@ char *next_arg(char *args, char **param, char **val)
> *val = args + equals + 1;
>
> /* Don't include quotes in value. */
> - if (**val == '"') {
> + if ((**val == '"') && (args[i-1] == '"')) {
> (*val)++;
> - if (args[i-1] == '"')
> - args[i-1] = '\0';
> + args[i-1] = '\0';
> }
> }
> - if (quoted && args[i-1] == '"')
> - args[i-1] = '\0';
>
> if (args[i]) {
> args[i] = '\0';
> --
> 2.10.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
On Mon, Aug 21, 2017 at 01:23:08PM +0300, m18063 wrote: > Hi Thierry, > > Thank you for your response. I added few comments below. > > Thank you, > Claudiu > > On 21.08.2017 11:25, Thierry Reding wrote: > > On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: > >> Hi all, > >> > >> Please give feedback on these patches which extends the PWM > >> framework in order to support multiple PWM signal types. > >> Since I didn't receive any inputs on RFC series I'm resending it as > >> normal patch series. > >> > >> The current patch series add the following PWM signal types: > >> - PWM complementary signals > >> - PWM push-pull signal > >> > >> Definition of PWM complementary mode: > >> For a PWM controllers with more than one outputs per PWM channel, > >> e.g. with 2 outputs per PWM channels, the PWM complementary signals > >> have opposite levels, same duration and same starting times, > >> as in the following diagram: > >> > >> ________ > >> PWMH __| |__| |__| |__| |__ > >> __________ > >> PWML |__| |__| |__| |__| > >><--T--> > >> Where T is the signal period. > >> > >> Definition of PWM push-pull mode: > >> For PWM controllers with more than one outputs per PWM channel, > >> e.g. with 2 outputs per PWM channel, the PWM push-pull signals > >> have same levels, same duration and are delayed until the begining > >> of the next period, as in the following diagram: > >> > >> __ __ > >> PWMH __| || | > >> __ __ > >> PWML | || |__ > >><--T--> > >> > >> Where T is the signal period. > >> > >> These output signals could be configured by setting PWM mode > >> (a new input in sysfs has been added in order to support this > >> operation). > >> > >> root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# > >> ls -l > >> -r--r--r--1 root root 4096 Feb 9 10:54 capture > >> -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle > >> -rw-r--r--1 root root 4096 Feb 9 10:54 enable > >> -rw-r--r--1 root root 4096 Feb 9 10:54 mode > >> -rw-r--r--1 root root 4096 Feb 9 10:54 period > >> -rw-r--r--1 root root 4096 Feb 9 10:55 polarity > >> drwxr-xr-x2 root root 0 Feb 9 10:54 power > >> -rw-r--r--1 root root 4096 Feb 9 10:54 uevent > >> > >> The PWM push-pull mode could be usefull in applications like > >> half bridge converters. > > > > Sorry for taking an absurdly long time to get back to you on this. > > > > One problem I see with this is that the PWM framework is built on the > > assumption that we have a single output per PWM channel. This becomes > > important when you start adding features such as this because now the > > users have no way of determining whether or not the PWM they retrieve > > will actually be able to do what they want. > I was thinking that the framework is there to offer support in configuring > the underlying hardware without taking into account how many outputs per > PWM channels are actually present. It is true I only worked with > Atmel/Microchip > PWM controllers which for instance, SAMA5 SoC has a PWM controller > with 2 outputs per PWM channel. Taking into account that the driver is > already mainlined I though that the user is aware of what he is using > (either a one output per PWM channel controller, or 2 outputs or > more than 2) and about the underlying hardware support. I understand your > position on this. I'm just explaining myself on the approach I've chose > for this implementation. So currently we assume that there will be (at least) one output per PWM channel. However there are currently no drivers that actually use any output other than the "primary" one. That means, even if there are currently PWM controllers that support multiple outputs per PWM channel, we have no code making assumptions about it. Before we can add code that makes any assumptions about the number of outputs per PWM channel, we have to add facitilities for such code to detect capabilities, so that they can deal with PWMs that don't match what they need. > > For example, let's say you have a half bridge converter driver in the > > kernel and it does a pwm_get() to obtain a PWM to use. There's nothing > > preventing it from using a simple one-output PWM and there's no way to > > check that we're actually doing something wrong. > I understand your position here. I've chose this approach taking into > account that the user of the PWM will be aware of the capabilities > of the underlying hardware because I worked on a controller which already > has a mainlined driver and which has more than one output per PWM channel > and I believe there are also other controllers with this kind of capability > and with already mainlined driver (e.g. reading the code of STM32 PWM driver > I saw a bool type
Re: [PATCH v7 3/4] lib/cmdline.c Remove quotes symmetrically.
On Mon, 21 Aug 2017 18:27:12 +0800 Baoquan He wrote: > On 08/17/17 at 10:14pm, Michal Suchanek wrote: > > Remove quotes from argument value only if there is qoute on both > > sides. > > > > Signed-off-by: Michal Suchanek > > Sounds reasonable. Just for curiosity, do we have chance to pass in > option with a single '"'? No, we don't. Perhaps it would work if it was at the end of the commandline. next_arg checks that quoting is closed. It was possible but undocumented with previous behavior - you would place the quote in the middle and the closing quote at start or end so that next_arg would remove the closing quote but not the one in the middle. It would be also possible with shell-like backslash escaping but that is not implemented. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states
On Mon, Aug 21, 2017 at 11:51 AM, Markus Heiser wrote: > Hi Rafael, > > great work, helps me and the world saving fossil fuels ;) Thanks! >> Am 20.08.2017 um 18:05 schrieb Rafael J. Wysocki : >> >> From: Rafael J. Wysocki >> >> Reorganize the power management part of admin-guide by adding a >> description of major power management strategies supported by the >> kernel (system-wide and working-state power management) to it and >> dividing the rest of the material into the system-wide PM and >> working-state PM chapters. >> >> On top of that, add a description of system sleep states to the >> system-wide PM chapter. >> >> Signed-off-by: Rafael J. Wysocki >> --- >> Documentation/admin-guide/pm/index.rst |5 >> Documentation/admin-guide/pm/sleep-states.rst | 234 >> + >> Documentation/admin-guide/pm/strategies.rst| 52 + >> Documentation/admin-guide/pm/system-wide.rst | 15 + >> Documentation/admin-guide/pm/working-state.rst | 16 + >> 5 files changed, 320 insertions(+), 2 deletions(-) >> >> Index: linux-pm/Documentation/admin-guide/pm/index.rst >> === >> --- linux-pm.orig/Documentation/admin-guide/pm/index.rst >> +++ linux-pm/Documentation/admin-guide/pm/index.rst >> @@ -5,8 +5,9 @@ Power Management >> .. toctree:: >>:maxdepth: 2 >> >> - cpufreq >> - intel_pstate >> + strategies >> + system-wide >> + working-state >> >> .. only:: subproject and html > > BTW: lets drop this C&P 'only' block here. Subprojects are only where a > Documentation/*/conf.py exists. The build does not have sub-sub-projects > at Documentation/*/*/conf.py level. OK [cut] > >> Index: linux-pm/Documentation/admin-guide/pm/strategies.rst >> === >> --- /dev/null >> +++ linux-pm/Documentation/admin-guide/pm/strategies.rst >> @@ -0,0 +1,52 @@ >> +=== >> +Power Management Strategies >> +=== >> + >> +:: >> + >> + Copyright (c) 2017 Intel Corp., Rafael J. Wysocki >> >> + >> +The Linux kernel supports two major high-level power management strategies. >> + >> +One of them is based on using global low-power states of the whole system in >> +which user space code cannot be executed and the overall system activity is >> +significantly reduced, referred to as :doc:`sleep states `. >> The >> +kernel puts the system into one of these states when requested by user space >> +and the system stays in it until a special signal is received from one of >> +designated devices, triggering a transition to the ``working state`` in >> which >> +user space code can run. Because sleep states are global and the whole >> system >> +is affected by the state changes, this strategy is referred to as the >> +:doc:`system-wide power management `. > > I really appreciate your hyper-ref markup using :doc:`Foo ` and `Bar`_ > it is very clear when reading the raw text files in the source tree. I think > this has its value, but it also has its drawbacks when chapters are renamed > or moved from one file to another. Thats, why I recommend using explicitly > anchors / may be the maintainer Jon can give us his assessment. What I mean:: > > .. _foo: > > Foo > === > > lorem see :ref:`bar` > > .. _bar: > > Bar > === > > ipsum see :ref:`foo` > > With explicitly anchors: > > - there is no need to track when a chapter is renamed > - or moved to another file, > - same to renaming files > - with intersphinx [1] other projects can link to such anchors > > [1] http://www.sphinx-doc.org/en/stable/ext/intersphinx.html OK, makes sense. >> + >> +The other strategy, referred to as the >> +:doc:`working-state power management `, > > Even if you use :ref: or :doc: both are line-break-safe ... > > +The other strategy, referred to as the :doc:`working-state power > +management `, ... > > .. should work. I works. I'll send a v2 with the above changes shortly Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dm-devel] [PATCH v5 12/19] dm: move dm-verity to generic async completion
On Sat, Aug 19, 2017 at 11:08 PM, Mikulas Patocka wrote:
>
>
>
> On Mon, 14 Aug 2017, Gilad Ben-Yossef wrote:
>
> > dm-verity is starting async. crypto ops and waiting for them to complete.
> > Move it over to generic code doing the same.
> >
> > This also fixes a possible data coruption bug created by the
> > use of wait_for_completion_interruptible() without dealing
> > correctly with an interrupt aborting the wait prior to the
> > async op finishing.
>
> What is the exact problem there? The interruptible sleep is called from a
> workqueue and workqueues have all signals blocked. Are signals unblocked
> for some reason there?
I should have used "potential" rather then "possible". My bad.
My point was that the use of wait_for_completion_interruptible() is wrong
because we are not really ready to handle a signal *if* it arrives.
Yes, since we are being called from a workqueue this will not happen, but:
a. we (or rather I, since I wrote the offending code...) shouldn't call
*_interruptible() in a function that is executing with signals masked
unconditionally. It makes not sense.
b. someone might move the context this is executing in in the future, or make
some other change that will enable signals and create a very subtle bug.
>
>
> Should there be another patch for stable kernels that fixes the
> interruptible sleep?
No, for the reason you pointed yourself - signals are blocked here, so this
is a potential bug only but can't be triggered.
I already sent a patch set fixing similar places that had the
same issue and it went into stable - e.g.
https://patchwork.kernel.org/patch/9781693/
Thanks,
Gilad
>
>
> Mikulas
>
> > Signed-off-by: Gilad Ben-Yossef
> > ---
> > drivers/md/dm-verity-target.c | 81
> > +++
> > drivers/md/dm-verity.h| 5 ---
> > 2 files changed, 20 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
> > index 79f18d4..8df08a8 100644
> > --- a/drivers/md/dm-verity-target.c
> > +++ b/drivers/md/dm-verity-target.c
> > @@ -92,74 +92,33 @@ static sector_t verity_position_at_level(struct
> > dm_verity *v, sector_t block,
> > return block >> (level * v->hash_per_block_bits);
> > }
> >
> > -/*
> > - * Callback function for asynchrnous crypto API completion notification
> > - */
> > -static void verity_op_done(struct crypto_async_request *base, int err)
> > -{
> > - struct verity_result *res = (struct verity_result *)base->data;
> > -
> > - if (err == -EINPROGRESS)
> > - return;
> > -
> > - res->err = err;
> > - complete(&res->completion);
> > -}
> > -
> > -/*
> > - * Wait for async crypto API callback
> > - */
> > -static inline int verity_complete_op(struct verity_result *res, int ret)
> > -{
> > - switch (ret) {
> > - case 0:
> > - break;
> > -
> > - case -EINPROGRESS:
> > - case -EBUSY:
> > - ret = wait_for_completion_interruptible(&res->completion);
> > - if (!ret)
> > - ret = res->err;
> > - reinit_completion(&res->completion);
> > - break;
> > -
> > - default:
> > - DMERR("verity_wait_hash: crypto op submission failed: %d",
> > ret);
> > - }
> > -
> > - if (unlikely(ret < 0))
> > - DMERR("verity_wait_hash: crypto op failed: %d", ret);
> > -
> > - return ret;
> > -}
> > -
> > static int verity_hash_update(struct dm_verity *v, struct ahash_request
> > *req,
> > const u8 *data, size_t len,
> > - struct verity_result *res)
> > + struct crypto_wait *wait)
> > {
> > struct scatterlist sg;
> >
> > sg_init_one(&sg, data, len);
> > ahash_request_set_crypt(req, &sg, NULL, len);
> >
> > - return verity_complete_op(res, crypto_ahash_update(req));
> > + return crypto_wait_req(crypto_ahash_update(req), wait);
> > }
> >
> > /*
> > * Wrapper for crypto_ahash_init, which handles verity salting.
> > */
> > static int verity_hash_init(struct dm_verity *v, struct ahash_request *req,
> > - struct verity_result *res)
> > + struct crypto_wait *wait)
> > {
> > int r;
> >
> > ahash_request_set_tfm(req, v->tfm);
> > ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP |
> > CRYPTO_TFM_REQ_MAY_BACKLOG,
> > - verity_op_done, (void *)res);
> > - init_completion(&res->completion);
> > + crypto_req_done, (void *)wait);
> > + crypto_init_wait(wait);
> >
> > - r = verity_complete_op(res, crypto_ahash_init(req));
> > + r = crypto_wait_req(crypto_ahash_init(req), wait);
> >
> > if (unlikely(r < 0)) {
> > DMERR("crypto_ahash_init failed: %d", r);
> > @@ -167,18 +126,18 @@ static int verity_hash_i
Re: [PATCH v5 05/19] crypto: introduce crypto wait for async op
On Tue, Aug 15, 2017 at 5:23 AM, Jonathan Cameron wrote: > On Mon, 14 Aug 2017 18:21:15 +0300 > Gilad Ben-Yossef wrote: > >> Invoking a possibly async. crypto op and waiting for completion >> while correctly handling backlog processing is a common task >> in the crypto API implementation and outside users of it. >> >> This patch adds a generic implementation for doing so in >> preparation for using it across the board instead of hand >> rolled versions. > > Trivial observation. Shouldn't have this bonus blank line inserted here. > >> #endif /* _LINUX_CRYPTO_H */ >> > Indeed. Will be fixed. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] docs: Standardise capitalisation of section headers in core.rst
On Mon, 21 Aug 2017 12:15:26 +0300 Jani Nikula wrote: > However, if you want to sphinxify things a little, you could make the > resulting html a little bit nicer with automatic links, and document > maintenance a little bit easier, by replacing the hand written contents > with: > > .. contents:: >:local: I think this is what we should do. I don't think that manually listing the section heads buys a whole lot for readers of the docs, and experience says they won't be kept in sync with the rest of the document. I'd much rather see a patch taking them out and letting Sphinx do the work. Part 2 looks fine, though, I'll apply that shortly. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] PM: docs: Delete the obsolete states.txt document
On Monday, August 21, 2017 9:39:17 AM CEST Markus Heiser wrote: > > > Am 20.08.2017 um 18:06 schrieb Rafael J. Wysocki : > > > > From: Rafael J. Wysocki > > > > The Documentation/power/states.txt document is now redundant and > > sonewhat outdated, so delete it. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > Documentation/power/states.txt | 127 > > - > > 1 file changed, 127 deletions(-) > > strange, I tried to apply the series, 1/2 applied but with 2/2 I get a > "sha1 information is lacking or useless", did I miss something? You need to apply this on top of linux-next, as some changes are made to states.txt in one of the pending PM commits. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] PM: docs: Describe high-level PM strategies and sleep states
From: Rafael J. Wysocki Reorganize the power management part of admin-guide by adding a description of major power management strategies supported by the kernel (system-wide and working-state power management) to it and dividing the rest of the material into the system-wide PM and working-state PM chapters. On top of that, add a description of system sleep states to the system-wide PM chapter. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukas Wunner --- -> v2: - Changed the wording in the strategies.rst document slightly to address Lukas' comments. - Changed refs in the sleep-states.rst document to address Markus' comments. - Followed Markus' suggestion to drop C&P 'only' blocks in a few places. - Added Reviewed-by from Lukas as the changes to the content are very small. --- Documentation/admin-guide/pm/index.rst | 12 - Documentation/admin-guide/pm/sleep-states.rst | 245 + Documentation/admin-guide/pm/strategies.rst| 52 + Documentation/admin-guide/pm/system-wide.rst |8 Documentation/admin-guide/pm/working-state.rst |9 5 files changed, 317 insertions(+), 9 deletions(-) Index: linux-pm/Documentation/admin-guide/pm/index.rst === --- linux-pm.orig/Documentation/admin-guide/pm/index.rst +++ linux-pm/Documentation/admin-guide/pm/index.rst @@ -5,12 +5,6 @@ Power Management .. toctree:: :maxdepth: 2 - cpufreq - intel_pstate - -.. only:: subproject and html - - Indices - === - - * :ref:`genindex` + strategies + system-wide + working-state Index: linux-pm/Documentation/admin-guide/pm/sleep-states.rst === --- /dev/null +++ linux-pm/Documentation/admin-guide/pm/sleep-states.rst @@ -0,0 +1,245 @@ +=== +System Sleep States +=== + +:: + + Copyright (c) 2017 Intel Corp., Rafael J. Wysocki + +Sleep states are global low-power states of the entire system in which user +space code cannot be executed and the overall system activity is significantly +reduced. + + +Sleep States That Can Be Supported +== + +Depending on its configuration and the capabilities of the platform it runs on, +the Linux kernel can support up to four system sleep states, includig +hibernation and up to three variants of system suspend. The sleep states that +can be supported by the kernel are listed below. + +.. _s2idle: + +Suspend-to-Idle +--- + +This is a generic, pure software, light-weight variant of system suspend (also +referred to as S2I or S2Idle). It allows more energy to be saved relative to +runtime idle by freezing user space, suspending the timekeeping and putting all +I/O devices into low-power states (possibly lower-power than available in the +working state), such that the processors can spend time in their deepest idle +states while the system is suspended. + +The system is woken up from this state by in-band interrupts, so theoretically +any devices that can cause interrupts to be generated in the working state can +also be set up as wakeup devices for S2Idle. + +This state can be used on platforms without support for :ref:`standby ` +or :ref:`suspend-to-RAM `, or it can be used in addition to any of the +deeper system suspend variants to provide reduced resume latency. It is always +supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set. + +.. _standby: + +Standby +--- + +This state, if supported, offers moderate, but real, energy savings, while +providing a relatively straightforward transition back to the working state. No +operating state is lost (the system core logic retains power), so the system can +go back to where it left off easily enough. + +In addition to freezing user space, suspending the timekeeping and putting all +I/O devices into low-power states, which is done for :ref:`suspend-to-idle +` too, nonboot CPUs are taken offline and all low-level system functions +are suspended during transitions into this state. For this reason, it should +allow more energy to be saved relative to :ref:`suspend-to-idle `, but +the resume latency will generally be greater than for that state. + +The set of devices that can wake up the system from this state usually is +reduced relative to :ref:`suspend-to-idle ` and it may be necessary to +rely on the platform for setting up the wakeup functionality as appropriate. + +This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration +option is set and the support for it is registered by the platform with the +core system suspend subsystem. On ACPI-based systems this state is mapped to +the S1 system state defined by ACPI. + +.. _s2ram: + +Suspend-to-RAM +-- + +This state (also referred to as STR or S2RAM), if supported, offers significant +energy savings as everything in the system is put into a low-power stat
Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
On 08/20/2017 11:23 PM, Wangkai (Kevin,C) wrote: > > Yes, I have add some trace info for the dentry state changed, with dentry > flag and reference count: > > File create: > [ 42.636675] dentry [_1234] 0x880230be8180 flag 0x0 ref 1 ev dentry > alloc > File close: > [ 42.637421] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref 0 ev > dput called > > Unlink lookup: > [ 244.658086] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref 1 ev > d_lookup > Unlink d_delete: > [ 244.658254] dentry [_1234] 0x880230be8180 flag 0x800c0 ref 1 ev > d_lockref ref 1 > Unlink dput: > [ 244.658438] dentry [_1234] 0x880230be8180 flag 0x800c0 ref 0 ev > dput called > > The end, dentry's flag stay at 0x800c0, but this dentry was not freed, keeped > by the dcache as unused, > After tens of thousands of the dentries slow down the dentry lookup > performance, kernel memory usage > Keep high. > > Regards, > Kevin That is expected. The kernel does not get rid of negative dentries until the shrinker is called because of memory pressure. Negative dentries do help to improve file lookup performance. However, too much of negative dentries suppress the amount of free memory available for other use. That is why I send out my patch to limit the number of negative dentries outstanding. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
+fscrypt is not guaranteed to protect confidentiality or authenticity +if an attacker is able to manipulate the filesystem offline prior to +an authorized user later accessing the filesystem. How does fscrypt / Android protect against Evil Maid attack. ? Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 00/19] simplify crypto wait for async op
Many users of kernel async. crypto services have a pattern of starting an async. crypto op and than using a completion to wait for it to end. This patch set simplifies this common use case in two ways: First, by separating the return codes of the case where a request is queued to a backlog due to the provider being busy (-EBUSY) from the case the request has failed due to the provider being busy and backlogging is not enabled (-EAGAIN). Next, this change is than built on to create a generic API to wait for a async. crypto operation to complete. The end result is a smaller code base and an API that is easier to use and more difficult to get wrong. The patch set was boot tested on x86_64 and arm64 which at the very least tests the crypto users via testmgr and tcrypt but I do note that I do not have access to some of the HW whose drivers are modified nor do I claim I was able to test all of the corner cases. The patch set is based upon linux-next release tagged next-20170817. Changes from v5: - Remove redundant new line as spotted by Jonathan Cameron. - Reworded dm-verity change commit message to better clarify potential issue averted by change as pointed out by Mikulas Patocka. Changes from v4: - Rebase on top of latest algif changes from Stephan Mueller. - Fix typo in ccp patch title. Changes from v3: - Instead of changing the return code to indicate backlog queueing, change the return code to indicate transient busy state, as suggested by Herbert Xu. Changes from v2: - Patch title changed from "introduce crypto wait for async op" to better reflect the current state. - Rebase on top of latest linux-next. - Add a new return code of -EIOCBQUEUED for backlog queueing, as suggested by Herbert Xu. - Transform more users to the new API. - Update the drbg change to account for new init as indicated by Stephan Muller. Changes from v1: - Address review comments from Eric Biggers. - Separated out bug fixes of existing code and rebase on top of that patch set. - Rename 'ecr' to 'wait' in fscrypto code. - Split patch introducing the new API from the change moving over the algif code which it originated from to the new API. - Inline crypto_wait_req(). - Some code indentation fixes. Gilad Ben-Yossef (19): crypto: change transient busy return code to -EAGAIN crypto: ccp: use -EAGAIN for transient busy indication crypto: remove redundant backlog checks on EBUSY crypto: marvell/cesa: remove redundant backlog checks on EBUSY crypto: introduce crypto wait for async op crypto: move algif to generic async completion crypto: move pub key to generic async completion crypto: move drbg to generic async completion crypto: move gcm to generic async completion crypto: move testmgr to generic async completion fscrypt: move to generic async completion dm: move dm-verity to generic async completion cifs: move to generic async completion ima: move to generic async completion crypto: tcrypt: move to generic async completion crypto: talitos: move to generic async completion crypto: qce: move to generic async completion crypto: mediatek: move to generic async completion crypto: adapt api sample to use async. op wait Documentation/crypto/api-samples.rst | 52 ++--- crypto/af_alg.c | 27 - crypto/ahash.c | 12 +-- crypto/algapi.c | 6 +- crypto/algif_aead.c | 8 +- crypto/algif_hash.c | 50 + crypto/algif_skcipher.c | 9 +- crypto/api.c | 13 +++ crypto/asymmetric_keys/public_key.c | 28 + crypto/cryptd.c | 4 +- crypto/cts.c | 6 +- crypto/drbg.c| 36 ++- crypto/gcm.c | 32 ++ crypto/lrw.c | 8 +- crypto/rsa-pkcs1pad.c| 16 +-- crypto/tcrypt.c | 84 +-- crypto/testmgr.c | 204 --- crypto/xts.c | 8 +- drivers/crypto/ccp/ccp-crypto-main.c | 8 +- drivers/crypto/ccp/ccp-dev.c | 7 +- drivers/crypto/marvell/cesa.c| 3 +- drivers/crypto/marvell/cesa.h| 2 +- drivers/crypto/mediatek/mtk-aes.c| 31 +- drivers/crypto/qce/sha.c | 30 +- drivers/crypto/talitos.c | 38 +-- drivers/md/dm-verity-target.c| 81 -- drivers/md/dm-verity.h | 5 - fs/cifs/smb2ops.c| 30 +- fs/crypto/crypto.c | 28 + fs/crypto/fname.c| 36 ++- fs/crypto/fscrypt_private.h | 10 -- fs/crypto/keyinfo.c | 21 +--- include/crypto/drbg.h| 3 +- include/crypto/if_alg.h | 15 +-- include/linux/crypto.h | 40 +++ security/integrity
[PATCH v6 01/19] crypto: change transient busy return code to -EAGAIN
The crypto API was using the -EBUSY return value to indicate
both a hard failure to submit a crypto operation into a
transformation provider when the latter was busy and the backlog
mechanism was not enabled as well as a notification that the
operation was queued into the backlog when the backlog mechanism
was enabled.
Having the same return code indicate two very different conditions
depending on a flag is both error prone and requires extra runtime
check like the following to discern between the cases:
if (err == -EINPROGRESS ||
(err == -EBUSY && (ahash_request_flags(req) &
CRYPTO_TFM_REQ_MAY_BACKLOG)))
This patch changes the return code used to indicate a crypto op
failed due to the transformation provider being transiently busy
to -EAGAIN.
Signed-off-by: Gilad Ben-Yossef
---
crypto/algapi.c | 6 --
crypto/algif_hash.c | 20 +---
crypto/cryptd.c | 4 +---
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index aa699ff..916bee3 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -897,9 +897,11 @@ int crypto_enqueue_request(struct crypto_queue *queue,
int err = -EINPROGRESS;
if (unlikely(queue->qlen >= queue->max_qlen)) {
- err = -EBUSY;
- if (!(request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (!(request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) {
+ err = -EAGAIN;
goto out;
+ }
+ err = -EBUSY;
if (queue->backlog == &queue->list)
queue->backlog = &request->list;
}
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 5e92bd2..3b3c154 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -39,6 +39,20 @@ struct algif_hash_tfm {
bool has_key;
};
+/* Previous versions of crypto_* ops used to return -EBUSY
+ * rather than -EAGAIN to indicate being tied up. The in
+ * kernel API changed but we don't want to break the user
+ * space API. As only the hash user interface exposed this
+ * error ever to the user, do the translation here.
+ */
+static inline int crypto_user_err(int err)
+{
+ if (err == -EAGAIN)
+ return -EBUSY;
+
+ return err;
+}
+
static int hash_alloc_result(struct sock *sk, struct hash_ctx *ctx)
{
unsigned ds;
@@ -136,7 +150,7 @@ static int hash_sendmsg(struct socket *sock, struct msghdr
*msg,
unlock:
release_sock(sk);
- return err ?: copied;
+ return err ? crypto_user_err(err) : copied;
}
static ssize_t hash_sendpage(struct socket *sock, struct page *page,
@@ -188,7 +202,7 @@ static ssize_t hash_sendpage(struct socket *sock, struct
page *page,
unlock:
release_sock(sk);
- return err ?: size;
+ return err ? crypto_user_err(err) : size;
}
static int hash_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
@@ -236,7 +250,7 @@ static int hash_recvmsg(struct socket *sock, struct msghdr
*msg, size_t len,
hash_free_result(sk, ctx);
release_sock(sk);
- return err ?: len;
+ return err ? crypto_user_err(err) : len;
}
static int hash_accept(struct socket *sock, struct socket *newsock, int flags,
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 0508c48..d1dbdce 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -137,16 +137,14 @@ static int cryptd_enqueue_request(struct cryptd_queue
*queue,
int cpu, err;
struct cryptd_cpu_queue *cpu_queue;
atomic_t *refcnt;
- bool may_backlog;
cpu = get_cpu();
cpu_queue = this_cpu_ptr(queue->cpu_queue);
err = crypto_enqueue_request(&cpu_queue->queue, request);
refcnt = crypto_tfm_ctx(request->tfm);
- may_backlog = request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG;
- if (err == -EBUSY && !may_backlog)
+ if (err == -EAGAIN)
goto out_put_cpu;
queue_work_on(cpu, kcrypto_wq, &cpu_queue->work);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 09/19] crypto: move gcm to generic async completion
gcm is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
crypto/gcm.c | 32 ++--
1 file changed, 6 insertions(+), 26 deletions(-)
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 3841b5e..fb923a5 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -16,7 +16,6 @@
#include
#include
#include "internal.h"
-#include
#include
#include
#include
@@ -78,11 +77,6 @@ struct crypto_gcm_req_priv_ctx {
} u;
};
-struct crypto_gcm_setkey_result {
- int err;
- struct completion completion;
-};
-
static struct {
u8 buf[16];
struct scatterlist sg;
@@ -98,17 +92,6 @@ static inline struct crypto_gcm_req_priv_ctx
*crypto_gcm_reqctx(
return (void *)PTR_ALIGN((u8 *)aead_request_ctx(req), align + 1);
}
-static void crypto_gcm_setkey_done(struct crypto_async_request *req, int err)
-{
- struct crypto_gcm_setkey_result *result = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- result->err = err;
- complete(&result->completion);
-}
-
static int crypto_gcm_setkey(struct crypto_aead *aead, const u8 *key,
unsigned int keylen)
{
@@ -119,7 +102,7 @@ static int crypto_gcm_setkey(struct crypto_aead *aead,
const u8 *key,
be128 hash;
u8 iv[16];
- struct crypto_gcm_setkey_result result;
+ struct crypto_wait wait;
struct scatterlist sg[1];
struct skcipher_request req;
@@ -140,21 +123,18 @@ static int crypto_gcm_setkey(struct crypto_aead *aead,
const u8 *key,
if (!data)
return -ENOMEM;
- init_completion(&data->result.completion);
+ crypto_init_wait(&data->wait);
sg_init_one(data->sg, &data->hash, sizeof(data->hash));
skcipher_request_set_tfm(&data->req, ctr);
skcipher_request_set_callback(&data->req, CRYPTO_TFM_REQ_MAY_SLEEP |
CRYPTO_TFM_REQ_MAY_BACKLOG,
- crypto_gcm_setkey_done,
- &data->result);
+ crypto_req_done,
+ &data->wait);
skcipher_request_set_crypt(&data->req, data->sg, data->sg,
sizeof(data->hash), data->iv);
- err = crypto_skcipher_encrypt(&data->req);
- if (err == -EINPROGRESS || err == -EBUSY) {
- wait_for_completion(&data->result.completion);
- err = data->result.err;
- }
+ err = crypto_wait_req(crypto_skcipher_encrypt(&data->req),
+ &data->wait);
if (err)
goto out;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 12/19] dm: move dm-verity to generic async completion
dm-verity is starting async. crypto ops and waiting for them to complete.
Move it over to generic code doing the same.
This also avoids a future potential data coruption bug created
by the use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
async op finishing, should this code ever move to a context
where signals are not masked.
Signed-off-by: Gilad Ben-Yossef
CC: Mikulas Patocka
---
drivers/md/dm-verity-target.c | 81 +++
drivers/md/dm-verity.h| 5 ---
2 files changed, 20 insertions(+), 66 deletions(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index 79f18d4..8df08a8 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -92,74 +92,33 @@ static sector_t verity_position_at_level(struct dm_verity
*v, sector_t block,
return block >> (level * v->hash_per_block_bits);
}
-/*
- * Callback function for asynchrnous crypto API completion notification
- */
-static void verity_op_done(struct crypto_async_request *base, int err)
-{
- struct verity_result *res = (struct verity_result *)base->data;
-
- if (err == -EINPROGRESS)
- return;
-
- res->err = err;
- complete(&res->completion);
-}
-
-/*
- * Wait for async crypto API callback
- */
-static inline int verity_complete_op(struct verity_result *res, int ret)
-{
- switch (ret) {
- case 0:
- break;
-
- case -EINPROGRESS:
- case -EBUSY:
- ret = wait_for_completion_interruptible(&res->completion);
- if (!ret)
- ret = res->err;
- reinit_completion(&res->completion);
- break;
-
- default:
- DMERR("verity_wait_hash: crypto op submission failed: %d", ret);
- }
-
- if (unlikely(ret < 0))
- DMERR("verity_wait_hash: crypto op failed: %d", ret);
-
- return ret;
-}
-
static int verity_hash_update(struct dm_verity *v, struct ahash_request *req,
const u8 *data, size_t len,
- struct verity_result *res)
+ struct crypto_wait *wait)
{
struct scatterlist sg;
sg_init_one(&sg, data, len);
ahash_request_set_crypt(req, &sg, NULL, len);
- return verity_complete_op(res, crypto_ahash_update(req));
+ return crypto_wait_req(crypto_ahash_update(req), wait);
}
/*
* Wrapper for crypto_ahash_init, which handles verity salting.
*/
static int verity_hash_init(struct dm_verity *v, struct ahash_request *req,
- struct verity_result *res)
+ struct crypto_wait *wait)
{
int r;
ahash_request_set_tfm(req, v->tfm);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP |
CRYPTO_TFM_REQ_MAY_BACKLOG,
- verity_op_done, (void *)res);
- init_completion(&res->completion);
+ crypto_req_done, (void *)wait);
+ crypto_init_wait(wait);
- r = verity_complete_op(res, crypto_ahash_init(req));
+ r = crypto_wait_req(crypto_ahash_init(req), wait);
if (unlikely(r < 0)) {
DMERR("crypto_ahash_init failed: %d", r);
@@ -167,18 +126,18 @@ static int verity_hash_init(struct dm_verity *v, struct
ahash_request *req,
}
if (likely(v->salt_size && (v->version >= 1)))
- r = verity_hash_update(v, req, v->salt, v->salt_size, res);
+ r = verity_hash_update(v, req, v->salt, v->salt_size, wait);
return r;
}
static int verity_hash_final(struct dm_verity *v, struct ahash_request *req,
-u8 *digest, struct verity_result *res)
+u8 *digest, struct crypto_wait *wait)
{
int r;
if (unlikely(v->salt_size && (!v->version))) {
- r = verity_hash_update(v, req, v->salt, v->salt_size, res);
+ r = verity_hash_update(v, req, v->salt, v->salt_size, wait);
if (r < 0) {
DMERR("verity_hash_final failed updating salt: %d", r);
@@ -187,7 +146,7 @@ static int verity_hash_final(struct dm_verity *v, struct
ahash_request *req,
}
ahash_request_set_crypt(req, NULL, digest, 0);
- r = verity_complete_op(res, crypto_ahash_final(req));
+ r = crypto_wait_req(crypto_ahash_final(req), wait);
out:
return r;
}
@@ -196,17 +155,17 @@ int verity_hash(struct dm_verity *v, struct ahash_request
*req,
const u8 *data, size_t len, u8 *digest)
{
int r;
- struct verity_result res;
+ struct crypto_wait wait;
- r = verity_hash_init(v, req, &res);
+ r = verity_hash_init(v, req, &wait);
if (unlikely(r < 0))
[PATCH v6 19/19] crypto: adapt api sample to use async. op wait
The code sample is waiting for an async. crypto op completion.
Adapt sample to use the new generic infrastructure to do the same.
This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
async op finishing.
Signed-off-by: Gilad Ben-Yossef
---
Documentation/crypto/api-samples.rst | 52 +++-
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/Documentation/crypto/api-samples.rst
b/Documentation/crypto/api-samples.rst
index 2531948..006827e 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -7,59 +7,27 @@ Code Example For Symmetric Key Cipher Operation
::
-struct tcrypt_result {
-struct completion completion;
-int err;
-};
-
/* tie all data structures together */
struct skcipher_def {
struct scatterlist sg;
struct crypto_skcipher *tfm;
struct skcipher_request *req;
-struct tcrypt_result result;
+struct crypto_wait wait;
};
-/* Callback function */
-static void test_skcipher_cb(struct crypto_async_request *req, int error)
-{
-struct tcrypt_result *result = req->data;
-
-if (error == -EINPROGRESS)
-return;
-result->err = error;
-complete(&result->completion);
-pr_info("Encryption finished successfully\n");
-}
-
/* Perform cipher operation */
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
int enc)
{
-int rc = 0;
+int rc;
if (enc)
-rc = crypto_skcipher_encrypt(sk->req);
+rc = crypto_wait_req(crypto_skcipher_encrypt(sk->req), &sk->wait);
else
-rc = crypto_skcipher_decrypt(sk->req);
-
-switch (rc) {
-case 0:
-break;
-case -EINPROGRESS:
-case -EBUSY:
-rc = wait_for_completion_interruptible(
-&sk->result.completion);
-if (!rc && !sk->result.err) {
-reinit_completion(&sk->result.completion);
-break;
-}
-default:
-pr_info("skcipher encrypt returned with %d result %d\n",
-rc, sk->result.err);
-break;
-}
-init_completion(&sk->result.completion);
+rc = crypto_wait_req(crypto_skcipher_decrypt(sk->req), &sk->wait);
+
+ if (rc)
+ pr_info("skcipher encrypt returned with result %d\n", rc);
return rc;
}
@@ -89,8 +57,8 @@ Code Example For Symmetric Key Cipher Operation
}
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- test_skcipher_cb,
- &sk.result);
+ crypto_req_done,
+ &sk.wait);
/* AES 256 with random key */
get_random_bytes(&key, 32);
@@ -122,7 +90,7 @@ Code Example For Symmetric Key Cipher Operation
/* We encrypt one block */
sg_init_one(&sk.sg, scratchpad, 16);
skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
-init_completion(&sk.result.completion);
+crypto_init_wait(&sk.wait);
/* encrypt data */
ret = test_skcipher_encdec(&sk, 1);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 18/19] crypto: mediatek: move to generic async completion
The mediatek driver starts several async crypto ops and waits for their
completions. Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
Acked-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 31 +--
1 file changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index 9e845e8..e2c7c95 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -137,11 +137,6 @@ struct mtk_aes_gcm_ctx {
struct crypto_skcipher *ctr;
};
-struct mtk_aes_gcm_setkey_result {
- int err;
- struct completion completion;
-};
-
struct mtk_aes_drv {
struct list_head dev_list;
/* Device list lock */
@@ -936,17 +931,6 @@ static int mtk_aes_gcm_crypt(struct aead_request *req, u64
mode)
&req->base);
}
-static void mtk_gcm_setkey_done(struct crypto_async_request *req, int err)
-{
- struct mtk_aes_gcm_setkey_result *result = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- result->err = err;
- complete(&result->completion);
-}
-
/*
* Because of the hardware limitation, we need to pre-calculate key(H)
* for the GHASH operation. The result of the encryption operation
@@ -962,7 +946,7 @@ static int mtk_aes_gcm_setkey(struct crypto_aead *aead,
const u8 *key,
u32 hash[4];
u8 iv[8];
- struct mtk_aes_gcm_setkey_result result;
+ struct crypto_wait wait;
struct scatterlist sg[1];
struct skcipher_request req;
@@ -1002,22 +986,17 @@ static int mtk_aes_gcm_setkey(struct crypto_aead *aead,
const u8 *key,
if (!data)
return -ENOMEM;
- init_completion(&data->result.completion);
+ crypto_init_wait(&data->wait);
sg_init_one(data->sg, &data->hash, AES_BLOCK_SIZE);
skcipher_request_set_tfm(&data->req, ctr);
skcipher_request_set_callback(&data->req, CRYPTO_TFM_REQ_MAY_SLEEP |
CRYPTO_TFM_REQ_MAY_BACKLOG,
- mtk_gcm_setkey_done, &data->result);
+ crypto_req_done, &data->wait);
skcipher_request_set_crypt(&data->req, data->sg, data->sg,
AES_BLOCK_SIZE, data->iv);
- err = crypto_skcipher_encrypt(&data->req);
- if (err == -EINPROGRESS || err == -EBUSY) {
- err = wait_for_completion_interruptible(
- &data->result.completion);
- if (!err)
- err = data->result.err;
- }
+ err = crypto_wait_req(crypto_skcipher_encrypt(&data->req),
+ &data->wait);
if (err)
goto out;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 16/19] crypto: talitos: move to generic async completion
The talitos driver starts several async crypto ops and waits for their
completions. Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/talitos.c | 38 +-
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 79791c6..194a307 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2037,22 +2037,6 @@ static int ahash_import(struct ahash_request *areq,
const void *in)
return 0;
}
-struct keyhash_result {
- struct completion completion;
- int err;
-};
-
-static void keyhash_complete(struct crypto_async_request *req, int err)
-{
- struct keyhash_result *res = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- res->err = err;
- complete(&res->completion);
-}
-
static int keyhash(struct crypto_ahash *tfm, const u8 *key, unsigned int
keylen,
u8 *hash)
{
@@ -2060,10 +2044,10 @@ static int keyhash(struct crypto_ahash *tfm, const u8
*key, unsigned int keylen,
struct scatterlist sg[1];
struct ahash_request *req;
- struct keyhash_result hresult;
+ struct crypto_wait wait;
int ret;
- init_completion(&hresult.completion);
+ crypto_init_wait(&wait);
req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!req)
@@ -2072,25 +2056,13 @@ static int keyhash(struct crypto_ahash *tfm, const u8
*key, unsigned int keylen,
/* Keep tfm keylen == 0 during hash of the long key */
ctx->keylen = 0;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- keyhash_complete, &hresult);
+ crypto_req_done, &wait);
sg_init_one(&sg[0], key, keylen);
ahash_request_set_crypt(req, sg, hash, keylen);
- ret = crypto_ahash_digest(req);
- switch (ret) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- ret = wait_for_completion_interruptible(
- &hresult.completion);
- if (!ret)
- ret = hresult.err;
- break;
- default:
- break;
- }
+ ret = crypto_wait_req(crypto_ahash_digest(req), &wait);
+
ahash_request_free(req);
return ret;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 17/19] crypto: qce: move to generic async completion
The qce driver starts several async crypto ops and waits for their
completions. Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/qce/sha.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
index 47e114a..53227d7 100644
--- a/drivers/crypto/qce/sha.c
+++ b/drivers/crypto/qce/sha.c
@@ -349,28 +349,12 @@ static int qce_ahash_digest(struct ahash_request *req)
return qce->async_req_enqueue(tmpl->qce, &req->base);
}
-struct qce_ahash_result {
- struct completion completion;
- int error;
-};
-
-static void qce_digest_complete(struct crypto_async_request *req, int error)
-{
- struct qce_ahash_result *result = req->data;
-
- if (error == -EINPROGRESS)
- return;
-
- result->error = error;
- complete(&result->completion);
-}
-
static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm, const u8 *key,
unsigned int keylen)
{
unsigned int digestsize = crypto_ahash_digestsize(tfm);
struct qce_sha_ctx *ctx = crypto_tfm_ctx(&tfm->base);
- struct qce_ahash_result result;
+ struct crypto_wait wait;
struct ahash_request *req;
struct scatterlist sg;
unsigned int blocksize;
@@ -405,9 +389,9 @@ static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm,
const u8 *key,
goto err_free_ahash;
}
- init_completion(&result.completion);
+ crypto_init_wait(&wait);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- qce_digest_complete, &result);
+ crypto_req_done, &wait);
crypto_ahash_clear_flags(ahash_tfm, ~0);
buf = kzalloc(keylen + QCE_MAX_ALIGN_SIZE, GFP_KERNEL);
@@ -420,13 +404,7 @@ static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm,
const u8 *key,
sg_init_one(&sg, buf, keylen);
ahash_request_set_crypt(req, &sg, ctx->authkey, keylen);
- ret = crypto_ahash_digest(req);
- if (ret == -EINPROGRESS || ret == -EBUSY) {
- ret = wait_for_completion_interruptible(&result.completion);
- if (!ret)
- ret = result.error;
- }
-
+ ret = crypto_wait_req(crypto_ahash_digest(req), &wait);
if (ret)
crypto_ahash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 15/19] crypto: tcrypt: move to generic async completion
tcrypt starts several async crypto ops and waits for their completions.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
crypto/tcrypt.c | 84 +
1 file changed, 25 insertions(+), 59 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 0022a18..802aa81 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -79,34 +79,11 @@ static char *check[] = {
NULL
};
-struct tcrypt_result {
- struct completion completion;
- int err;
-};
-
-static void tcrypt_complete(struct crypto_async_request *req, int err)
-{
- struct tcrypt_result *res = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- res->err = err;
- complete(&res->completion);
-}
-
static inline int do_one_aead_op(struct aead_request *req, int ret)
{
- if (ret == -EINPROGRESS || ret == -EBUSY) {
- struct tcrypt_result *tr = req->base.data;
+ struct crypto_wait *wait = req->base.data;
- ret = wait_for_completion_interruptible(&tr->completion);
- if (!ret)
- ret = tr->err;
- reinit_completion(&tr->completion);
- }
-
- return ret;
+ return crypto_wait_req(ret, wait);
}
static int test_aead_jiffies(struct aead_request *req, int enc,
@@ -248,7 +225,7 @@ static void test_aead_speed(const char *algo, int enc,
unsigned int secs,
char *axbuf[XBUFSIZE];
unsigned int *b_size;
unsigned int iv_len;
- struct tcrypt_result result;
+ struct crypto_wait wait;
iv = kzalloc(MAX_IVLEN, GFP_KERNEL);
if (!iv)
@@ -284,7 +261,7 @@ static void test_aead_speed(const char *algo, int enc,
unsigned int secs,
goto out_notfm;
}
- init_completion(&result.completion);
+ crypto_init_wait(&wait);
printk(KERN_INFO "\ntesting speed of %s (%s) %s\n", algo,
get_driver_name(crypto_aead, tfm), e);
@@ -296,7 +273,7 @@ static void test_aead_speed(const char *algo, int enc,
unsigned int secs,
}
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- tcrypt_complete, &result);
+ crypto_req_done, &wait);
i = 0;
do {
@@ -397,21 +374,16 @@ static void test_hash_sg_init(struct scatterlist *sg)
static inline int do_one_ahash_op(struct ahash_request *req, int ret)
{
- if (ret == -EINPROGRESS || ret == -EBUSY) {
- struct tcrypt_result *tr = req->base.data;
+ struct crypto_wait *wait = req->base.data;
- wait_for_completion(&tr->completion);
- reinit_completion(&tr->completion);
- ret = tr->err;
- }
- return ret;
+ return crypto_wait_req(ret, wait);
}
struct test_mb_ahash_data {
struct scatterlist sg[TVMEMSIZE];
char result[64];
struct ahash_request *req;
- struct tcrypt_result tresult;
+ struct crypto_wait wait;
char *xbuf[XBUFSIZE];
};
@@ -440,7 +412,7 @@ static void test_mb_ahash_speed(const char *algo, unsigned
int sec,
if (testmgr_alloc_buf(data[i].xbuf))
goto out;
- init_completion(&data[i].tresult.completion);
+ crypto_init_wait(&data[i].wait);
data[i].req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!data[i].req) {
@@ -449,8 +421,8 @@ static void test_mb_ahash_speed(const char *algo, unsigned
int sec,
goto out;
}
- ahash_request_set_callback(data[i].req, 0,
- tcrypt_complete, &data[i].tresult);
+ ahash_request_set_callback(data[i].req, 0, crypto_req_done,
+ &data[i].wait);
test_hash_sg_init(data[i].sg);
}
@@ -492,16 +464,16 @@ static void test_mb_ahash_speed(const char *algo,
unsigned int sec,
if (ret)
break;
- complete(&data[k].tresult.completion);
- data[k].tresult.err = 0;
+ crypto_req_done(&data[k].req->base, 0);
}
for (j = 0; j < k; j++) {
- struct tcrypt_result *tr = &data[j].tresult;
+ struct crypto_wait *wait = &data[j].wait;
+ int wait_ret;
- wait_for_completion(&tr->completion);
- if (tr->err)
- ret = tr->err;
+ wait_ret = crypto_wait_req(-EINPROGRESS, wait);
+ if (wait_ret)
+ ret = wait_ret;
}
end = get_cycles();
@@ -679,7 +651,7 @@ static void test_ahash_speed_comm
[PATCH v6 13/19] cifs: move to generic async completion
cifs starts an async. crypto op and waits for their completion.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
Acked-by: Pavel Shilovsky
---
fs/cifs/smb2ops.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index cfacf2c..16fb041 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -1878,22 +1878,6 @@ init_sg(struct smb_rqst *rqst, u8 *sign)
return sg;
}
-struct cifs_crypt_result {
- int err;
- struct completion completion;
-};
-
-static void cifs_crypt_complete(struct crypto_async_request *req, int err)
-{
- struct cifs_crypt_result *res = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- res->err = err;
- complete(&res->completion);
-}
-
static int
smb2_get_enc_key(struct TCP_Server_Info *server, __u64 ses_id, int enc, u8
*key)
{
@@ -1934,12 +1918,10 @@ crypt_message(struct TCP_Server_Info *server, struct
smb_rqst *rqst, int enc)
struct aead_request *req;
char *iv;
unsigned int iv_len;
- struct cifs_crypt_result result = {0, };
+ DECLARE_CRYPTO_WAIT(wait);
struct crypto_aead *tfm;
unsigned int crypt_len = le32_to_cpu(tr_hdr->OriginalMessageSize);
- init_completion(&result.completion);
-
rc = smb2_get_enc_key(server, tr_hdr->SessionId, enc, key);
if (rc) {
cifs_dbg(VFS, "%s: Could not get %scryption key\n", __func__,
@@ -1999,14 +1981,10 @@ crypt_message(struct TCP_Server_Info *server, struct
smb_rqst *rqst, int enc)
aead_request_set_ad(req, assoc_data_len);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- cifs_crypt_complete, &result);
+ crypto_req_done, &wait);
- rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);
-
- if (rc == -EINPROGRESS || rc == -EBUSY) {
- wait_for_completion(&result.completion);
- rc = result.err;
- }
+ rc = crypto_wait_req(enc ? crypto_aead_encrypt(req)
+ : crypto_aead_decrypt(req), &wait);
if (!rc && enc)
memcpy(&tr_hdr->Signature, sign, SMB2_SIGNATURE_SIZE);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 14/19] ima: move to generic async completion
ima starts several async crypto ops and waits for their completions.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
Acked-by: Mimi Zohar
---
security/integrity/ima/ima_crypto.c | 56 +++--
1 file changed, 17 insertions(+), 39 deletions(-)
diff --git a/security/integrity/ima/ima_crypto.c
b/security/integrity/ima/ima_crypto.c
index a856d8c..9057b16 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -27,11 +27,6 @@
#include "ima.h"
-struct ahash_completion {
- struct completion completion;
- int err;
-};
-
/* minimum file size for ahash use */
static unsigned long ima_ahash_minsize;
module_param_named(ahash_minsize, ima_ahash_minsize, ulong, 0644);
@@ -196,30 +191,13 @@ static void ima_free_atfm(struct crypto_ahash *tfm)
crypto_free_ahash(tfm);
}
-static void ahash_complete(struct crypto_async_request *req, int err)
+static inline int ahash_wait(int err, struct crypto_wait *wait)
{
- struct ahash_completion *res = req->data;
- if (err == -EINPROGRESS)
- return;
- res->err = err;
- complete(&res->completion);
-}
+ err = crypto_wait_req(err, wait);
-static int ahash_wait(int err, struct ahash_completion *res)
-{
- switch (err) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- wait_for_completion(&res->completion);
- reinit_completion(&res->completion);
- err = res->err;
- /* fall through */
- default:
+ if (err)
pr_crit_ratelimited("ahash calculation failed: err: %d\n", err);
- }
return err;
}
@@ -233,7 +211,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
int rc, read = 0, rbuf_len, active = 0, ahash_rc = 0;
struct ahash_request *req;
struct scatterlist sg[1];
- struct ahash_completion res;
+ struct crypto_wait wait;
size_t rbuf_size[2];
hash->length = crypto_ahash_digestsize(tfm);
@@ -242,12 +220,12 @@ static int ima_calc_file_hash_atfm(struct file *file,
if (!req)
return -ENOMEM;
- init_completion(&res.completion);
+ crypto_init_wait(&wait);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
CRYPTO_TFM_REQ_MAY_SLEEP,
- ahash_complete, &res);
+ crypto_req_done, &wait);
- rc = ahash_wait(crypto_ahash_init(req), &res);
+ rc = ahash_wait(crypto_ahash_init(req), &wait);
if (rc)
goto out1;
@@ -288,7 +266,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
* read/request, wait for the completion of the
* previous ahash_update() request.
*/
- rc = ahash_wait(ahash_rc, &res);
+ rc = ahash_wait(ahash_rc, &wait);
if (rc)
goto out3;
}
@@ -304,7 +282,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
* read/request, wait for the completion of the
* previous ahash_update() request.
*/
- rc = ahash_wait(ahash_rc, &res);
+ rc = ahash_wait(ahash_rc, &wait);
if (rc)
goto out3;
}
@@ -318,7 +296,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
active = !active; /* swap buffers, if we use two */
}
/* wait for the last update request to complete */
- rc = ahash_wait(ahash_rc, &res);
+ rc = ahash_wait(ahash_rc, &wait);
out3:
if (read)
file->f_mode &= ~FMODE_READ;
@@ -327,7 +305,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
out2:
if (!rc) {
ahash_request_set_crypt(req, NULL, hash->digest, 0);
- rc = ahash_wait(crypto_ahash_final(req), &res);
+ rc = ahash_wait(crypto_ahash_final(req), &wait);
}
out1:
ahash_request_free(req);
@@ -537,7 +515,7 @@ static int calc_buffer_ahash_atfm(const void *buf, loff_t
len,
{
struct ahash_request *req;
struct scatterlist sg;
- struct ahash_completion res;
+ struct crypto_wait wait;
int rc, ahash_rc = 0;
hash->length = crypto_ahash_digestsize(tfm);
@@ -546,12 +524,12 @@ static int calc_buffer_ahash_atfm(const void *buf, loff_t
len,
if (!req)
return -ENOMEM;
- init_completion(&res.completion);
+ crypto_init_wait(&wait);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
CRYPTO_TFM_REQ_MAY_SLEEP,
-
[PATCH v6 11/19] fscrypt: move to generic async completion
fscrypt starts several async. crypto ops and waiting for them to
complete. Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
fs/crypto/crypto.c | 28
fs/crypto/fname.c | 36 ++--
fs/crypto/fscrypt_private.h | 10 --
fs/crypto/keyinfo.c | 21 +++--
4 files changed, 13 insertions(+), 82 deletions(-)
diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
index c7835df..80a3cad 100644
--- a/fs/crypto/crypto.c
+++ b/fs/crypto/crypto.c
@@ -126,21 +126,6 @@ struct fscrypt_ctx *fscrypt_get_ctx(const struct inode
*inode, gfp_t gfp_flags)
}
EXPORT_SYMBOL(fscrypt_get_ctx);
-/**
- * page_crypt_complete() - completion callback for page crypto
- * @req: The asynchronous cipher request context
- * @res: The result of the cipher operation
- */
-static void page_crypt_complete(struct crypto_async_request *req, int res)
-{
- struct fscrypt_completion_result *ecr = req->data;
-
- if (res == -EINPROGRESS)
- return;
- ecr->res = res;
- complete(&ecr->completion);
-}
-
int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw,
u64 lblk_num, struct page *src_page,
struct page *dest_page, unsigned int len,
@@ -151,7 +136,7 @@ int fscrypt_do_page_crypto(const struct inode *inode,
fscrypt_direction_t rw,
u8 padding[FS_IV_SIZE - sizeof(__le64)];
} iv;
struct skcipher_request *req = NULL;
- DECLARE_FS_COMPLETION_RESULT(ecr);
+ DECLARE_CRYPTO_WAIT(wait);
struct scatterlist dst, src;
struct fscrypt_info *ci = inode->i_crypt_info;
struct crypto_skcipher *tfm = ci->ci_ctfm;
@@ -179,7 +164,7 @@ int fscrypt_do_page_crypto(const struct inode *inode,
fscrypt_direction_t rw,
skcipher_request_set_callback(
req, CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
- page_crypt_complete, &ecr);
+ crypto_req_done, &wait);
sg_init_table(&dst, 1);
sg_set_page(&dst, dest_page, len, offs);
@@ -187,14 +172,9 @@ int fscrypt_do_page_crypto(const struct inode *inode,
fscrypt_direction_t rw,
sg_set_page(&src, src_page, len, offs);
skcipher_request_set_crypt(req, &src, &dst, len, &iv);
if (rw == FS_DECRYPT)
- res = crypto_skcipher_decrypt(req);
+ res = crypto_wait_req(crypto_skcipher_decrypt(req), &wait);
else
- res = crypto_skcipher_encrypt(req);
- if (res == -EINPROGRESS || res == -EBUSY) {
- BUG_ON(req->base.data != &ecr);
- wait_for_completion(&ecr.completion);
- res = ecr.res;
- }
+ res = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
skcipher_request_free(req);
if (res) {
printk_ratelimited(KERN_ERR
diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
index ad9f814..a80a0d3 100644
--- a/fs/crypto/fname.c
+++ b/fs/crypto/fname.c
@@ -15,21 +15,6 @@
#include "fscrypt_private.h"
/**
- * fname_crypt_complete() - completion callback for filename crypto
- * @req: The asynchronous cipher request context
- * @res: The result of the cipher operation
- */
-static void fname_crypt_complete(struct crypto_async_request *req, int res)
-{
- struct fscrypt_completion_result *ecr = req->data;
-
- if (res == -EINPROGRESS)
- return;
- ecr->res = res;
- complete(&ecr->completion);
-}
-
-/**
* fname_encrypt() - encrypt a filename
*
* The caller must have allocated sufficient memory for the @oname string.
@@ -40,7 +25,7 @@ static int fname_encrypt(struct inode *inode,
const struct qstr *iname, struct fscrypt_str *oname)
{
struct skcipher_request *req = NULL;
- DECLARE_FS_COMPLETION_RESULT(ecr);
+ DECLARE_CRYPTO_WAIT(wait);
struct fscrypt_info *ci = inode->i_crypt_info;
struct crypto_skcipher *tfm = ci->ci_ctfm;
int res = 0;
@@ -76,17 +61,12 @@ static int fname_encrypt(struct inode *inode,
}
skcipher_request_set_callback(req,
CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
- fname_crypt_complete, &ecr);
+ crypto_req_done, &wait);
sg_init_one(&sg, oname->name, cryptlen);
skcipher_request_set_crypt(req, &sg, &sg, cryptlen, iv);
/* Do the encryption */
- res = crypto_skcipher_encrypt(req);
- if (res == -EINPROGRESS || res == -EBUSY) {
- /* Request is being completed asynchronously; wait for it */
- wait_for_completion(&ecr.completion);
- res = ecr.res;
- }
+ res = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
skcipher_request_free(req);
if (res < 0) {
printk_ratelimite
[PATCH v6 10/19] crypto: move testmgr to generic async completion
testmgr is starting async. crypto ops and waiting for them to complete.
Move it over to generic code doing the same.
This also provides a test of the generic crypto async. wait code.
Signed-off-by: Gilad Ben-Yossef
---
crypto/testmgr.c | 204 ++-
1 file changed, 66 insertions(+), 138 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 7125ba3..a65b4d5 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -76,11 +76,6 @@ int alg_test(const char *driver, const char *alg, u32 type,
u32 mask)
#define ENCRYPT 1
#define DECRYPT 0
-struct tcrypt_result {
- struct completion completion;
- int err;
-};
-
struct aead_test_suite {
struct {
const struct aead_testvec *vecs;
@@ -155,17 +150,6 @@ static void hexdump(unsigned char *buf, unsigned int len)
buf, len, false);
}
-static void tcrypt_complete(struct crypto_async_request *req, int err)
-{
- struct tcrypt_result *res = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- res->err = err;
- complete(&res->completion);
-}
-
static int testmgr_alloc_buf(char *buf[XBUFSIZE])
{
int i;
@@ -193,20 +177,10 @@ static void testmgr_free_buf(char *buf[XBUFSIZE])
free_page((unsigned long)buf[i]);
}
-static int wait_async_op(struct tcrypt_result *tr, int ret)
-{
- if (ret == -EINPROGRESS || ret == -EBUSY) {
- wait_for_completion(&tr->completion);
- reinit_completion(&tr->completion);
- ret = tr->err;
- }
- return ret;
-}
-
static int ahash_partial_update(struct ahash_request **preq,
struct crypto_ahash *tfm, const struct hash_testvec *template,
void *hash_buff, int k, int temp, struct scatterlist *sg,
- const char *algo, char *result, struct tcrypt_result *tresult)
+ const char *algo, char *result, struct crypto_wait *wait)
{
char *state;
struct ahash_request *req;
@@ -236,7 +210,7 @@ static int ahash_partial_update(struct ahash_request **preq,
}
ahash_request_set_callback(req,
CRYPTO_TFM_REQ_MAY_BACKLOG,
- tcrypt_complete, tresult);
+ crypto_req_done, wait);
memcpy(hash_buff, template->plaintext + temp,
template->tap[k]);
@@ -247,7 +221,7 @@ static int ahash_partial_update(struct ahash_request **preq,
pr_err("alg: hash: Failed to import() for %s\n", algo);
goto out;
}
- ret = wait_async_op(tresult, crypto_ahash_update(req));
+ ret = crypto_wait_req(crypto_ahash_update(req), wait);
if (ret)
goto out;
*preq = req;
@@ -272,7 +246,7 @@ static int __test_hash(struct crypto_ahash *tfm,
char *result;
char *key;
struct ahash_request *req;
- struct tcrypt_result tresult;
+ struct crypto_wait wait;
void *hash_buff;
char *xbuf[XBUFSIZE];
int ret = -ENOMEM;
@@ -286,7 +260,7 @@ static int __test_hash(struct crypto_ahash *tfm,
if (testmgr_alloc_buf(xbuf))
goto out_nobuf;
- init_completion(&tresult.completion);
+ crypto_init_wait(&wait);
req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!req) {
@@ -295,7 +269,7 @@ static int __test_hash(struct crypto_ahash *tfm,
goto out_noreq;
}
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- tcrypt_complete, &tresult);
+ crypto_req_done, &wait);
j = 0;
for (i = 0; i < tcount; i++) {
@@ -335,26 +309,26 @@ static int __test_hash(struct crypto_ahash *tfm,
ahash_request_set_crypt(req, sg, result, template[i].psize);
if (use_digest) {
- ret = wait_async_op(&tresult, crypto_ahash_digest(req));
+ ret = crypto_wait_req(crypto_ahash_digest(req), &wait);
if (ret) {
pr_err("alg: hash: digest failed on test %d "
"for %s: ret=%d\n", j, algo, -ret);
goto out;
}
} else {
- ret = wait_async_op(&tresult, crypto_ahash_init(req));
+ ret = crypto_wait_req(crypto_ahash_init(req), &wait);
if (ret) {
pr_err("alg: hash: init failed on test %d "
"for %s: ret=%d\n", j, algo, -ret);
goto out;
}
- ret = wait_async_op(&tresult, crypto_ahash_update(req));
+ ret = crypto_wait_req(crypto_ahash_update(req), &wait);
if (ret) {
pr_err("alg: has
[PATCH v6 08/19] crypto: move drbg to generic async completion
DRBG is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.
The code now also passes CRYPTO_TFM_REQ_MAY_SLEEP flag indicating
crypto request memory allocation may use GFP_KERNEL which should
be perfectly fine as the code is obviously sleeping for the
completion of the request any way.
Signed-off-by: Gilad Ben-Yossef
---
crypto/drbg.c | 36 +---
include/crypto/drbg.h | 3 +--
2 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 633a88e..c522251 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1651,16 +1651,6 @@ static int drbg_fini_sym_kernel(struct drbg_state *drbg)
return 0;
}
-static void drbg_skcipher_cb(struct crypto_async_request *req, int error)
-{
- struct drbg_state *drbg = req->data;
-
- if (error == -EINPROGRESS)
- return;
- drbg->ctr_async_err = error;
- complete(&drbg->ctr_completion);
-}
-
static int drbg_init_sym_kernel(struct drbg_state *drbg)
{
struct crypto_cipher *tfm;
@@ -1691,7 +1681,7 @@ static int drbg_init_sym_kernel(struct drbg_state *drbg)
return PTR_ERR(sk_tfm);
}
drbg->ctr_handle = sk_tfm;
- init_completion(&drbg->ctr_completion);
+ crypto_init_wait(&drbg->ctr_wait);
req = skcipher_request_alloc(sk_tfm, GFP_KERNEL);
if (!req) {
@@ -1700,8 +1690,9 @@ static int drbg_init_sym_kernel(struct drbg_state *drbg)
return -ENOMEM;
}
drbg->ctr_req = req;
- skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- drbg_skcipher_cb, drbg);
+ skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
+ CRYPTO_TFM_REQ_MAY_SLEEP,
+ crypto_req_done, &drbg->ctr_wait);
alignmask = crypto_skcipher_alignmask(sk_tfm);
drbg->ctr_null_value_buf = kzalloc(DRBG_CTR_NULL_LEN + alignmask,
@@ -1762,21 +1753,12 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
/* Output buffer may not be valid for SGL, use scratchpad */
skcipher_request_set_crypt(drbg->ctr_req, &sg_in, &sg_out,
cryptlen, drbg->V);
- ret = crypto_skcipher_encrypt(drbg->ctr_req);
- switch (ret) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- wait_for_completion(&drbg->ctr_completion);
- if (!drbg->ctr_async_err) {
- reinit_completion(&drbg->ctr_completion);
- break;
- }
- default:
+ ret = crypto_wait_req(crypto_skcipher_encrypt(drbg->ctr_req),
+ &drbg->ctr_wait);
+ if (ret)
goto out;
- }
- init_completion(&drbg->ctr_completion);
+
+ crypto_init_wait(&drbg->ctr_wait);
memcpy(outbuf, drbg->outscratchpad, cryptlen);
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 22f884c..8f94110 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -126,8 +126,7 @@ struct drbg_state {
__u8 *ctr_null_value; /* CTR mode aligned zero buf */
__u8 *outscratchpadbuf; /* CTR mode output scratchpad */
__u8 *outscratchpad; /* CTR mode aligned outbuf */
- struct completion ctr_completion; /* CTR mode async handler */
- int ctr_async_err; /* CTR mode async error */
+ struct crypto_wait ctr_wait;/* CTR mode async wait obj */
bool seeded;/* DRBG fully seeded? */
bool pr;/* Prediction resistance enabled? */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 07/19] crypto: move pub key to generic async completion
public_key_verify_signature() is starting an async crypto op and
waiting for it to complete. Move it over to generic code doing
the same.
Signed-off-by: Gilad Ben-Yossef
---
crypto/asymmetric_keys/public_key.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/crypto/asymmetric_keys/public_key.c
b/crypto/asymmetric_keys/public_key.c
index 3cd6e12..d916235 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -57,29 +57,13 @@ static void public_key_destroy(void *payload0, void
*payload3)
public_key_signature_free(payload3);
}
-struct public_key_completion {
- struct completion completion;
- int err;
-};
-
-static void public_key_verify_done(struct crypto_async_request *req, int err)
-{
- struct public_key_completion *compl = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- compl->err = err;
- complete(&compl->completion);
-}
-
/*
* Verify a signature using a public key.
*/
int public_key_verify_signature(const struct public_key *pkey,
const struct public_key_signature *sig)
{
- struct public_key_completion compl;
+ struct crypto_wait cwait;
struct crypto_akcipher *tfm;
struct akcipher_request *req;
struct scatterlist sig_sg, digest_sg;
@@ -131,20 +115,16 @@ int public_key_verify_signature(const struct public_key
*pkey,
sg_init_one(&digest_sg, output, outlen);
akcipher_request_set_crypt(req, &sig_sg, &digest_sg, sig->s_size,
outlen);
- init_completion(&compl.completion);
+ crypto_init_wait(&cwait);
akcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
CRYPTO_TFM_REQ_MAY_SLEEP,
- public_key_verify_done, &compl);
+ crypto_req_done, &cwait);
/* Perform the verification calculation. This doesn't actually do the
* verification, but rather calculates the hash expected by the
* signature and returns that to us.
*/
- ret = crypto_akcipher_verify(req);
- if ((ret == -EINPROGRESS) || (ret == -EBUSY)) {
- wait_for_completion(&compl.completion);
- ret = compl.err;
- }
+ ret = crypto_wait_req(crypto_akcipher_verify(req), &cwait);
if (ret < 0)
goto out_free_output;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 05/19] crypto: introduce crypto wait for async op
Invoking a possibly async. crypto op and waiting for completion
while correctly handling backlog processing is a common task
in the crypto API implementation and outside users of it.
This patch adds a generic implementation for doing so in
preparation for using it across the board instead of hand
rolled versions.
Signed-off-by: Gilad Ben-Yossef
CC: Eric Biggers
CC: Jonathan Cameron
---
crypto/api.c | 13 +
include/linux/crypto.h | 40
2 files changed, 53 insertions(+)
diff --git a/crypto/api.c b/crypto/api.c
index 941cd4c..2a2479d 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "internal.h"
LIST_HEAD(crypto_alg_list);
@@ -595,5 +596,17 @@ int crypto_has_alg(const char *name, u32 type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_has_alg);
+void crypto_req_done(struct crypto_async_request *req, int err)
+{
+ struct crypto_wait *wait = req->data;
+
+ if (err == -EINPROGRESS)
+ return;
+
+ wait->err = err;
+ complete(&wait->completion);
+}
+EXPORT_SYMBOL_GPL(crypto_req_done);
+
MODULE_DESCRIPTION("Cryptographic core API");
MODULE_LICENSE("GPL");
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 84da997..78508ca 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/*
* Autoloaded crypto modules should only use a prefixed name to avoid allowing
@@ -468,6 +469,45 @@ struct crypto_alg {
} CRYPTO_MINALIGN_ATTR;
/*
+ * A helper struct for waiting for completion of async crypto ops
+ */
+struct crypto_wait {
+ struct completion completion;
+ int err;
+};
+
+/*
+ * Macro for declaring a crypto op async wait object on stack
+ */
+#define DECLARE_CRYPTO_WAIT(_wait) \
+ struct crypto_wait _wait = { \
+ COMPLETION_INITIALIZER_ONSTACK((_wait).completion), 0 }
+
+/*
+ * Async ops completion helper functioons
+ */
+void crypto_req_done(struct crypto_async_request *req, int err);
+
+static inline int crypto_wait_req(int err, struct crypto_wait *wait)
+{
+ switch (err) {
+ case -EINPROGRESS:
+ case -EBUSY:
+ wait_for_completion(&wait->completion);
+ reinit_completion(&wait->completion);
+ err = wait->err;
+ break;
+ };
+
+ return err;
+}
+
+static inline void crypto_init_wait(struct crypto_wait *wait)
+{
+ init_completion(&wait->completion);
+}
+
+/*
* Algorithm registration interface.
*/
int crypto_register_alg(struct crypto_alg *alg);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 06/19] crypto: move algif to generic async completion
algif starts several async crypto ops and waits for their completion.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
crypto/af_alg.c | 27 ---
crypto/algif_aead.c | 8
crypto/algif_hash.c | 30 ++
crypto/algif_skcipher.c | 9 -
include/crypto/if_alg.h | 15 +--
5 files changed, 23 insertions(+), 66 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index d6936c0..f8917e7 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -481,33 +481,6 @@ int af_alg_cmsg_send(struct msghdr *msg, struct
af_alg_control *con)
}
EXPORT_SYMBOL_GPL(af_alg_cmsg_send);
-int af_alg_wait_for_completion(int err, struct af_alg_completion *completion)
-{
- switch (err) {
- case -EINPROGRESS:
- case -EBUSY:
- wait_for_completion(&completion->completion);
- reinit_completion(&completion->completion);
- err = completion->err;
- break;
- };
-
- return err;
-}
-EXPORT_SYMBOL_GPL(af_alg_wait_for_completion);
-
-void af_alg_complete(struct crypto_async_request *req, int err)
-{
- struct af_alg_completion *completion = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- completion->err = err;
- complete(&completion->completion);
-}
-EXPORT_SYMBOL_GPL(af_alg_complete);
-
/**
* af_alg_alloc_tsgl - allocate the TX SGL
*
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 48d46e7..abbac8a 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -278,11 +278,11 @@ static int _aead_recvmsg(struct socket *sock, struct
msghdr *msg,
/* Synchronous operation */
aead_request_set_callback(&areq->cra_u.aead_req,
CRYPTO_TFM_REQ_MAY_BACKLOG,
- af_alg_complete, &ctx->completion);
- err = af_alg_wait_for_completion(ctx->enc ?
+ crypto_req_done, &ctx->wait);
+ err = crypto_wait_req(ctx->enc ?
crypto_aead_encrypt(&areq->cra_u.aead_req) :
crypto_aead_decrypt(&areq->cra_u.aead_req),
-&ctx->completion);
+ &ctx->wait);
}
/* AIO operation in progress */
@@ -554,7 +554,7 @@ static int aead_accept_parent_nokey(void *private, struct
sock *sk)
ctx->merge = 0;
ctx->enc = 0;
ctx->aead_assoclen = 0;
- af_alg_init_completion(&ctx->completion);
+ crypto_init_wait(&ctx->wait);
ask->private = ctx;
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 3b3c154..d2ab8de 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -26,7 +26,7 @@ struct hash_ctx {
u8 *result;
- struct af_alg_completion completion;
+ struct crypto_wait wait;
unsigned int len;
bool more;
@@ -102,8 +102,7 @@ static int hash_sendmsg(struct socket *sock, struct msghdr
*msg,
if ((msg->msg_flags & MSG_MORE))
hash_free_result(sk, ctx);
- err = af_alg_wait_for_completion(crypto_ahash_init(&ctx->req),
- &ctx->completion);
+ err = crypto_wait_req(crypto_ahash_init(&ctx->req), &ctx->wait);
if (err)
goto unlock;
}
@@ -124,8 +123,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr
*msg,
ahash_request_set_crypt(&ctx->req, ctx->sgl.sg, NULL, len);
- err = af_alg_wait_for_completion(crypto_ahash_update(&ctx->req),
-&ctx->completion);
+ err = crypto_wait_req(crypto_ahash_update(&ctx->req),
+ &ctx->wait);
af_alg_free_sg(&ctx->sgl);
if (err)
goto unlock;
@@ -143,8 +142,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr
*msg,
goto unlock;
ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
- err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
-&ctx->completion);
+ err = crypto_wait_req(crypto_ahash_final(&ctx->req),
+ &ctx->wait);
}
unlock:
@@ -185,7 +184,7 @@ static ssize_t hash_sendpage(struct socket *sock, struct
page *page,
} else {
if (!ctx->more) {
err = crypto_ahash_init(&ctx->req);
- err = af_alg_wait_for_completion(err, &ctx->completion);
+ err = crypto_wait_req(err, &ctx->wait);
if (err)
[PATCH v6 04/19] crypto: marvell/cesa: remove redundant backlog checks on EBUSY
Now that -EBUSY return code only indicates backlog queueing we can safely remove the now redundant check for the CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned. Signed-off-by: Gilad Ben-Yossef Acked-by: Boris Brezillon --- drivers/crypto/marvell/cesa.c | 3 +-- drivers/crypto/marvell/cesa.h | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c index 6e7a5c7..269737f 100644 --- a/drivers/crypto/marvell/cesa.c +++ b/drivers/crypto/marvell/cesa.c @@ -183,8 +183,7 @@ int mv_cesa_queue_req(struct crypto_async_request *req, spin_lock_bh(&engine->lock); ret = crypto_enqueue_request(&engine->queue, req); if ((mv_cesa_req_get_type(creq) == CESA_DMA_REQ) && - (ret == -EINPROGRESS || - (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG))) + (ret == -EINPROGRESS || ret == -EBUSY) mv_cesa_tdma_chain(engine, creq); spin_unlock_bh(&engine->lock); diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h index b7872f6..63c8457 100644 --- a/drivers/crypto/marvell/cesa.h +++ b/drivers/crypto/marvell/cesa.h @@ -763,7 +763,7 @@ static inline int mv_cesa_req_needs_cleanup(struct crypto_async_request *req, * the backlog and will be processed later. There's no need to * clean it up. */ - if (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG) + if (ret == -EBUSY) return false; /* Request wasn't queued, we need to clean it up */ -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 02/19] crypto: ccp: use -EAGAIN for transient busy indication
Replace -EBUSY with -EAGAIN when reporting transient busy
indication in the absence of backlog.
Signed-off-by: Gilad Ben-Yossef
Reviewed-by: Gary R Hook
---
drivers/crypto/ccp/ccp-crypto-main.c | 8 +++-
drivers/crypto/ccp/ccp-dev.c | 7 +--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c
b/drivers/crypto/ccp/ccp-crypto-main.c
index 35a9de7..403ff0a 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -222,9 +222,10 @@ static int ccp_crypto_enqueue_cmd(struct ccp_crypto_cmd
*crypto_cmd)
/* Check if the cmd can/should be queued */
if (req_queue.cmd_count >= CCP_CRYPTO_MAX_QLEN) {
- ret = -EBUSY;
- if (!(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG))
+ if (!(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG)) {
+ ret = -EAGAIN;
goto e_lock;
+ }
}
/* Look for an entry with the same tfm. If there is a cmd
@@ -243,9 +244,6 @@ static int ccp_crypto_enqueue_cmd(struct ccp_crypto_cmd
*crypto_cmd)
ret = ccp_enqueue_cmd(crypto_cmd->cmd);
if (!ccp_crypto_success(ret))
goto e_lock;/* Error, don't queue it */
- if ((ret == -EBUSY) &&
- !(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG))
- goto e_lock;/* Not backlogging, don't queue it */
}
if (req_queue.cmd_count >= CCP_CRYPTO_MAX_QLEN) {
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 4e029b1..3d637e3 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -292,9 +292,12 @@ int ccp_enqueue_cmd(struct ccp_cmd *cmd)
i = ccp->cmd_q_count;
if (ccp->cmd_count >= MAX_CMD_QLEN) {
- ret = -EBUSY;
- if (cmd->flags & CCP_CMD_MAY_BACKLOG)
+ if (cmd->flags & CCP_CMD_MAY_BACKLOG) {
+ ret = -EBUSY;
list_add_tail(&cmd->entry, &ccp->backlog);
+ } else {
+ ret = -EAGAIN;
+ }
} else {
ret = -EINPROGRESS;
ccp->cmd_count++;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 03/19] crypto: remove redundant backlog checks on EBUSY
Now that -EBUSY return code only indicates backlog queueing we can safely remove the now redundant check for the CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned. Signed-off-by: Gilad Ben-Yossef --- crypto/ahash.c| 12 +++- crypto/cts.c | 6 ++ crypto/lrw.c | 8 ++-- crypto/rsa-pkcs1pad.c | 16 crypto/xts.c | 8 ++-- 5 files changed, 13 insertions(+), 37 deletions(-) diff --git a/crypto/ahash.c b/crypto/ahash.c index 826cd7a..d63eeef 100644 --- a/crypto/ahash.c +++ b/crypto/ahash.c @@ -334,9 +334,7 @@ static int ahash_op_unaligned(struct ahash_request *req, return err; err = op(req); - if (err == -EINPROGRESS || - (err == -EBUSY && (ahash_request_flags(req) & - CRYPTO_TFM_REQ_MAY_BACKLOG))) + if (err == -EINPROGRESS || err == -EBUSY) return err; ahash_restore_req(req, err); @@ -394,9 +392,7 @@ static int ahash_def_finup_finish1(struct ahash_request *req, int err) req->base.complete = ahash_def_finup_done2; err = crypto_ahash_reqtfm(req)->final(req); - if (err == -EINPROGRESS || - (err == -EBUSY && (ahash_request_flags(req) & - CRYPTO_TFM_REQ_MAY_BACKLOG))) + if (err == -EINPROGRESS || err == -EBUSY) return err; out: @@ -432,9 +428,7 @@ static int ahash_def_finup(struct ahash_request *req) return err; err = tfm->update(req); - if (err == -EINPROGRESS || - (err == -EBUSY && (ahash_request_flags(req) & - CRYPTO_TFM_REQ_MAY_BACKLOG))) + if (err == -EINPROGRESS || err == -EBUSY) return err; return ahash_def_finup_finish1(req, err); diff --git a/crypto/cts.c b/crypto/cts.c index 243f591..4773c18 100644 --- a/crypto/cts.c +++ b/crypto/cts.c @@ -136,8 +136,7 @@ static void crypto_cts_encrypt_done(struct crypto_async_request *areq, int err) goto out; err = cts_cbc_encrypt(req); - if (err == -EINPROGRESS || - (err == -EBUSY && req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) + if (err == -EINPROGRESS || err == -EBUSY) return; out: @@ -229,8 +228,7 @@ static void crypto_cts_decrypt_done(struct crypto_async_request *areq, int err) goto out; err = cts_cbc_decrypt(req); - if (err == -EINPROGRESS || - (err == -EBUSY && req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) + if (err == -EINPROGRESS || err == -EBUSY) return; out: diff --git a/crypto/lrw.c b/crypto/lrw.c index a8bfae4..695cea9 100644 --- a/crypto/lrw.c +++ b/crypto/lrw.c @@ -328,9 +328,7 @@ static int do_encrypt(struct skcipher_request *req, int err) crypto_skcipher_encrypt(subreq) ?: post_crypt(req); - if (err == -EINPROGRESS || - (err == -EBUSY && -req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) + if (err == -EINPROGRESS || err == -EBUSY) return err; } @@ -380,9 +378,7 @@ static int do_decrypt(struct skcipher_request *req, int err) crypto_skcipher_decrypt(subreq) ?: post_crypt(req); - if (err == -EINPROGRESS || - (err == -EBUSY && -req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) + if (err == -EINPROGRESS || err == -EBUSY) return err; } diff --git a/crypto/rsa-pkcs1pad.c b/crypto/rsa-pkcs1pad.c index 407c64b..2908f93 100644 --- a/crypto/rsa-pkcs1pad.c +++ b/crypto/rsa-pkcs1pad.c @@ -279,9 +279,7 @@ static int pkcs1pad_encrypt(struct akcipher_request *req) req->dst, ctx->key_size - 1, req->dst_len); err = crypto_akcipher_encrypt(&req_ctx->child_req); - if (err != -EINPROGRESS && - (err != -EBUSY || -!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))) + if (err != -EINPROGRESS && err != -EBUSY) return pkcs1pad_encrypt_sign_complete(req, err); return err; @@ -383,9 +381,7 @@ static int pkcs1pad_decrypt(struct akcipher_request *req) ctx->key_size); err = crypto_akcipher_decrypt(&req_ctx->child_req); - if (err != -EINPROGRESS && - (err != -EBUSY || -!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))) + if (err != -EINPROGRESS && err != -EBUSY) return pkcs1pad_decrypt_complete(req, err); return err; @@ -440,9 +436,7 @@ static int pkcs1pad_sign(struct akcipher_request *req) req->dst, ctx->key_size - 1, req->dst_len); err = crypto_akcipher_sign(&req_ctx->child_req); - if (err != -EI
Re: [RFC PATCH 3/3] kbuild: generate *.tab.c and *.tab.h during build
On Sat, Aug 19, 2017 at 3:49 AM, Masahiro Yamada wrote: > *.tab.[ch] files are artifacts generated from *.y by using bison. > Instead of running bison, we conventionally version-control > *.tab.[ch]_shipped files and copy them to *.tab.[ch] during build. > > It is true that this approach can minimize external tool dependency, > but we need to update the shipped files from time to time. This > commit switches to build-time generation of the intermediate C files. When do we need to update them? > > Signed-off-by: Masahiro Yamada > --- > > Documentation/process/changes.rst| 12 + > scripts/Makefile.lib | 14 +- > scripts/dtc/Makefile |9 +- > scripts/dtc/dtc-parser.tab.c_shipped | 2303 --- > scripts/dtc/dtc-parser.tab.h_shipped | 125 -- The script to import dtc normally creates these. If you change this, please make sure the script still works. > scripts/genksyms/Makefile|5 +- > scripts/genksyms/parse.tab.c_shipped | 2394 > scripts/genksyms/parse.tab.h_shipped | 119 -- > scripts/kconfig/Makefile |2 +- > scripts/kconfig/zconf.tab.c_shipped | 2471 > -- > 10 files changed, 24 insertions(+), 7430 deletions(-) > delete mode 100644 scripts/dtc/dtc-parser.tab.c_shipped > delete mode 100644 scripts/dtc/dtc-parser.tab.h_shipped > delete mode 100644 scripts/genksyms/parse.tab.c_shipped > delete mode 100644 scripts/genksyms/parse.tab.h_shipped > delete mode 100644 scripts/kconfig/zconf.tab.c_shipped > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] dt-bindings: i2c: Document the POWER system power supply device
On 08/17/2017 10:11 AM, Rob Herring wrote:
On Thu, Aug 10, 2017 at 05:19:44PM -0500, Eddie James wrote:
From: "Edward A. James"
Signed-off-by: Edward A. James
---
.../devicetree/bindings/i2c/ibm,power-ps.txt| 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/ibm,power-ps.txt
diff --git a/Documentation/devicetree/bindings/i2c/ibm,power-ps.txt
b/Documentation/devicetree/bindings/i2c/ibm,power-ps.txt
new file mode 100644
index 000..2ea8ea2
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ibm,power-ps.txt
@@ -0,0 +1,21 @@
+Device-tree bindings for IBM POWER system power supplies
+
+
+Required properties:
+ - compatible = "ibm,power-ps";
+ - reg = < I2C bus address >;: Address of the power supply on the
+ I2C bus.
+
+Example:
+
+i2c-bus@100 {
+#address-cells = <1>;
+#size-cells = <0>;
+#interrupt-cells = <1>;
+< more properties >
+
+power_ps@68 {
Don't use '_' in node names. Should be a generic name too if possible.
Perhaps "power-supply".
Yes, the latest patch set switched this to power-supply. The driver name
changed in v3, sorry for the confusion.
Thanks,
Eddie
+compatible = "ibm,power-ps";
+reg = <0x68>;
+};
+};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Mon, Aug 21, 2017 at 09:44:11PM +0800, Anand Jain wrote: > > > > +fscrypt is not guaranteed to protect confidentiality or authenticity > > +if an attacker is able to manipulate the filesystem offline prior to > > +an authorized user later accessing the filesystem. > > How does fscrypt / Android protect against Evil Maid attack. ? In order to answer that question it's important to be specific about threat model is like; exactly what powers does the Evil Maid actually have? One of the stronger form of the Evil Maid attack posits that the Evil Made can remove the device from your hotel room, modify the hardware undetectably (up to and including desoldering the flash chip so it can be read and write directly), then replace it back to your hotel room, wait for you to login, and then later on, steal your phone and desolder the flash chip again. This sort of attack is going to require a combination of hardware and software features. Without talking about future product features on any specific future device being shipped by Google or any other company --- theoretically, if the keys are stored a hardware device which only disgorges the keys sends them directly to the in-line crypto engine without letting the keys be visible to the Linux kernel (or the Host CPU in any way at all), then it makes these sorts of Evil Maid much more difficult. Of course, if the Evil Maid can somehow insert something to tap the communications channel between the key storage device and the inline-crypto engine, then all bets are off. Presumably, though, this could be made harder; for example, by putting them on the system-on-a-chip. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Sat, Aug 19, 2017 at 10:32:27PM -0400, Theodore Ts'o wrote: > On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote: > > On Aug 18, 2017, at 1:47 PM, Eric Biggers wrote: > > > +Key hierarchy > > > += > > > + > > > +Master Keys > > > +--- > > > + > > > +Userspace should generate master keys either using a cryptographically > > > +secure random number generator, e.g. by reading from ``/dev/urandom`` > > > +or calling getrandom(), or by using a KDF (Key Derivation Function). > > > +Note that whenever a KDF is used to "stretch" a lower-entropy secret > > > +such as a passphrase, it is critical that a KDF designed for this > > > +purpose be used, such as scrypt, PBKDF2, or Argon2. > > > > One minor suggestion - when generating a master key for a filesystem, > > I'd think it is preferable to use /dev/random instead of /dev/urandom > > to ensure there is enough entropy. > > I would just say "use getrandom" and be done with it. More > importantly, we probably just want to direct users to use either > https://github.com/google/fscrypt or Android key management system at > the beginning of the file. > > If the readers of this documentation file need to be told how to get > good random number generators, they're very likely to make any number > of other basic security mistakes. If people don't think the fscrypt > user program isn't user-friendly or flexible enough to encompass their > use case, it's probably better to encourage them to submit > enhancements to an existing open source key management system such as > google/fscrypt. If we minimize the number of userspace > implementations, the easier it will be to make sure they are > appropriately audited for security issues... > Yes, the intent wasn't really to start a debate about /dev/random vs. /dev/urandom vs. getrandom(). I'll probably just remove the text "e.g. by reading from /dev/urandom or calling getrandom()". I agree that we should recommend the 'fscrypt' userspace tool more strongly as well. I did mention it at the beginning of the document, but I didn't explicitly say something like "use this instead of writing your own tool". Either way, the kernel API should still be fully documented. And part of that is documenting that the master key needs to be a good pseudorandom key. Otherwise I could imagine someone mistakenly thinking that the filesystem does key stretching for them, for example. (Yes, that person probably wouldn't read the documentation and would screw up anyway, but we might as well try.) Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Mon, Aug 21, 2017 at 09:44:11PM +0800, Anand Jain wrote: > > > >+fscrypt is not guaranteed to protect confidentiality or authenticity > >+if an attacker is able to manipulate the filesystem offline prior to > >+an authorized user later accessing the filesystem. > > How does fscrypt / Android protect against Evil Maid attack. ? > > Thanks, Anand As Ted mentioned, it really depends on the type of attack. If we assume that the attacker can *only* change the contents of disk, then there is a protection against a specific type of attack. Android has Verified Boot, which verifies the integrity and authenticity of the kernel and the 'system' partition: https://source.android.com/security/verifiedboot/ >From there, the vold binary (which has been authenticated using dm-verity) is able to unwrap the encryption keys (which are authenticated using AES-GCM), then check that the encrypted directories have the correct encryption policies. The filesystem then enforces the one-policy-per-tree constraint, as described in my proposed documentation: Except for those special files, it is forbidden to have unencrypted files, or files encrypted with a different encryption policy, in an encrypted directory tree. Attempts to link or rename such a file into an encrypted directory will fail with EPERM. This is also enforced during ->lookup() to provide limited protection against offline attacks that try to disable or downgrade encryption in known locations where applications may later write sensitive data. So on Android, an "Evil Maid" attacker cannot simply replace an encrypted directory with an unencrypted one, causing a program to write unencrypted files to that directory. _However_, an "Evil Maid" attacker can probably still do other, perhaps much more effective attacks --- e.g. installing a hardware "key logger", or perhaps installing a binary into /data in such a way that it gets auto-executed and compromises the system after the user logs in. Or they could attack the actual file contents encryption which is not authenticated. Or they could mess around with filesystem metadata on the userdata partition, which is neither encrypted nor authenticated. I suppose that dm-integrity could be used to protect against some of those attacks, but of course it would not protect against hardware key loggers, etc. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
+fscrypt is not guaranteed to protect confidentiality or authenticity +if an attacker is able to manipulate the filesystem offline prior to +an authorized user later accessing the filesystem. How does fscrypt / Android protect against Evil Maid attack. ? _However_, an "Evil Maid" attacker can probably still do other, perhaps much more effective attacks --- e.g. :: . Or they could attack the actual file contents encryption which is not authenticated. Or they could mess around with filesystem metadata on the userdata partition, which is neither encrypted nor authenticated. In specific, the scenario I had in mind was the above threat. I suppose that dm-integrity could be used to protect against some of those attacks, but of course it would not protect against hardware key loggers, etc. OK. I think AE is the only good solution for this, File-name encryption at this stage won't solve any kind of Evil Maid attack, (as it was quoted somewhere else in ML). Further, below, is define but not used. - #define FS_AES_256_GCM_KEY_SIZE32 - Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
Hi Eric, How about a section on the threat model specific to the file-name ? (Sorry if I am missing something). Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote: > > Hi Eric, > > How about a section on the threat model specific to the file-name ? > > (Sorry if I am missing something). > > Thanks, Anand It's already mentioned that filenames are encrypted: "fscrypt protects the confidentiality of file contents and filenames in the event of a single point-in-time permanent offline compromise of the block device content." There's not much more to it than that; all the other points in the "Threat model" section (offline manipulations, timing attacks, access control, key eviction, etc.) are essentially the same between contents and filenames encryption. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
> -Original Message- > From: Waiman Long [mailto:long...@redhat.com] > Sent: Monday, August 21, 2017 9:35 PM > To: Wangkai (Kevin,C); Alexander Viro; Jonathan Corbet > Cc: linux-ker...@vger.kernel.org; linux-doc@vger.kernel.org; > linux-fsde...@vger.kernel.org; Paul E. McKenney; Andrew Morton; Ingo Molnar; > Miklos Szeredi; Matthew Wilcox; Larry Woodman; James Bottomley > Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries > > On 08/20/2017 11:23 PM, Wangkai (Kevin,C) wrote: > > > > Yes, I have add some trace info for the dentry state changed, with dentry > > flag > and reference count: > > > > File create: > > [ 42.636675] dentry [_1234] 0x880230be8180 flag 0x0 ref 1 ev > dentry alloc > > File close: > > [ 42.637421] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref 0 > ev dput called > > > > Unlink lookup: > > [ 244.658086] dentry [_1234] 0x880230be8180 flag 0x4800c0 ref > > 1 ev d_lookup Unlink d_delete: > > [ 244.658254] dentry [_1234] 0x880230be8180 flag 0x800c0 ref > > 1 ev d_lockref ref 1 Unlink dput: > > [ 244.658438] dentry [_1234] 0x880230be8180 flag 0x800c0 ref > > 0 ev dput called > > > > The end, dentry's flag stay at 0x800c0, but this dentry was not freed, > > keeped by the dcache as unused, After tens of thousands of the > > dentries slow down the dentry lookup performance, kernel memory usage > Keep high. > > > > Regards, > > Kevin > > That is expected. The kernel does not get rid of negative dentries until the > shrinker is called because of memory pressure. Negative dentries do help to > improve file lookup performance. However, too much of negative dentries > suppress the amount of free memory available for other use. > That is why I send out my patch to limit the number of negative dentries > outstanding. > I think there are two issue: 1. when a file was removed, the dentry should be deleted, this is as a bug, if the Dentry memory cannot be reclaimed, there is a memory leak. 2. limit the dentries number can improve when there were lots of files operations, And all the files were valid. Regards, Kevin
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Tue, Aug 22, 2017 at 10:22:13AM +0800, Anand Jain wrote: > > > > > > > +fscrypt is not guaranteed to protect confidentiality or authenticity > > > > +if an attacker is able to manipulate the filesystem offline prior to > > > > +an authorized user later accessing the filesystem. > > > > > > How does fscrypt / Android protect against Evil Maid attack. ? > > > _However_, an "Evil Maid" attacker can probably still do other, perhaps much > > more effective attacks --- e.g. > :: > > . Or they could attack the actual > > file contents encryption which is not authenticated. Or they could mess > > around > > with filesystem metadata on the userdata partition, which is neither > > encrypted > > nor authenticated. > > In specific, the scenario I had in mind was the above threat. > > > I suppose that dm-integrity could be used to protect against some of those > > attacks, but of course it would not protect against hardware key loggers, > > etc. > > OK. > > > I think AE is the only good solution for this, File-name encryption at > this stage won't solve any kind of Evil Maid attack, (as it was quoted > somewhere else in ML). > > > Further, below, is define but not used. > - > #define FS_AES_256_GCM_KEY_SIZE 32 > - > Yes, authenticated encryption with AES-256-GCM was in an older version of the ext4 encryption design document. But unfortunately it was never really thought through. The primary problem, even ignoring rollback protection, is that there is nowhere to store the per-block metadata (GCM authentication tag and IV) *and* have it updated atomicly with the block contents. Recently, dm-integrity solves this at the block device layer, but it uses data journaling which is very inefficient. This maybe could be implemented more efficiently on a COW filesystem like BTRFS. But even after that, another problem is that authenticated encryption of file contents only would not stop an attacker from swapping around blocks, files, directories, or creating links, etc. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Tue, Aug 22, 2017 at 10:22:13AM +0800, Anand Jain wrote: > > I think AE is the only good solution for this, File-name encryption at > this stage won't solve any kind of Evil Maid attack, (as it was quoted > somewhere else in ML). AE doesn't help at all against the Evil Maid attack, since the Evil Maid is trying get the user's keying material, and what kind of encryption you are using is pretty much irrelevant. The typical attack (where the user's keys are available to the host CPU) involves compromising the system software --- and system software is public (everyone can get a copy of the Android system image for a particular device), so encryption is pointless. That's why the system image is protected using dm-verity, which provides data integrity, but not confidentiality. The bootloader will protect against installing a new system image unless you have the private key of the handset manufacturer to sign said system image. But the Evil Maid can carry out a "chip off" attack, where flash chip is desoldered and the system image, and the dm-verity information can be written directly without the bootloader being able to prevent it. This is why using AE isn't going to help you. Sure, the Evil Maid could try to diddle directories and use complicated crypto attacks. But why bother when they can just simply steal the user's keys, at which point all the AE in the world doesn't help a whit. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: sunxi: add support for R40 SoC
在 2017-08-21 17:34，Maxime Ripard 写道：
Hi,
On Sun, Aug 20, 2017 at 01:29:57PM +0800, Icenowy Zheng wrote:
Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Documentation/arm/sunxi/README | 6 ++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/arm/sunxi/README
b/Documentation/arm/sunxi/README
index d7b1f016bd62..4fa836782e46 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -75,6 +75,12 @@ SunXi family
+ Datasheet
http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
+ - Allwinner R40 (sun8i)
++ Datasheet
+
https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf
++ User Manual
+
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf
+
Please sort it by alphabetical order.
I prefer to sort it by the wafer ID (the number after w in the official
ID).
The current document can be explained to follow the alphabetical order
or the wafer ID.
P.S. there's some error in the V3s datasheet position, and if it's fixed
we can still continue to make the two kinds of order both meaningful ;-)
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Datasheet
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
b/Documentation/devicetree/bindings/arm/sunxi.txt
index f35c6ada5a65..e4beec3d9ad3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
allwinner,sun8i-a83t
allwinner,sun8i-h2-plus
allwinner,sun8i-h3
+ allwinner-sun8i-r40
allwinner,sun8i-v3s
allwinner,sun9i-a80
allwinner,sun50i-a64
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 7ab353fb25f2..311e6c4fc4f4 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] =
{
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-v3s",
+ "allwinner,sun8i-r40",
And same thing here.
Thanks!
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] dt-bindings: add compatible string for Allwinner V3s SoC
The compatible string for Allwinner V3s SoC used to be missing.
Add it to the binding document.
Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
b/Documentation/devicetree/bindings/arm/sunxi.txt
index d2c46449b4eb..f35c6ada5a65 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
allwinner,sun8i-a83t
allwinner,sun8i-h2-plus
allwinner,sun8i-h3
+ allwinner,sun8i-v3s
allwinner,sun9i-a80
allwinner,sun50i-a64
nextthing,gr8
--
2.13.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: sunxi: fix the core number of V3s in sunxi README
The Allwinner V3s SoC is not quad-core, but single-core.
Fix this in the README file.
Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng
---
Documentation/arm/sunxi/README | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index d7b1f016bd62..de791e18ccef 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -33,6 +33,11 @@ SunXi family
- Next Thing Co GR8 (sun5i)
+* Single ARM Cortex-A7 based SoCs
+ - Allwinner V3s (sun8i)
++ Datasheet
+ http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
+
* Dual ARM Cortex-A7 based SoCs
- Allwinner A20 (sun7i)
+ User Manual
@@ -71,10 +76,6 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
- - Allwinner V3s (sun8i)
-+ Datasheet
- http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
-
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Datasheet
--
2.13.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: sunxi: add support for R40 SoC
Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Fix alphabetical orders.
Documentation/arm/sunxi/README | 6 ++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index de791e18ccef..f8efc21998bf 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -76,6 +76,12 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
+ - Allwinner R40 (sun8i)
++ Datasheet
+ https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf
++ User Manual
+
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf
+
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Datasheet
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
b/Documentation/devicetree/bindings/arm/sunxi.txt
index f35c6ada5a65..e4beec3d9ad3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
allwinner,sun8i-a83t
allwinner,sun8i-h2-plus
allwinner,sun8i-h3
+ allwinner-sun8i-r40
allwinner,sun8i-v3s
allwinner,sun9i-a80
allwinner,sun50i-a64
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 7ab353fb25f2..5e9602ce1573 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -65,6 +65,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a83t",
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
+ "allwinner,sun8i-r40",
"allwinner,sun8i-v3s",
NULL,
};
--
2.13.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
