[PATCH 09/12] crypto: atmel-sha: add support to hmac(shaX)

This patch adds support to the hmac(shaX) algorithms. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha-regs.h | 4 + drivers/crypto/atmel-sha.c | 598 +++- 2 files changed, 601 insertions(+), 1 deletion(-) diff

[PATCH 09/12] crypto: atmel-sha: add support to hmac(shaX)

This patch adds support to the hmac(shaX) algorithms. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha-regs.h | 4 + drivers/crypto/atmel-sha.c | 598 +++- 2 files changed, 601 insertions(+), 1 deletion(-) diff --git

[PATCH 07/12] crypto: atmel-sha: add atmel_sha_cpu_start()

This patch adds a simple function to perform data transfer with PIO, hence handled by the CPU. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 90 ++ 1 file changed, 90 insertions(+) diff --git

[PATCH 08/12] crypto: atmel-sha: add simple DMA transfers

This patch adds a simple function to perform data transfer with the DMA controller. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 116 + 1 file changed, 116 insertions(+) diff --git

[PATCH 07/12] crypto: atmel-sha: add atmel_sha_cpu_start()

This patch adds a simple function to perform data transfer with PIO, hence handled by the CPU. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 90 ++ 1 file changed, 90 insertions(+) diff --git a/drivers/crypto/atmel-sha.c

[PATCH 08/12] crypto: atmel-sha: add simple DMA transfers

This patch adds a simple function to perform data transfer with the DMA controller. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 116 + 1 file changed, 116 insertions(+) diff --git a/drivers/crypto/atmel-sha.c

[PATCH 05/12] crypto: atmel-sha: add atmel_sha_wait_for_data_ready()

This patch simply defines a helper function to test the 'Data Ready' flag of the Status Register. It also gives a chance for the crypto request to be processed synchronously if this 'Data Ready' flag is already set when polling the Status Register. Indeed, running synchronously avoid the latency

[PATCH 05/12] crypto: atmel-sha: add atmel_sha_wait_for_data_ready()

This patch simply defines a helper function to test the 'Data Ready' flag of the Status Register. It also gives a chance for the crypto request to be processed synchronously if this 'Data Ready' flag is already set when polling the Status Register. Indeed, running synchronously avoid the latency

[PATCH 04/12] crypto: atmel-sha: redefine SHA_FLAGS_SHA* flags to match SHA_MR_ALGO_SHA*

This patch modifies the SHA_FLAGS_SHA* flags: those algo flags are now organized as values of a single bitfield instead of individual bits. This allows to reduce the number of bits needed to encode all possible values. Also the new values match the SHA_MR_ALGO_SHA* values hence the algorithm

