On Thu, May 30, 2019 at 09:05:53PM +0800, kbuild test robot wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> master
> head: 0adb0c99594b73844cf9a5714faa6553ea04ba04
> commit: c34a320176a59445d76783e5ee043d6ecd22d011 [56/59] crypto: atmel-ecc -
> fa
On Fri, May 31, 2019 at 06:10:51AM +, Horia Geanta wrote:
>
> Driver is not touching the DMA mapped areas, the DMA API conventions are
> carefully followed.
> It's touching a virtual pointer that is not DMA mapped, that just happens to
> be
> on the same cache line with a DMA mapped buffer.
W
On 5/31/2019 8:43 AM, Herbert Xu wrote:
> On Fri, May 31, 2019 at 05:22:50AM +, Horia Geanta wrote:
>>
>> Unless it's clearly defined *which* virtual addresses mustn't be accessed,
>> things won't work properly.
>> In theory, any two objects could share a cache line. We can't just stop all
>> m
On 5/30/2019 4:26 PM, Ard Biesheuvel wrote:
> On Thu, 30 May 2019 at 15:18, Horia Geanta wrote:
>>
>> On 5/30/2019 11:08 AM, Ard Biesheuvel wrote:
>>> On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
On 5/30/2019 8:34 AM, Herbert Xu wrote:
> It would appear that Ard's latest sugges
On 5/31/2019 1:00 AM, Iuliana Prodan wrote:
> On 5/30/2019 6:05 PM, Ard Biesheuvel wrote:
>> On Thu, 30 May 2019 at 16:34, Herbert Xu wrote:
>>>
>>> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
This might work:
>>>
>>> Looks good to me.
>>>
>>
>> Thanks Herbert,
>>
>>
On Fri, May 31, 2019 at 05:22:50AM +, Horia Geanta wrote:
>
> Unless it's clearly defined *which* virtual addresses mustn't be accessed,
> things won't work properly.
> In theory, any two objects could share a cache line. We can't just stop all
> memory accesses from CPU while a peripheral is b
On 5/30/2019 4:26 PM, Herbert Xu wrote:
> On Thu, May 30, 2019 at 01:18:34PM +, Horia Geanta wrote:
>>
>> I guess there are only two options:
>> -either cache line sharing is avoided OR
>> -users need to be *aware* they are sharing the cache line and some rules /
>> assumptions are in place on
Hi, Neal
On Mon, May 27, 2019 at 1:39 AM Neal Liu wrote:
>
> For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> entropy sources is not accessible from normal world (linux) and
> rather accessible from secure world (ATF/TEE) only. This driver aims
> to provide a generic interfac
Hi, Neal
On Mon, May 27, 2019 at 1:39 AM Neal Liu wrote:
>
> Document the binding used by the MediaTek ARMv8 SoCs random
> number generator with TrustZone enabled.
>
> Signed-off-by: Neal Liu
> ---
> Documentation/devicetree/bindings/rng/mtk-rng.txt | 13 ++---
> 1 file changed, 10 in
Hi Neal,
On Mon, May 27, 2019 at 1:39 AM Neal Liu wrote:
>
> 1. Add a header file to provide SIP interface to ARM Trusted
> Firmware(ATF)
> 2. Add hwrng SMC fid
>
> Signed-off-by: Neal Liu
> ---
> include/linux/soc/mediatek/mtk_sip_svc.h | 51
> ++
> 1 file change
On 5/30/2019 6:05 PM, Ard Biesheuvel wrote:
> On Thu, 30 May 2019 at 16:34, Herbert Xu wrote:
>>
>> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
>>>
>>> This might work:
>>
>> Looks good to me.
>>
>
> Thanks Herbert,
>
> But given your remark regarding CBC being the only algo
Lieber Freund,
Ich bin Herr Richard Wahl der Mega-Gewinner von $ 533M In Mega Millions Jackpot
spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde
Ihre E-Mail nach einem Spinball ausgewählt. Ich habe den größten Teil meines
Vermögens auf eine Reihe von Wohltätigkeitso
From: Eric Biggers
Commit c778f96bf347 ("crypto: lrw - Optimize tweak computation")
incorrectly reduced the alignmask of LRW instances from
'__alignof__(u64) - 1' to '__alignof__(__be32) - 1'.
However, xor_tweak() and setkey() assume that the data and key,
respectively, are aligned to 'be128', w
From: Eric Biggers
Changing ghash_mod_init() to be subsys_initcall made it start running
before the alignment fault handler has been installed on ARM. In kernel
builds where the keys in the ghash test vectors happened to be
misaligned in the kernel image, this exposed the longstanding bug that
g
On Thu, May 30, 2019 at 10:47:18AM +0100, Robin Murphy wrote:
> On 2019-05-30 10:12 am, Peter Robinson wrote:
> > Hi Eric,
> >
> > I'm seeing the crash below on ARMv7 devices, at least the Raspberry Pi
> > and UDoo Neo (i.MX6SX), with your "crypto: run initcalls for generic
> > implementations ear
On Thu, May 30, 2019 at 09:52:57AM +0300, Nikolay Borisov wrote:
> xxhash is currently implemented as a self-contained module in /lib.
> This patch enables that module to be used as part of the generic kernel
> crypto framework. It adds a simple wrapper to the 64bit version.
>
> I've also added te
On Thu, 30 May 2019 at 17:13, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 05:10:06PM +0200, Ard Biesheuvel wrote:
> >
> > Are there any generic templates relying on this for other algos than CBC?
>
> algif_skcipher relies on this.
>
I see.
In any case, that one line patch would still make thin
On Thu, May 30, 2019 at 05:10:06PM +0200, Ard Biesheuvel wrote:
>
> Are there any generic templates relying on this for other algos than CBC?
algif_skcipher relies on this.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/
On Thu, 30 May 2019 at 16:53, Pascal Van Leeuwen
wrote:
>
> >
> > This might work:
> >
> > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> > index c0ece44f303b..3d313d2a279a 100644
> > --- a/drivers/crypto/caam/caamalg.c
> > +++ b/drivers/crypto/caam/caamalg.c
> > @@ -
On Thu, 30 May 2019 at 17:06, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 05:04:51PM +0200, Ard Biesheuvel wrote:
> >
> > But given your remark regarding CBC being the only algo that has this
> > requirement, I wonder if this might be sufficient as well.
>
> It's not that CBC is the only one wit
On Thu, May 30, 2019 at 05:04:51PM +0200, Ard Biesheuvel wrote:
>
> But given your remark regarding CBC being the only algo that has this
> requirement, I wonder if this might be sufficient as well.
It's not that CBC is the only one with the requirement. It's just
that this is the wrong output IV
On Thu, 30 May 2019 at 16:34, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
> >
> > This might work:
>
> Looks good to me.
>
Thanks Herbert,
But given your remark regarding CBC being the only algo that has this
requirement, I wonder if this might be suffic
Dear Sir/ Madam,
Please forgive me if my request is not acceptable by your kind person.
I am Mr. Nor Hizam Hashim, Working at MAYBANK (Malaysia) as the Independent
Non-Executive Director & Audit Committee. During our last banking Audits we
discovered an abandoned account belongs to one of our F
>
> This might work:
>
> diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> index c0ece44f303b..3d313d2a279a 100644
> --- a/drivers/crypto/caam/caamalg.c
> +++ b/drivers/crypto/caam/caamalg.c
> @@ -1661,7 +1661,8 @@ static int aead_decrypt(struct aead_request *req)
> *
On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
>
> This might work:
Looks good to me.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, 30 May 2019 at 16:28, Ard Biesheuvel wrote:
>
> On Thu, 30 May 2019 at 16:27, Herbert Xu wrote:
> >
> > On Thu, May 30, 2019 at 03:55:07PM +0200, Ard Biesheuvel wrote:
> > >
> > > > Would this work?
> >
> > I see. You need to preserve the original IV.
> >
> > > > diff --git a/drivers/cry
> On Thu, 30 May 2019 at 15:58, Herbert Xu
> wrote:
> >
> > On Thu, May 30, 2019 at 01:45:47PM +, Iuliana Prodan wrote:
> > >
> > > On the current structure of caamalg, to work, iv needs to be copied
> > > before memcpy(iv, req->iv, ivsize), from skcipher_edesc_alloc
> function.
> > > For this
On Thu, 30 May 2019 at 16:27, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 03:55:07PM +0200, Ard Biesheuvel wrote:
> >
> > > Would this work?
>
> I see. You need to preserve the original IV.
>
> > > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> > > index c0ece44f30
On Thu, May 30, 2019 at 03:55:07PM +0200, Ard Biesheuvel wrote:
>
> > Would this work?
I see. You need to preserve the original IV.
> > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> > index c0ece44f303b..2ef2f76a3cb8 100644
> > --- a/drivers/crypto/caam/caamalg.c
>
On Thu, 30 May 2019 at 15:58, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 01:45:47PM +, Iuliana Prodan wrote:
> >
> > On the current structure of caamalg, to work, iv needs to be copied
> > before memcpy(iv, req->iv, ivsize), from skcipher_edesc_alloc function.
> > For this we need edesc, bu
On Thu, May 30, 2019 at 01:45:47PM +, Iuliana Prodan wrote:
>
> On the current structure of caamalg, to work, iv needs to be copied
> before memcpy(iv, req->iv, ivsize), from skcipher_edesc_alloc function.
> For this we need edesc, but this cannot be allocated before knowing how
> much memor
On Thu, 30 May 2019 at 15:53, Ard Biesheuvel wrote:
>
> On Thu, 30 May 2019 at 15:45, Iuliana Prodan wrote:
> >
> > On 5/30/2019 4:34 PM, Herbert Xu wrote:
> > > On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
> > >>
> > >> I've tried coping the IV before the extended descriptor a
On Thu, 30 May 2019 at 15:45, Iuliana Prodan wrote:
>
> On 5/30/2019 4:34 PM, Herbert Xu wrote:
> > On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
> >>
> >> I've tried coping the IV before the extended descriptor allocation, but
> >> is not working and to make it work will need to
On 5/30/2019 4:34 PM, Herbert Xu wrote:
> On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
>>
>> I've tried coping the IV before the extended descriptor allocation, but
>> is not working and to make it work will need to make more changes in
>> CAAM. We need the original iv, and if we
On Fri, May 24, 2019 at 06:26:45PM +0200, Ard Biesheuvel wrote:
> The Socionext SynQuacer based 96boards DeveloperBox platform does not
> incorporate a random number generator, but it does have a 96boards low
> speed connector which supports extension boards such as the Secure96,
> which has a TPM
On Thu, May 23, 2019 at 10:50:27AM +0200, Sascha Hauer wrote:
> Since eaed71a44ad9 ("crypto: caam - add ecb(*) support") the IV can be
> NULL, so only dump it when it's non NULL as designated by the ivsize
> variable.
>
> Fixes: eaed71a44ad9 ("crypto: caam - add ecb(*) support")
> Signed-off-by: S
On Tue, May 21, 2019 at 11:46:22AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> "jitterentropy_rng" doesn't have any other implementations, nor is it
> tested by the crypto self-tests. So it was unnecessary to change it to
> subsys_initcall. Also it depends on the main clocksource being
On Wed, May 22, 2019 at 12:42:29PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> When I added the sanity check of 'descsize', I missed that the child
> hash tfm needs to be freed if the sanity check fails. Of course this
> should never happen, hence the use of WARN_ON(), but it should be f
On Tue, May 21, 2019 at 01:34:06PM +, Christophe Leroy wrote:
> Several test failures have popped up following recent changes to crypto
> selftests.
>
> This series fixes (most of) them.
>
> The last three patches are trivial cleanups.
>
> Christophe Leroy (15):
> crypto: talitos - fix skc
On Mon, May 20, 2019 at 09:42:32AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove the boilerplate license text and replace it with the equivalent
> SPDX license identifier.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/vmx/aes.c | 14 +-
> drivers/crypto/vm
On Mon, May 20, 2019 at 09:44:48AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Convert the VMX implementations of AES-CBC, AES-CTR, and AES-XTS from
> the deprecated "blkcipher" API to the "skcipher" API.
>
> As part of this, I moved the skcipher_request for the fallback algorithm
> off
On Mon, May 20, 2019 at 09:53:43AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There's no reason for users to select CONFIG_CRYPTO_GF128MUL, since it's
> just some helper functions, and algorithms that need it select it.
>
> Remove the prompt string so that it's not shown to users.
>
>
On Mon, May 20, 2019 at 09:55:15AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove the crypto_tfm_in_queue() function, which is unused.
>
> Signed-off-by: Eric Biggers
> ---
> crypto/algapi.c| 13 -
> include/crypto/algapi.h| 7 ---
> include
On Mon, May 20, 2019 at 09:48:29AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The crypto self-tests are part of the "cryptomgr" module, which can
> technically be disabled (though it rarely is). If you do so, currently
> you can still enable CRYPTO_MANAGER_EXTRA_TESTS, which doesn't mak
On Mon, May 20, 2019 at 09:47:19AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> On PowerPC with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, there is sometimes
> a crash in generate_random_aead_testvec(). The problem is that the
> generated test vectors use data lengths of up to about 2 * PAGE_SI
On Mon, May 20, 2019 at 09:54:46AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove the unnecessary constant CRYPTO_ALG_TYPE_DIGEST, which has the
> same value as CRYPTO_ALG_TYPE_HASH.
>
> Signed-off-by: Eric Biggers
> ---
> Documentation/crypto/architecture.rst | 4 +---
> crypto/cr
On Mon, May 20, 2019 at 09:49:46AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The "cryptomgr" module is required for templates to be used. Many
> templates select it, but others don't. Make all templates select it.
>
> Signed-off-by: Eric Biggers
> ---
> crypto/Kconfig | 8
On Mon, May 20, 2019 at 09:53:58AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> kcrypto_wq is only used by cryptd, so move it into cryptd.c and change
> the workqueue name from "crypto" to "cryptd".
>
> Signed-off-by: Eric Biggers
> ---
> crypto/Kconfig | 5
On Mon, May 20, 2019 at 09:52:07AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> echainiv is the only algorithm or template in the crypto API that is
> enabled by default. But there doesn't seem to be a good reason for it.
> And it pulls in a lot of stuff as dependencies, like AEAD support
On Mon, May 20, 2019 at 03:59:19PM +0200, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong
> ---
> drivers/char/hw_random/meson-rng.c | 52 +-
> 1 file changed, 1 insertion(+), 51 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondo
On Thu, May 30, 2019 at 02:43:27PM +0530, Vaneet Narang wrote:
> [Reminder] Any updates ?
I was assuming that Andrew was going to pick this up. Andrew?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
>
> I've tried coping the IV before the extended descriptor allocation, but
> is not working and to make it work will need to make more changes in
> CAAM. We need the original iv, and if we move it before
> skcipher_edesc_alloc we l
On 5/30/2019 1:16 AM, Ard Biesheuvel wrote:
> On Wed, 29 May 2019 at 22:27, Eric Biggers wrote:
>>
>> On Wed, May 29, 2019 at 08:10:56PM +0300, Iuliana Prodan wrote:
>>> The generic GCM driver should ensure that whatever it passes into
>>> scatterlists is safe for non-cache coherent DMA.
>>> The i
On Thu, May 30, 2019 at 01:18:34PM +, Horia Geanta wrote:
>
> I guess there are only two options:
> -either cache line sharing is avoided OR
> -users need to be *aware* they are sharing the cache line and some rules /
> assumptions are in place on how to safely work on the data
No there is a t
On Thu, 30 May 2019 at 15:18, Horia Geanta wrote:
>
> On 5/30/2019 11:08 AM, Ard Biesheuvel wrote:
> > On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
> >>
> >> On 5/30/2019 8:34 AM, Herbert Xu wrote:
> >>> On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
>
> So what abou
On Thu, May 30, 2019 at 01:35:06PM +0200, Ondrej Mosnacek wrote:
>
> Because libkcapi already assumes these values [1] and has code that
> uses them. Reserving will allow existing builds of libkcapi to work
> correctly once the functionality actually lands in the kernel (if that
> ever happens). Of
On 5/30/2019 11:08 AM, Ard Biesheuvel wrote:
> On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
>>
>> On 5/30/2019 8:34 AM, Herbert Xu wrote:
>>> On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
So what about the other places that also pass an IV located next to the
d
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 0adb0c99594b73844cf9a5714faa6553ea04ba04
commit: c34a320176a59445d76783e5ee043d6ecd22d011 [56/59] crypto: atmel-ecc -
factor out code that can be shared
reproduce:
# apt-get install sparse
On 5/6/2019 11:06 AM, Horia Geanta wrote:
> On 5/6/2019 9:40 AM, Herbert Xu wrote:
>> On Fri, May 03, 2019 at 03:05:48PM +0300, Horia Geantă wrote:
>>> The detection whether DKP (Derived Key Protocol) is used relies on
>>> the setkey callback.
>>> Since "aead_setkey" was replaced in some cases with
On Thu, May 30, 2019 at 10:12 AM Herbert Xu wrote:
> On Tue, May 21, 2019 at 12:00:34PM +0200, Ondrej Mosnacek wrote:
> >
> > @@ -256,6 +362,48 @@ static int alg_setsockopt(struct socket *sock, int
> > level, int optname,
> > goto unlock;
> >
> > err = alg_setk
On Thu, 30 May 2019 at 12:16, Pascal Van Leeuwen
wrote:
>
> > >> Yes. Code and data with static linkage will just be optimized away by
> > >> the compiler if the CONFIG_xx option is not enabled, so all you need
> > >> to guard are the actual statements, function calls etc.
> > >>
> > > Ok, makes s
> >> Yes. Code and data with static linkage will just be optimized away by
> >> the compiler if the CONFIG_xx option is not enabled, so all you need
> >> to guard are the actual statements, function calls etc.
> >>
> > Ok, makes sense. Then I'll just config out the relevant function bodies
> > and
> >
> > The crypto_alloc_shash will only identify cipher implementations that
> were
> > registered with the CRYPTO_ALG_TYPE_SHASH flag. That flag is set when a
> cipher
> > is registered using crypto_register_shash.
> >
> > Thus, ciphers registered with crypto_register_ahash will not bear this
> f
On 2019-05-30 10:12 am, Peter Robinson wrote:
Hi Eric,
I'm seeing the crash below on ARMv7 devices, at least the Raspberry Pi
and UDoo Neo (i.MX6SX), with your "crypto: run initcalls for generic
implementations earlier" patch. It's causing the boot to fail very
early on across the ARMv7 devices
[Reminder] Any updates ?
> currently params structure is passed in all functions, which increases
> stack usage in all the function and lead to stack overflow on target like
> ARM with kernel stack size of 8 KB so better to pass pointer.
> Checked for ARM:
> (ZSTD_compressContinue_internal)->
[Reminder] Any Comments?
>rankPos structure variables value can not be more than 512.
>So it can easily be declared as U16 rather than U32.
>It will reduce stack usage of HUF_sort from 256 bytes to 128 bytes
>original:
>e24ddc01sub sp, sp, #256; 0x100
>changed:
>e24dd080
Hi Eric,
I'm seeing the crash below on ARMv7 devices, at least the Raspberry Pi
and UDoo Neo (i.MX6SX), with your "crypto: run initcalls for generic
implementations earlier" patch. It's causing the boot to fail very
early on across the ARMv7 devices I've tested on Fedora (I'm the Arm
lead for Fedo
On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
>
> On 5/30/2019 8:34 AM, Herbert Xu wrote:
> > On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
> >>
> >> So what about the other places that also pass an IV located next to the
> >> data,
> >> like crypto/ccm.c and crypto/adiantum.c
On 5/30/2019 8:34 AM, Herbert Xu wrote:
> On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
>>
>> So what about the other places that also pass an IV located next to the data,
>> like crypto/ccm.c and crypto/adiantum.c? If we're actually going to make
>> this a
Fix for ccm is WIP.
We
Hi,
On 21/05/2019 12:00, Ondrej Mosnacek wrote:
> This patch adds new socket options to AF_ALG that allow setting key from
> kernel keyring. For simplicity, each keyring key type (logon, user,
> trusted, encrypted) has its own socket option name and the value is just
> the key description string t
- Ursprüngliche Mail -
> Von: "Herbert Xu"
> An: "richard"
> CC: "Linux Crypto Mailing List" ,
> linux-arm-ker...@lists.infradead.org, "linux-kernel"
> , linux-...@nxp.com, feste...@gmail.com,
> "kernel" , "Sascha Hauer"
> , shawn...@kernel.org, da...@davemloft.net, "david"
>
> Gesend
On Tue, May 21, 2019 at 12:00:34PM +0200, Ondrej Mosnacek wrote:
>
> @@ -256,6 +362,48 @@ static int alg_setsockopt(struct socket *sock, int
> level, int optname,
> goto unlock;
>
> err = alg_setkey(sk, optval, optlen);
> +#ifdef CONFIG_KEYS
> + br
72 matches
Mail list logo
