[PATCH v3 06/13] iscsi: ensure RNG is seeded before use

It's not safe to use weak random data here, especially for the challenge response randomness. Since we're always in process context, it's safe to simply wait until we have enough randomness to carry out the authentication correctly. While we're at it, we clean up a small memleak during an error

[PATCH v3 06/13] iscsi: ensure RNG is seeded before use

It's not safe to use weak random data here, especially for the challenge response randomness. Since we're always in process context, it's safe to simply wait until we have enough randomness to carry out the authentication correctly. While we're at it, we clean up a small memleak during an error

[PATCH v3 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

This protocol uses lots of complex cryptography that relies on securely generated random numbers. Thus, it's important that the RNG is actually seeded before use. Fortuantely, it appears we're always operating in process context (there are many GFP_KERNEL allocations and other sleeping

[PATCH v3 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

This protocol uses lots of complex cryptography that relies on securely generated random numbers. Thus, it's important that the RNG is actually seeded before use. Fortuantely, it appears we're always operating in process context (there are many GFP_KERNEL allocations and other sleeping

[PATCH v3 11/13] net/route: use get_random_int for random counter

Using get_random_int here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Also, semantically, it's not really proper to have been assigning an

[PATCH v3 09/13] rhashtable: use get_random_u32 for hash_rnd

This is much faster and just as secure. It also has the added benefit of probably returning better randomness at early-boot on systems with architectural RNGs. Signed-off-by: Jason A. Donenfeld Cc: Thomas Graf Cc: Herbert Xu ---

[PATCH v3 11/13] net/route: use get_random_int for random counter

Using get_random_int here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Also, semantically, it's not really proper to have been assigning an

[PATCH v3 09/13] rhashtable: use get_random_u32 for hash_rnd

This is much faster and just as secure. It also has the added benefit of probably returning better randomness at early-boot on systems with architectural RNGs. Signed-off-by: Jason A. Donenfeld Cc: Thomas Graf Cc: Herbert Xu --- lib/rhashtable.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v3 10/13] net/neighbor: use get_random_u32 for 32-bit hash random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Signed-off-by: Jason A. Donenfeld Cc: David Miller

[PATCH v3 10/13] net/neighbor: use get_random_u32 for 32-bit hash random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Signed-off-by: Jason A. Donenfeld Cc: David Miller ---

[PATCH v3 13/13] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/crypto/rng.c

[PATCH v3 08/13] cifs: use get_random_u32 for 32-bit lock random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is sometimes when this is used. Signed-off-by: Jason A. Donenfeld Cc: Steve French

[PATCH v3 03/13] random: invalidate batched entropy after crng init

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to

[PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

These functions are simple convenience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.h | 25

[PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/crypto/rng.c index f46dac5288b9..e042437e64b4 100644 ---

[PATCH v3 08/13] cifs: use get_random_u32 for 32-bit lock random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is sometimes when this is used. Signed-off-by: Jason A. Donenfeld Cc: Steve French --- fs/cifs/cifsfs.c | 2 +- 1

[PATCH v3 03/13] random: invalidate batched entropy after crng init

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to

[PATCH v3 13/13] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

These functions are simple convenience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.h | 25 + 3

[PATCH v3 07/13] ceph: ensure RNG is seeded before using

Ceph uses the RNG for various nonce generations, and it shouldn't accept using bad randomness. So, we wait for the RNG to be properly seeded. We do this by calling wait_for_random_bytes() in a function that is certainly called in process context, early on, so that all subsequent calls to

[PATCH v3 07/13] ceph: ensure RNG is seeded before using

Ceph uses the RNG for various nonce generations, and it shouldn't accept using bad randomness. So, we wait for the RNG to be properly seeded. We do this by calling wait_for_random_bytes() in a function that is certainly called in process context, early on, so that all subsequent calls to

[PATCH v3 05/13] security/keys: ensure RNG is seeded before use

Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). However, we can't change to using a

[PATCH v3 05/13] security/keys: ensure RNG is seeded before use

Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). However, we can't change to using a

[PATCH v3 01/13] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 41

[PATCH v3 00/13] Unseeded In-Kernel Randomness Fixes

As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs involves adding a simple blocking API so that modules that use the RNG in process context can just sleep

[PATCH v3 00/13] Unseeded In-Kernel Randomness Fixes

As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs involves adding a simple blocking API so that modules that use the RNG in process context can just sleep

[PATCH v3 01/13] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 41 +++--

Re: [PATCH] qla2xxx: remove writeq/readq function definitions

Corentin, > Instead of rewriting write/readq, use linux/io-64-nonatomic-lo-hi.h > which already have them. Applied to 4.13/scsi-queue, thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] qla2xxx: remove writeq/readq function definitions

Corentin, > Instead of rewriting write/readq, use linux/io-64-nonatomic-lo-hi.h > which already have them. Applied to 4.13/scsi-queue, thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [resend RFC 1/6] ACPICA: add HMAT table definitions

On Mon, Jun 05, 2017 at 10:44:11PM +0200, Rafael J. Wysocki wrote: > On Mon, Jun 5, 2017 at 9:50 PM, Ross Zwisler > wrote: > > Import HMAT table definitions from the ACPICA codebase. > > > > This kernel patch was generated using an ACPICA patch from "Zheng, Lv" > >

Re: [resend RFC 1/6] ACPICA: add HMAT table definitions

On Mon, Jun 05, 2017 at 10:44:11PM +0200, Rafael J. Wysocki wrote: > On Mon, Jun 5, 2017 at 9:50 PM, Ross Zwisler > wrote: > > Import HMAT table definitions from the ACPICA codebase. > > > > This kernel patch was generated using an ACPICA patch from "Zheng, Lv" > > . The actual upstream patch

Re: [PATCH v2 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On Mon, Jun 5, 2017 at 6:33 AM, Ding Tianhong wrote: > > > On 2017/6/4 2:19, Alexander Duyck wrote: >> On Fri, Jun 2, 2017 at 9:04 PM, Ding Tianhong >> wrote: >>> The PCIe Device Control Register use the bit 4 to indicate that >>> whether the

Re: [PATCH v2 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On Mon, Jun 5, 2017 at 6:33 AM, Ding Tianhong wrote: > > > On 2017/6/4 2:19, Alexander Duyck wrote: >> On Fri, Jun 2, 2017 at 9:04 PM, Ding Tianhong >> wrote: >>> The PCIe Device Control Register use the bit 4 to indicate that >>> whether the device is permitted to enable relaxed ordering or

Re: [PATCH v3] kbuild: simplify silent build (-s) detection

2017-05-19 20:42 GMT+09:00 Masahiro Yamada : > This allows to detect -s (--silent) option without checking GNU Make > version. > > As commit e36aaea28972 ("kbuild: Fix silent builds with make-4") > pointed out, GNU Make 4.x changed the way/order it presents the >

Re: [PATCH v3] kbuild: simplify silent build (-s) detection

2017-05-19 20:42 GMT+09:00 Masahiro Yamada : > This allows to detect -s (--silent) option without checking GNU Make > version. > > As commit e36aaea28972 ("kbuild: Fix silent builds with make-4") > pointed out, GNU Make 4.x changed the way/order it presents the > command line options into

Re: sparc64 gcc 7.1 compile error

Hi David, David Miller wrote, > From: Waldemar Brodkorb > Date: Mon, 5 Jun 2017 11:19:41 +0200 > > > I get a compile/linking error with gcc 7.1 when targeting qemu system > > sparc64. > > This should fix the problem, please let me know if it works for you: Yes, that works

Re: sparc64 gcc 7.1 compile error

Hi David, David Miller wrote, > From: Waldemar Brodkorb > Date: Mon, 5 Jun 2017 11:19:41 +0200 > > > I get a compile/linking error with gcc 7.1 when targeting qemu system > > sparc64. > > This should fix the problem, please let me know if it works for you: Yes, that works fine for me. Thanks

Re: [PATCH v3] tags: honor COMPILED_SOURCE with apart output directory

Hi Robert, I wanted you to update the log. 2017-06-05 20:59 GMT+09:00 Robert Jarzmik : > When the kernel is compiled with an "O=" argument, the object files are > not necessarily in the source tree, and more probably in another tree. Always in another tree. > In this

Re: [PATCH v3] tags: honor COMPILED_SOURCE with apart output directory

Hi Robert, I wanted you to update the log. 2017-06-05 20:59 GMT+09:00 Robert Jarzmik : > When the kernel is compiled with an "O=" argument, the object files are > not necessarily in the source tree, and more probably in another tree. Always in another tree. > In this situation, the current

Re: [PATCH 1/1] genksyms: add printf format attribute to error_with_pos()

2017-05-20 20:27 GMT+09:00 Nicolas Iooss : > When compiling with -Wsuggest-attribute=format in HOSTCFLAGS, gcc > complains that error_with_pos() may be declared with a printf format > attribute: > > scripts/genksyms/genksyms.c:726:3: warning: function might be >

Re: [PATCH 1/1] genksyms: add printf format attribute to error_with_pos()

2017-05-20 20:27 GMT+09:00 Nicolas Iooss : > When compiling with -Wsuggest-attribute=format in HOSTCFLAGS, gcc > complains that error_with_pos() may be declared with a printf format > attribute: > > scripts/genksyms/genksyms.c:726:3: warning: function might be > possible candidate for

Re: [PATCH RFC v2 0/8] get_random_bytes_wait family of APIs

As this RFC series matures, all the changes are in this branch here, to look at: https://git.zx2c4.com/linux-dev/log/?h=jd/rng-blocker Ted -- there's one, in particular, that should probably be picked up regardless of the rest, and that's "random: invalidate batched entropy after crng init".

Re: [PATCH RFC v2 0/8] get_random_bytes_wait family of APIs

As this RFC series matures, all the changes are in this branch here, to look at: https://git.zx2c4.com/linux-dev/log/?h=jd/rng-blocker Ted -- there's one, in particular, that should probably be picked up regardless of the rest, and that's "random: invalidate batched entropy after crng init".

[PATCH v4 06/23] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

Add two compatible strings for UniPhier SoC family. "socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4, Pro4, sLD8. "socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2, LD6b, LD11, LD20. Signed-off-by: Masahiro Yamada --- Changes

[PATCH v4 06/23] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

Add two compatible strings for UniPhier SoC family. "socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4, Pro4, sLD8. "socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2, LD6b, LD11, LD20. Signed-off-by: Masahiro Yamada --- Changes in v4: - Adjusted to generic

[PATCH v4 16/23] mtd: nand: denali: use interrupt instead of polling for bank reset

The current bank reset implementation polls the INTR_STATUS register until interested bits are set. This is not good because: - polling simply wastes time-slice of the thread - The while() loop may continue eternally if no bit is set, for example, due to the controller problem. The

[PATCH v4 16/23] mtd: nand: denali: use interrupt instead of polling for bank reset

The current bank reset implementation polls the INTR_STATUS register until interested bits are set. This is not good because: - polling simply wastes time-slice of the thread - The while() loop may continue eternally if no bit is set, for example, due to the controller problem. The

[PATCH v4 13/23] mtd: nand: denali: fix NAND_CMD_PARAM handling

NAND_CMD_PARAM is not working at all due to multiple bugs. [1] The command 0x90 issued instead of 0xec The command code 0x90 is hard-code as index_addr(denali, addr | 0, 0x90) So, Read ID (0x90) command is sent to the device instead of Read Parameter Page (0xec). [2] only first 8 bytes are

[PATCH v4 13/23] mtd: nand: denali: fix NAND_CMD_PARAM handling

NAND_CMD_PARAM is not working at all due to multiple bugs. [1] The command 0x90 issued instead of 0xec The command code 0x90 is hard-code as index_addr(denali, addr | 0, 0x90) So, Read ID (0x90) command is sent to the device instead of Read Parameter Page (0xec). [2] only first 8 bytes are

[PATCH v4 07/23] mtd: nand: denali: set NAND_ECC_CUSTOM_PAGE_ACCESS

The denali_cmdfunc() actually does nothing valuable for NAND_CMD_{PAGEPROG,READ0,SEQIN}. For NAND_CMD_{READ0,SEQIN}, it copies "page" to "denali->page", then denali_read_page() and denali_read_page_raw() compare them to check if the NAND framework called the callbacks in correct order.

[PATCH v4 17/23] mtd: nand: denali: propagate page to helpers via function argument

This driver stores the currently addressed page into denali->page, which is later read out by helper functions. While I am tackling on this driver, I often missed to insert "denali->page = page;" where needed. This makes page_read/write callbacks to get access to a wrong page, which is a bug

[PATCH v4 07/23] mtd: nand: denali: set NAND_ECC_CUSTOM_PAGE_ACCESS

The denali_cmdfunc() actually does nothing valuable for NAND_CMD_{PAGEPROG,READ0,SEQIN}. For NAND_CMD_{READ0,SEQIN}, it copies "page" to "denali->page", then denali_read_page() and denali_read_page_raw() compare them to check if the NAND framework called the callbacks in correct order.

[PATCH v4 17/23] mtd: nand: denali: propagate page to helpers via function argument

This driver stores the currently addressed page into denali->page, which is later read out by helper functions. While I am tackling on this driver, I often missed to insert "denali->page = page;" where needed. This makes page_read/write callbacks to get access to a wrong page, which is a bug

[PATCH v4 05/23] mtd: nand: denali: remove Toshiba and Hynix specific fixup code

The Denali IP can automatically detect device parameters such as page size, oob size, device width, etc. and this driver currently relies on it. However, this hardware function is known to be problematic. [1] Due to a hardware bug, various misdetected cases were reported. That is why

[PATCH v4 01/23] mtd: nand: denali_dt: clean up resource ioremap

No need to use two struct resource pointers. Just reuse one. Signed-off-by: Masahiro Yamada --- Changes in v4: - Newly added Changes in v3: None Changes in v2: None drivers/mtd/nand/denali_dt.c | 12 +--- 1 file changed, 5 insertions(+), 7

[PATCH v4 05/23] mtd: nand: denali: remove Toshiba and Hynix specific fixup code

The Denali IP can automatically detect device parameters such as page size, oob size, device width, etc. and this driver currently relies on it. However, this hardware function is known to be problematic. [1] Due to a hardware bug, various misdetected cases were reported. That is why

[PATCH v4 01/23] mtd: nand: denali_dt: clean up resource ioremap

No need to use two struct resource pointers. Just reuse one. Signed-off-by: Masahiro Yamada --- Changes in v4: - Newly added Changes in v3: None Changes in v2: None drivers/mtd/nand/denali_dt.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git

[PATCH v4 10/23] mtd: nand: denali: handle timing parameters by setup_data_interface()

Handling timing parameters in a driver's own way should be avoided because it duplicates efforts of drivers/mtd/nand/nand_timings.c Besides, this driver hard-codes Intel specific parameters such as CLK_X=5, CLK_MULTI=4. Taking a certain device (Samsung K9WAG08U1A) into account by

[PATCH v4 19/23] mtd: nand: denali: use flag instead of register macro for direction

It is not a good idea to re-use macros that represent a specific register bit field for the transfer direction. It is true that bit 8 indicates the direction for the MAP10 pipeline operation and the data DMA operation, but this is not valid across the IP. Use a simple flag (write: 1, read: 0)

[PATCH v4 10/23] mtd: nand: denali: handle timing parameters by setup_data_interface()

Handling timing parameters in a driver's own way should be avoided because it duplicates efforts of drivers/mtd/nand/nand_timings.c Besides, this driver hard-codes Intel specific parameters such as CLK_X=5, CLK_MULTI=4. Taking a certain device (Samsung K9WAG08U1A) into account by

[PATCH v4 19/23] mtd: nand: denali: use flag instead of register macro for direction

It is not a good idea to re-use macros that represent a specific register bit field for the transfer direction. It is true that bit 8 indicates the direction for the MAP10 pipeline operation and the data DMA operation, but this is not valid across the IP. Use a simple flag (write: 1, read: 0)

[PATCH v4 08/23] mtd: nand: denali: do not propagate NAND_STATUS_FAIL to waitfunc()

Currently, the error handling of denali_write_page(_raw) is a bit complicated. If the program command fails, NAND_STATUS_FAIL is set to the driver internal denali->status, then read out later by denali_waitfunc(). We can avoid it by exploiting the nand_write_page() implementation. If

[PATCH v4 08/23] mtd: nand: denali: do not propagate NAND_STATUS_FAIL to waitfunc()

Currently, the error handling of denali_write_page(_raw) is a bit complicated. If the program command fails, NAND_STATUS_FAIL is set to the driver internal denali->status, then read out later by denali_waitfunc(). We can avoid it by exploiting the nand_write_page() implementation. If

[PATCH v4 02/23] mtd: nand: denali: use BIT() and GENMASK() for register macros

Use BIT() and GENMASK() for register field macros. This will make it easier to compare the macros with the register description in the Denali User's Guide. Signed-off-by: Masahiro Yamada --- Changes in v4: None Changes in v3: None Changes in v2: - Newly added

Re: [PATCH] checkpatch: Change format of --color argument to --color[=WHEN]

On Mon, Jun 05, 2017 at 04:10:30PM -0700, Joe Perches wrote: > On Mon, 2017-06-05 at 18:27 -0400, John Brooks wrote: > > The boolean --color argument did not offer the ability to force colourized > > output even if stdout is not a terminal. > > OK, but why is colorizing output not to terminals

Re: [PATCH] checkpatch: Change format of --color argument to --color[=WHEN]

On Mon, Jun 05, 2017 at 04:10:30PM -0700, Joe Perches wrote: > On Mon, 2017-06-05 at 18:27 -0400, John Brooks wrote: > > The boolean --color argument did not offer the ability to force colourized > > output even if stdout is not a terminal. > > OK, but why is colorizing output not to terminals

[PATCH v4 02/23] mtd: nand: denali: use BIT() and GENMASK() for register macros

Use BIT() and GENMASK() for register field macros. This will make it easier to compare the macros with the register description in the Denali User's Guide. Signed-off-by: Masahiro Yamada --- Changes in v4: None Changes in v3: None Changes in v2: - Newly added drivers/mtd/nand/denali.h |

[PATCH v4 00/23] mtd: nand: denali: Denali NAND IP patch bomb

This patch series intends to solve various problems. [1] The driver just retrieves the OOB area as-is whereas the controller uses syndrome page layout. [2] Many NAND chip specific parameters are hard-coded in the driver. [3] ONFi devices are not working [4] It can not read Bad Block Marker

[PATCH v4 15/23] mtd: nand: denali: fix bank reset function to detect the number of chips

The nand_scan_ident() iterates over maxchips, and calls nand_reset() for each. This driver currently passes the maximum number of banks (=chip selects) supported by the controller as maxchips. So, maxchips is typically 4 or 8. Usually, less number of NAND chips are connected to the controller.

[PATCH v4 09/23] mtd: nand: denali: remove unneeded find_valid_banks()

The function find_valid_banks() issues the Read ID (0x90) command, then compares the first byte (Manufacturer ID) of each bank with the one of bank0. This is equivalent to what nand_scan_ident() does. The number of chips is detected there, so this is unneeded. What is worse for

[PATCH v4 00/23] mtd: nand: denali: Denali NAND IP patch bomb

This patch series intends to solve various problems. [1] The driver just retrieves the OOB area as-is whereas the controller uses syndrome page layout. [2] Many NAND chip specific parameters are hard-coded in the driver. [3] ONFi devices are not working [4] It can not read Bad Block Marker

[PATCH v4 15/23] mtd: nand: denali: fix bank reset function to detect the number of chips

The nand_scan_ident() iterates over maxchips, and calls nand_reset() for each. This driver currently passes the maximum number of banks (=chip selects) supported by the controller as maxchips. So, maxchips is typically 4 or 8. Usually, less number of NAND chips are connected to the controller.

[PATCH v4 09/23] mtd: nand: denali: remove unneeded find_valid_banks()

The function find_valid_banks() issues the Read ID (0x90) command, then compares the first byte (Manufacturer ID) of each bank with the one of bank0. This is equivalent to what nand_scan_ident() does. The number of chips is detected there, so this is unneeded. What is worse for

[PATCH v4 04/23] mtd: nand: denali: avoid hard-coding ECC step, strength, bytes

This driver was originally written for the Intel MRST platform with several platform-specific parameters hard-coded. Currently, the ECC settings are hard-coded as follows: #define ECC_SECTOR_SIZE 512 #define ECC_8BITS 14 #define ECC_15BITS 26 Therefore, the driver can only

[PATCH v4 04/23] mtd: nand: denali: avoid hard-coding ECC step, strength, bytes

This driver was originally written for the Intel MRST platform with several platform-specific parameters hard-coded. Currently, the ECC settings are hard-coded as follows: #define ECC_SECTOR_SIZE 512 #define ECC_8BITS 14 #define ECC_15BITS 26 Therefore, the driver can only

[PATCH v4 12/23] mtd: nand: denali: fix NAND_CMD_STATUS handling

The current NAND_CMD_STATUS handling is weird; it just reads the WRITE_PROTECT register, and returns NAND_STATUS_WP if it is set. It does not send Read Status (0x70) command, so it is not helpful for checking the current device status. Signed-off-by: Masahiro Yamada

[PATCH v4 23/23] mtd: nand: denali: enable bad block table scan

Now this driver is ready to remove NAND_SKIP_BBTSCAN. The BBT descriptors in denali.c are equivalent to the ones in nand_bbt.c. There is no need to duplicate the equivalent structures. The with-oob decriptors do not work for this driver anyway. The bbt_pattern (offs = 8) and the version

[PATCH v4 12/23] mtd: nand: denali: fix NAND_CMD_STATUS handling

The current NAND_CMD_STATUS handling is weird; it just reads the WRITE_PROTECT register, and returns NAND_STATUS_WP if it is set. It does not send Read Status (0x70) command, so it is not helpful for checking the current device status. Signed-off-by: Masahiro Yamada --- Changes in v4: None

[PATCH v4 23/23] mtd: nand: denali: enable bad block table scan

Now this driver is ready to remove NAND_SKIP_BBTSCAN. The BBT descriptors in denali.c are equivalent to the ones in nand_bbt.c. There is no need to duplicate the equivalent structures. The with-oob decriptors do not work for this driver anyway. The bbt_pattern (offs = 8) and the version

[PATCH v4 03/23] mtd: nand: add generic helpers to check, match, maximize ECC settings

Driver are responsible for setting up ECC parameters correctly. Those include: - Check if ECC parameters specified (usually by DT) are valid - Meet the chip's ECC requirement - Maximize ECC strength if NAND_ECC_MAXIMIZE flag is set The logic can be generalized by factoring out common code.

[PATCH v4 03/23] mtd: nand: add generic helpers to check, match, maximize ECC settings

Driver are responsible for setting up ECC parameters correctly. Those include: - Check if ECC parameters specified (usually by DT) are valid - Meet the chip's ECC requirement - Maximize ECC strength if NAND_ECC_MAXIMIZE flag is set The logic can be generalized by factoring out common code.

[PATCH v4 21/23] mtd: nand: denali: skip driver internal bounce buffer when possible

For ecc->read_page() and ecc->write_page(), it is possible to call dma_map_single() against the given buffer. This bypasses the driver internal bounce buffer and save the memcpy(). Signed-off-by: Masahiro Yamada --- Changes in v4: - Remove dma_unmap_single()

[PATCH v4 11/23] mtd: nand: denali: rework interrupt handling

Simplify the interrupt handling and fix issues: - The register field view of INTR_EN / INTR_STATUS is different among IP versions. The global macro DENALI_IRQ_ALL is hard-coded for Intel platforms. The interrupt mask should be determined at run-time depending on the running platform. -

[PATCH v4 18/23] mtd: nand: denali: merge struct nand_buf into struct denali_nand_info

Now struct nand_buf has only two members, so I see no reason for the separation. Signed-off-by: Masahiro Yamada --- Changes in v4: None Changes in v3: None Changes in v2: - Newly added drivers/mtd/nand/denali.c | 29 ++---

[PATCH v4 11/23] mtd: nand: denali: rework interrupt handling

Simplify the interrupt handling and fix issues: - The register field view of INTR_EN / INTR_STATUS is different among IP versions. The global macro DENALI_IRQ_ALL is hard-coded for Intel platforms. The interrupt mask should be determined at run-time depending on the running platform. -

[PATCH v4 18/23] mtd: nand: denali: merge struct nand_buf into struct denali_nand_info

Now struct nand_buf has only two members, so I see no reason for the separation. Signed-off-by: Masahiro Yamada --- Changes in v4: None Changes in v3: None Changes in v2: - Newly added drivers/mtd/nand/denali.c | 29 ++--- drivers/mtd/nand/denali.h | 8 ++-- 2

[PATCH v4 21/23] mtd: nand: denali: skip driver internal bounce buffer when possible

For ecc->read_page() and ecc->write_page(), it is possible to call dma_map_single() against the given buffer. This bypasses the driver internal bounce buffer and save the memcpy(). Signed-off-by: Masahiro Yamada --- Changes in v4: - Remove dma_unmap_single() from denali_remove() Changes in

[PATCH v4 20/23] mtd: nand: denali: fix raw and oob accessors for syndrome page layout

The Denali IP adopts the syndrome page layout; payload and ECC are interleaved, with BBM area always placed at the beginning of OOB. The figure below shows the page organization for ecc->steps == 2: |||---| ||| | ||

[PATCH v4 20/23] mtd: nand: denali: fix raw and oob accessors for syndrome page layout

The Denali IP adopts the syndrome page layout; payload and ECC are interleaved, with BBM area always placed at the beginning of OOB. The figure below shows the page organization for ecc->steps == 2: |||---| ||| | ||

[PATCH v4 22/23] mtd: nand: denali: use non-managed kmalloc() for DMA buffer

As Russell and Lars stated in the discussion [1], using devm_k*alloc() with DMA is not a good idea. Let's use kmalloc (not kzalloc because no need for zero-out). Also, allocate the buffer as late as possible because it must be freed for any error that follows. [1]

[PATCH v4 22/23] mtd: nand: denali: use non-managed kmalloc() for DMA buffer

As Russell and Lars stated in the discussion [1], using devm_k*alloc() with DMA is not a good idea. Let's use kmalloc (not kzalloc because no need for zero-out). Also, allocate the buffer as late as possible because it must be freed for any error that follows. [1]

[PATCH v4 14/23] mtd: nand: denali: switch over to cmd_ctrl instead of cmdfunc

The NAND_CMD_SET_FEATURES support is missing from denali_cmdfunc(). This is needed for nand_onfi_set_features(). Besides, we see /* TODO: Read OOB data */ comment line. It would be possible to add more commands along with the current implementation, but having ->cmd_ctrl() seems a better

[PATCH v4 14/23] mtd: nand: denali: switch over to cmd_ctrl instead of cmdfunc

The NAND_CMD_SET_FEATURES support is missing from denali_cmdfunc(). This is needed for nand_onfi_set_features(). Besides, we see /* TODO: Read OOB data */ comment line. It would be possible to add more commands along with the current implementation, but having ->cmd_ctrl() seems a better

[PATCH] net: ethernet: ti: cpdma: do not enable host error misc irq

CPSW driver does not handle this interrupt, so there are no reasons to enable it in hardware. Signed-off-by: Grygorii Strashko --- drivers/net/ethernet/ti/davinci_cpdma.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[PATCH] net: ethernet: ti: cpdma: do not enable host error misc irq

CPSW driver does not handle this interrupt, so there are no reasons to enable it in hardware. Signed-off-by: Grygorii Strashko --- drivers/net/ethernet/ti/davinci_cpdma.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c

[PATCH] cpsw: cpts: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter

CPSW driver supports PTP v1 messages, but for unknown reasons this filter is not advertised. As result, ./tools/testing/selftests/networking/timestamping/timestamping utility can't be used for testing of CPSW RX timestamping with option SOF_TIMESTAMPING_RX_HARDWARE, because it uses

[PATCH] cpsw: cpts: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter

CPSW driver supports PTP v1 messages, but for unknown reasons this filter is not advertised. As result, ./tools/testing/selftests/networking/timestamping/timestamping utility can't be used for testing of CPSW RX timestamping with option SOF_TIMESTAMPING_RX_HARDWARE, because it uses

Re: [PATCH RFC v2 5/8] security/keys: ensure RNG is seeded before use

On Mon, Jun 5, 2017 at 5:47 AM, Jason A. Donenfeld wrote: > - get_random_bytes(>serial, sizeof(key->serial)); > + ret = get_random_bytes_wait(>serial, > sizeof(key->serial)); This actually isn't okay at bootup, but I've got a different change for

Re: [PATCH RFC v2 5/8] security/keys: ensure RNG is seeded before use

On Mon, Jun 5, 2017 at 5:47 AM, Jason A. Donenfeld wrote: > - get_random_bytes(>serial, sizeof(key->serial)); > + ret = get_random_bytes_wait(>serial, > sizeof(key->serial)); This actually isn't okay at bootup, but I've got a different change for this section that

<    1   2   3   4   5   6   7   8   9   10   >