[PATCH 00/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi all, this series of patches has been based and tested on next-20161222 with CRYPTO_MANAGER_DISABLED_TESTS not set. The series adds support to the hmac(shaX) algorithms first, then combines both the Atmel SHA and AES hardware accelerators to implement authenc(hmac(shaX),Y(aes)) algorithms

[PATCH 01/12] crypto: atmel-sha: create function to get an Atmel SHA device

This is a transitional patch: it creates the atmel_sha_find_dev() function, which will be used in further patches to share the source code responsible for finding a Atmel SHA device. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 15 +++ 1

[GIT PULL] Block fixes for 4.10-rc1

Hi Linus, Just a set of small fixes that have either been queued up after the original pull for this merge window, or just missed the original pull request. - A few bcache fixes/changes from Eric and Kent. - Adding WRITE_SAME to the command filter whitelist frm Mauricio. - Kill an unused

[PATCH 04/12] crypto: atmel-sha: redefine SHA_FLAGS_SHA* flags to match SHA_MR_ALGO_SHA*

This patch modifies the SHA_FLAGS_SHA* flags: those algo flags are now organized as values of a single bitfield instead of individual bits. This allows to reduce the number of bits needed to encode all possible values. Also the new values match the SHA_MR_ALGO_SHA* values hence the algorithm

[PATCH 00/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi all, this series of patches has been based and tested on next-20161222 with CRYPTO_MANAGER_DISABLED_TESTS not set. The series adds support to the hmac(shaX) algorithms first, then combines both the Atmel SHA and AES hardware accelerators to implement authenc(hmac(shaX),Y(aes)) algorithms

[PATCH 01/12] crypto: atmel-sha: create function to get an Atmel SHA device

This is a transitional patch: it creates the atmel_sha_find_dev() function, which will be used in further patches to share the source code responsible for finding a Atmel SHA device. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 15 +++ 1 file changed, 11

[GIT PULL] Block fixes for 4.10-rc1

Hi Linus, Just a set of small fixes that have either been queued up after the original pull for this merge window, or just missed the original pull request. - A few bcache fixes/changes from Eric and Kent. - Adding WRITE_SAME to the command filter whitelist frm Mauricio. - Kill an unused

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 6:07 PM, Andy Lutomirski wrote: > On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin > wrote: >> As a separate message, to disentangle the threads, I'd like to >> talk about get_random_long(). >> >> After some thinking, I still

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 6:07 PM, Andy Lutomirski wrote: > On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin > wrote: >> As a separate message, to disentangle the threads, I'd like to >> talk about get_random_long(). >> >> After some thinking, I still like the "state-preserving" construct >> that's

Re: [3/3] ARM: da850: Add ti, da830-uart compatible for serial ports

On 12/20/2016 02:23 PM, David Lechner wrote: > TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond Similar comment about adding Keystone SoCs to the list of SoCs. > the standard 8250 registers, so we need a new compatible string to > indicate this. Also, at least one of these

Re: [3/3] ARM: da850: Add ti, da830-uart compatible for serial ports

On 12/20/2016 02:23 PM, David Lechner wrote: > TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond Similar comment about adding Keystone SoCs to the list of SoCs. > the standard 8250 registers, so we need a new compatible string to > indicate this. Also, at least one of these

Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

Am Dienstag, 13. Dezember 2016, 18:48:50 schrieb Heiko Stuebner: > Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris: > > Hi Heiko, > > > > On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote: > > > Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris: > >

Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

Am Dienstag, 13. Dezember 2016, 18:48:50 schrieb Heiko Stuebner: > Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris: > > Hi Heiko, > > > > On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote: > > > Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris: > >

BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: >> Hi Hannes, >> >> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa >> wrote: >> > IPv6 you cannot touch

BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: >> Hi Hannes, >> >> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa >> wrote: >> > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. >> > You

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe ha scritto: > > This is basically identical to deadline-iosched, except it registers > as a MQ capable scheduler. This is still a single queue design. > > Signed-off-by: Jens Axboe > --- ... > diff --git

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe ha scritto: > > This is basically identical to deadline-iosched, except it registers > as a MQ capable scheduler. This is still a single queue design. > > Signed-off-by: Jens Axboe > --- ... > diff --git a/block/mq-deadline.c

Re: [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 12/22/2016 10:55 AM, Juergen Gross wrote: > On 22/12/16 16:49, Boris Ostrovsky wrote: >> On 12/22/2016 02:19 AM, Juergen Gross wrote: >>> When the xenbus driver does some special handling for a Xenstore >>> command any error condition related to the command should be returned >>> via an error

Re: [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 12/22/2016 10:55 AM, Juergen Gross wrote: > On 22/12/16 16:49, Boris Ostrovsky wrote: >> On 12/22/2016 02:19 AM, Juergen Gross wrote: >>> When the xenbus driver does some special handling for a Xenstore >>> command any error condition related to the command should be returned >>> via an error

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote: > I find this compelling. We'll have one csprng for both > get_random_int/long and for /dev/urandom, and we'll be able to update > that silly warning on the comment of get_random_int/long to read > "gives output of either rdrand

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote: > I find this compelling. We'll have one csprng for both > get_random_int/long and for /dev/urandom, and we'll be able to update > that silly warning on the comment of get_random_int/long to read > "gives output of either rdrand

Re: [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 22/12/16 16:49, Boris Ostrovsky wrote: > On 12/22/2016 02:19 AM, Juergen Gross wrote: >> When the xenbus driver does some special handling for a Xenstore >> command any error condition related to the command should be returned >> via an error response instead of letting the related write

Re: [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 22/12/16 16:49, Boris Ostrovsky wrote: > On 12/22/2016 02:19 AM, Juergen Gross wrote: >> When the xenbus driver does some special handling for a Xenstore >> command any error condition related to the command should be returned >> via an error response instead of letting the related write

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: > > following up on what appears to be a random subject: ;) > > > > IIRC, ext4 code by default still uses half_md4 for hashing of

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: > > following up on what appears to be a random subject: ;) > > > > IIRC, ext4 code by default still uses half_md4 for hashing of filenames > > in the htree.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:51 PM, Hannes Frederic Sowa wrote: > This algorithm should be a non-seeded algorithm, because the hashes > should be stable and verifiable by user space tooling. Thus this would > need a hashing algorithm that is hardened against pre-image >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:51 PM, Hannes Frederic Sowa wrote: > This algorithm should be a non-seeded algorithm, because the hashes > should be stable and verifiable by user space tooling. Thus this would > need a hashing algorithm that is hardened against pre-image > attacks/collision resistance,

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > Hi Hannes, > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa > wrote: > > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > > You don't want to give people new IPv6 addresses

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > Hi Hannes, > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa > wrote: > > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > > You don't want to give people new IPv6 addresses with the same stable > >

Re: [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

On 22/12/16 16:38, Boris Ostrovsky wrote: > On 12/22/2016 02:19 AM, Juergen Gross wrote: >> When accessing Xenstore in a transaction the user is specifying a >> transaction id which he normally obtained from Xenstore when starting >> the transaction. Xenstore is validating a transaction id against

Re: [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

On 22/12/16 16:38, Boris Ostrovsky wrote: > On 12/22/2016 02:19 AM, Juergen Gross wrote: >> When accessing Xenstore in a transaction the user is specifying a >> transaction id which he normally obtained from Xenstore when starting >> the transaction. Xenstore is validating a transaction id against

Re: [PATCH 3/3] xen: remove stale xs_input_avail() from header

On 12/22/2016 02:19 AM, Juergen Gross wrote: > In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of > xs_input_avail(). Remove it. > > Signed-off-by: Juergen Gross > Reviewed-by: Boris Ostrovsky

Re: [PATCH 3/3] xen: remove stale xs_input_avail() from header

On 12/22/2016 02:19 AM, Juergen Gross wrote: > In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of > xs_input_avail(). Remove it. > > Signed-off-by: Juergen Gross > Reviewed-by: Boris Ostrovsky

Re: [PATCH v2] stmmac: CSR clock configuration fix

G'day Joao, On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference design I checked a problem in the CSR clock configuration that was impossibilitating the phy discovery, since every read operation returned 0x. This patch fixes the issue. Signed-off-by: Joao

Re: [PATCH v2] stmmac: CSR clock configuration fix

G'day Joao, On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference design I checked a problem in the CSR clock configuration that was impossibilitating the phy discovery, since every read operation returned 0x. This patch fixes the issue. Signed-off-by: Joao

Re: [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 12/22/2016 02:19 AM, Juergen Gross wrote: > When the xenbus driver does some special handling for a Xenstore > command any error condition related to the command should be returned > via an error response instead of letting the related write operation > fail. Otherwise the user land handler

Re: [PATCH 2/3] xen: return xenstore command failures via response instead of rc

On 12/22/2016 02:19 AM, Juergen Gross wrote: > When the xenbus driver does some special handling for a Xenstore > command any error condition related to the command should be returned > via an error response instead of letting the related write operation > fail. Otherwise the user land handler

Re: [PATCH v2] stmmac: CSR clock configuration fix

Hello Phil, Às 3:42 PM de 12/22/2016, Phil Reid escreveu: > G'day Joao, > > On 22/12/2016 20:38, Joao Pinto wrote: >> When testing stmmac with my QoS reference design I checked a problem in the >> CSR clock configuration that was impossibilitating the phy discovery, since >> every read

Re: [PATCH 0/3] power: supply: bq24735: handle AC adapter absence

Hi, On Tue, Dec 20, 2016 at 12:32:59PM +0100, Peter Rosin wrote: > There is provision in the driver for handling the case where the > chargers are not responding to i2c requests when the AC adapter > is absent. I think this has been used by some Tegra boards that > leave the charger handling to

Re: [PATCH v2] stmmac: CSR clock configuration fix

Hello Phil, Às 3:42 PM de 12/22/2016, Phil Reid escreveu: > G'day Joao, > > On 22/12/2016 20:38, Joao Pinto wrote: >> When testing stmmac with my QoS reference design I checked a problem in the >> CSR clock configuration that was impossibilitating the phy discovery, since >> every read

Re: [PATCH 0/3] power: supply: bq24735: handle AC adapter absence

Hi, On Tue, Dec 20, 2016 at 12:32:59PM +0100, Peter Rosin wrote: > There is provision in the driver for handling the case where the > chargers are not responding to i2c requests when the AC adapter > is absent. I think this has been used by some Tegra boards that > leave the charger handling to

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Thu, 22 Dec 2016, Guenter Roeck wrote: > On 12/22/2016 04:29 AM, Julia Lawall wrote: > > > > > > On Wed, 21 Dec 2016, Guenter Roeck wrote: > > > > > Hi Julia, > > > > > > On Wed, Dec 21, 2016 at 08:39:38PM +0100, Julia Lawall wrote: > > > > > > > > > > > > On Wed, 21 Dec 2016, Guenter Roeck

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Thu, 22 Dec 2016, Guenter Roeck wrote: > On 12/22/2016 04:29 AM, Julia Lawall wrote: > > > > > > On Wed, 21 Dec 2016, Guenter Roeck wrote: > > > > > Hi Julia, > > > > > > On Wed, Dec 21, 2016 at 08:39:38PM +0100, Julia Lawall wrote: > > > > > > > > > > > > On Wed, 21 Dec 2016, Guenter Roeck

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Hannes, On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa wrote: > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > You don't want to give people new IPv6 addresses with the same stable > secret (across reboots) after a kernel upgrade.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Hannes, On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa wrote: > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > You don't want to give people new IPv6 addresses with the same stable > secret (across reboots) after a kernel upgrade. Maybe they lose > connectivity

Re: [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

On 12/22/2016 02:19 AM, Juergen Gross wrote: > When accessing Xenstore in a transaction the user is specifying a > transaction id which he normally obtained from Xenstore when starting > the transaction. Xenstore is validating a transaction id against all > known transaction ids of the connection

Re: [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

On 12/22/2016 02:19 AM, Juergen Gross wrote: > When accessing Xenstore in a transaction the user is specifying a > transaction id which he normally obtained from Xenstore when starting > the transaction. Xenstore is validating a transaction id against all > known transaction ids of the connection

Re: [PATCH 2/3] fs/pstore: fs/squashfs: Change lz4 compressor functions to work with new version

On (12/22/16 16:31), Sven Schmidt wrote: > Hey Sergey and thanks for your time. I'm afraid I messed up the diffstat on > this. > Actually I just replaced the function calls and corrected the use of return > values. > I will send an updated patchset later since there also have been errors >

Re: [PATCH 2/3] fs/pstore: fs/squashfs: Change lz4 compressor functions to work with new version

On (12/22/16 16:31), Sven Schmidt wrote: > Hey Sergey and thanks for your time. I'm afraid I messed up the diffstat on > this. > Actually I just replaced the function calls and corrected the use of return > values. > I will send an updated patchset later since there also have been errors >

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On 12/22/2016 04:29 AM, Julia Lawall wrote: On Wed, 21 Dec 2016, Guenter Roeck wrote: Hi Julia, On Wed, Dec 21, 2016 at 08:39:38PM +0100, Julia Lawall wrote: On Wed, 21 Dec 2016, Guenter Roeck wrote: Hi Julia, On Wed, Dec 21, 2016 at 03:05:37PM +0100, Julia Lawall wrote: A solution

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > > As a first step, I'm considering adding a patch to move halfmd4.c > > inside the ext4 domain, or at the very least, simply remove it from > >

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On 12/22/2016 04:29 AM, Julia Lawall wrote: On Wed, 21 Dec 2016, Guenter Roeck wrote: Hi Julia, On Wed, Dec 21, 2016 at 08:39:38PM +0100, Julia Lawall wrote: On Wed, 21 Dec 2016, Guenter Roeck wrote: Hi Julia, On Wed, Dec 21, 2016 at 03:05:37PM +0100, Julia Lawall wrote: A solution

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > > As a first step, I'm considering adding a patch to move halfmd4.c > > inside the ext4 domain, or at the very least, simply remove it from > > linux/cryptohash.h. That'll

Re: [PATCH 2/3] fs/pstore: fs/squashfs: Change lz4 compressor functions to work with new version

On 12/22/2016 02:21 PM, Sergey Senozhatsky wrote: > On (12/20/16 19:53), Sven Schmidt wrote: >> @@ -366,7 +366,7 @@ static int decompress_lz4(void *in, void *out, size_t >> inlen, size_t outlen) >> >> static void allocate_lz4(void) >> { >> -big_oops_buf_sz =

Re: [PATCH 2/3] fs/pstore: fs/squashfs: Change lz4 compressor functions to work with new version

On 12/22/2016 02:21 PM, Sergey Senozhatsky wrote: > On (12/20/16 19:53), Sven Schmidt wrote: >> @@ -366,7 +366,7 @@ static int decompress_lz4(void *in, void *out, size_t >> inlen, size_t outlen) >> >> static void allocate_lz4(void) >> { >> -big_oops_buf_sz =

Re: [PATCH v4 3/5] i2c: designware: Add slave definitions

On Thu, 2016-12-22 at 14:59 +, Luis Oliveira wrote: > On 13-Dec-16 14:11, Rob Herring wrote: > > Something like this: > > > > of_for_each_child_node(child) { > >   of_property_read_u32(child, "reg", ); > >   if (reg & I2C_OWN_SLAVE_ADDRESS)) > > im_a_slave = true; > > } > > > >

Re: [PATCH v4 3/5] i2c: designware: Add slave definitions

On Thu, 2016-12-22 at 14:59 +, Luis Oliveira wrote: > On 13-Dec-16 14:11, Rob Herring wrote: > > Something like this: > > > > of_for_each_child_node(child) { > >   of_property_read_u32(child, "reg", ); > >   if (reg & I2C_OWN_SLAVE_ADDRESS)) > > im_a_slave = true; > > } > > > >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > As a first step, I'm considering adding a patch to move halfmd4.c > inside the ext4 domain, or at the very least, simply remove it from > linux/cryptohash.h. That'll then leave the handful of bizarre sha1 > usages to

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > As a first step, I'm considering adding a patch to move halfmd4.c > inside the ext4 domain, or at the very least, simply remove it from > linux/cryptohash.h. That'll then leave the handful of bizarre sha1 > usages to consider.

Re: [PATCHSET v4] blk-mq-scheduling framework

> Il giorno 19 dic 2016, alle ore 22:05, Jens Axboe ha scritto: > > On 12/19/2016 11:21 AM, Paolo Valente wrote: >> >>> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe ha scritto: >>> >>> On 12/19/2016 04:32 AM, Paolo Valente wrote: > Il giorno 17 dic

Re: [PATCHSET v4] blk-mq-scheduling framework

> Il giorno 19 dic 2016, alle ore 22:05, Jens Axboe ha scritto: > > On 12/19/2016 11:21 AM, Paolo Valente wrote: >> >>> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe ha scritto: >>> >>> On 12/19/2016 04:32 AM, Paolo Valente wrote: > Il giorno 17 dic 2016, alle ore 01:12, Jens

Re: [2/3] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx

On 12/20/2016 02:23 PM, David Lechner wrote: > This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx. These > SoCs have standard 8250 registers plus some extra non-standard registers. > > The UART will not function unless the non-standard Power and Emulation > Management Register

Re: [2/3] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx

On 12/20/2016 02:23 PM, David Lechner wrote: > This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx. These > SoCs have standard 8250 registers plus some extra non-standard registers. > > The UART will not function unless the non-standard Power and Emulation > Management Register

Re: [PATCH 6/8] blk-mq-sched: add framework for MQ capable IO schedulers

> Il giorno 21 dic 2016, alle ore 03:22, Jens Axboe ha scritto: > > On Tue, Dec 20 2016, Paolo Valente wrote: >>> + else >>> + rq = __blk_mq_alloc_request(data, op); >>> + >>> + if (rq) { >>> + rq->elv.icq = NULL; >>> + if (e &&

Re: [PATCH 6/8] blk-mq-sched: add framework for MQ capable IO schedulers

> Il giorno 21 dic 2016, alle ore 03:22, Jens Axboe ha scritto: > > On Tue, Dec 20 2016, Paolo Valente wrote: >>> + else >>> + rq = __blk_mq_alloc_request(data, op); >>> + >>> + if (rq) { >>> + rq->elv.icq = NULL; >>> + if (e && e->type->icq_cache) >>> +

[RFC PATCH] cgroup, cpuset: add cpuset.remap_cpus

Changes a cpuset, recursively remapping all its descendants to the new range. Signed-off-by: Wolfgang Bumiller --- Currently once a cpuset cgroup has a subdirectory it's impossible to remove cpu without manually recursing through the cgroup file system. The problem gets

[RFC PATCH] cgroup, cpuset: add cpuset.remap_cpus

Changes a cpuset, recursively remapping all its descendants to the new range. Signed-off-by: Wolfgang Bumiller --- Currently once a cpuset cgroup has a subdirectory it's impossible to remove cpu without manually recursing through the cgroup file system. The problem gets worse if you want to

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:05 PM, Hannes Frederic Sowa wrote: > This change would need a new version of the ext4 super block, because > you should not change existing file systems. Right. As a first step, I'm considering adding a patch to move halfmd4.c inside the

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:05 PM, Hannes Frederic Sowa wrote: > This change would need a new version of the ext4 super block, because > you should not change existing file systems. Right. As a first step, I'm considering adding a patch to move halfmd4.c inside the ext4 domain, or at the very

Re: [LKP] [lkp-developer] [sched/fair] 4e5160766f: +149% ftq.noise.50% regression

Le Tuesday 13 Dec 2016 à 09:47:30 (+0800), Huang, Ying a écrit : > Hi, Vincent, > > Vincent Guittot writes: > > > Hi Ying, > > > > On 12 December 2016 at 06:43, kernel test robot > > wrote: > >> Greeting, > >> > >> FYI, we noticed a 149%

Re: [LKP] [lkp-developer] [sched/fair] 4e5160766f: +149% ftq.noise.50% regression

Le Tuesday 13 Dec 2016 à 09:47:30 (+0800), Huang, Ying a écrit : > Hi, Vincent, > > Vincent Guittot writes: > > > Hi Ying, > > > > On 12 December 2016 at 06:43, kernel test robot > > wrote: > >> Greeting, > >> > >> FYI, we noticed a 149% regression of ftq.noise.50% due to commit: > >> > >> >

pull-request: wireless-drivers 2016-12-22

Hi Dave, before the holidays a really small pull request for 4.10. I just want to have the regressions in rtlwifi and ath9k fixed quickly so I send this earlier than I normally would. Please let me know if there are any problems. Kalle The following changes since commit

pull-request: wireless-drivers 2016-12-22

Hi Dave, before the holidays a really small pull request for 4.10. I just want to have the regressions in rtlwifi and ath9k fixed quickly so I send this earlier than I normally would. Please let me know if there are any problems. Kalle The following changes since commit

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 14:10, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: >> following up on what appears to be a random subject: ;) >> >> IIRC, ext4 code by default still uses half_md4 for hashing of filenames >> in the htree.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 14:10, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: >> following up on what appears to be a random subject: ;) >> >> IIRC, ext4 code by default still uses half_md4 for hashing of filenames >> in the htree. siphash seems to fit this use

[PATCH urgent] Revert "x86/unwind: Detect bad stack return address"

This reverts commit b6959a362177 ("x86/unwind: Detect bad stack return address"). Andrey Konovalov reported an unwinder warning: WARNING: unrecognized kernel stack return address a001 at 88006377fa18 in a.out:4467 The unwind was initiated from an interrupt which occurred

[PATCH urgent] Revert "x86/unwind: Detect bad stack return address"

This reverts commit b6959a362177 ("x86/unwind: Detect bad stack return address"). Andrey Konovalov reported an unwinder warning: WARNING: unrecognized kernel stack return address a001 at 88006377fa18 in a.out:4467 The unwind was initiated from an interrupt which occurred

Re: [PATCH v4 3/5] i2c: designware: Add slave definitions

On 13-Dec-16 14:11, Rob Herring wrote: > Again, please don't top post. And your line wrapping is messed up. > IOW, you can't use Outlook. > > On Tue, Dec 13, 2016 at 4:50 AM, Luis de Oliveira > wrote: >> The controller for i2c-designware cannot be slave/master at the

Re: [PATCH v4 3/5] i2c: designware: Add slave definitions

On 13-Dec-16 14:11, Rob Herring wrote: > Again, please don't top post. And your line wrapping is messed up. > IOW, you can't use Outlook. > > On Tue, Dec 13, 2016 at 4:50 AM, Luis de Oliveira > wrote: >> The controller for i2c-designware cannot be slave/master at the same time >> and it has to

Re: Build warning on 32-bit PPC - bisected to commit 989cea5c14be

On 12/21/2016 08:02 PM, Nicholas Piggin wrote: Hi Larry, This is strange you've bisected it there, I can't see how that patch would trigger it. That said, powerpc has had a few small build system glitches. It looks like this warning could be fixed by changing #elif CONFIG_FSL_BOOKE to #elif

Re: Build warning on 32-bit PPC - bisected to commit 989cea5c14be

On 12/21/2016 08:02 PM, Nicholas Piggin wrote: Hi Larry, This is strange you've bisected it there, I can't see how that patch would trigger it. That said, powerpc has had a few small build system glitches. It looks like this warning could be fixed by changing #elif CONFIG_FSL_BOOKE to #elif

Re: [RFC/PATCH] linux/kernel.h: Fix DIV_ROUND_CLOSEST to support negative divisors

On 12/22/2016 02:22 AM, Niklas Söderlund wrote: Add support to DIV_ROUND_CLOSEST for negative divisors if both dividend and divisor variable types are signed. This should not alter current behavior for users of the macro as previously negative divisors where not supported. Before:

Re: [RFC/PATCH] linux/kernel.h: Fix DIV_ROUND_CLOSEST to support negative divisors

On 12/22/2016 02:22 AM, Niklas Söderlund wrote: Add support to DIV_ROUND_CLOSEST for negative divisors if both dividend and divisor variable types are signed. This should not alter current behavior for users of the macro as previously negative divisors where not supported. Before:

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, 2016-12-22 at 00:45 -0800, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > > > Only btrfs, ext4, and xfs implement it for data changes. Because of > > this, these filesystems must log the inode to disk whenever the > > i_version counter changes.

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Thu, 2016-12-22 at 00:45 -0800, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > > > Only btrfs, ext4, and xfs implement it for data changes. Because of > > this, these filesystems must log the inode to disk whenever the > > i_version counter changes.

[PATCH v5] Patches for QCOM IPQ4019 clock driver

These patches are related to Qualcomm IPQ4019 GCC (Global Clock Controller) driver code mainly adding the nodes for clock marked as fixed in current IPQ4019 clock driver and support for multiple CPU frequencies. [v5] 1. Hardcoded the safe parent index for APSS CPU frequency change

[PATCH v5] clk: qcom: ipq4019: Add the cpu clock frequency change notifier

The current driver code gives the crash or gets hang while switching the CPU frequency some time. The APSS CPU Clock divider is not glitch free so it the APPS clock need to be switched for stable clock during the change. This patch adds the frequency change notifier for APSS CPU clock. It changes

[PATCH v5] Patches for QCOM IPQ4019 clock driver

These patches are related to Qualcomm IPQ4019 GCC (Global Clock Controller) driver code mainly adding the nodes for clock marked as fixed in current IPQ4019 clock driver and support for multiple CPU frequencies. [v5] 1. Hardcoded the safe parent index for APSS CPU frequency change

[PATCH v5] clk: qcom: ipq4019: Add the cpu clock frequency change notifier

The current driver code gives the crash or gets hang while switching the CPU frequency some time. The APSS CPU Clock divider is not glitch free so it the APPS clock need to be switched for stable clock during the change. This patch adds the frequency change notifier for APSS CPU clock. It changes

Re: [v1] i2c: busses: i2c-designware-pcidrv:- Handle return NULL error from pcim_iomap_table

On Thu, 2016-12-22 at 17:09 +0530, Arvind Yadav wrote: > Here, If pcim_iomap_table will fail. It will return NULL. > Kernel can run into a NULL-pointer dereference. > This error check will avoid NULL pointer dereference. > > Signed-off-by: Arvind Yadav > --- >  

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

On Wed 2016-12-21 15:25:05, Josh Poimboeuf wrote: > On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote: > > On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to

<    3   4   5   6   7   8   9   10   11   12   >