Hi Marc,
On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai wrote:
> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng wrote:
>>
>>
>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier 写到:
>>>On 18/05/17 08:16, Icenowy Zheng wrote:
Add support
Hi Marc,
On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai wrote:
> On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng wrote:
>>
>>
>> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier 写到:
>>>On 18/05/17 08:16, Icenowy Zheng wrote:
Add support for the newly imported compatible for the A64 R_INTC in
On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote:
> Through the new interface restore_kexec_list, it will be possible
> to restore a measurements list, previously read from
> binary_kexec_runtime_measurements.
For development, this was fine. You were able to save and restore the
On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote:
> Through the new interface restore_kexec_list, it will be possible
> to restore a measurements list, previously read from
> binary_kexec_runtime_measurements.
For development, this was fine. You were able to save and restore the
Hi Roberto,
On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote:
> ima_parse_buf() takes as input the buffer start and end pointers, and
> stores the result in a static array of ima_field_data structures,
> where the len field contains the length parsed from the buffer, and
> the data field
Hi Roberto,
On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote:
> ima_parse_buf() takes as input the buffer start and end pointers, and
> stores the result in a static array of ima_field_data structures,
> where the len field contains the length parsed from the buffer, and
> the data field
Balbir Singh writes:
> On Mon, May 29, 2017 at 6:00 PM, Christophe LEROY
> wrote:
>> Le 25/05/2017 à 18:45, kbuild test robot a écrit :
>>> All errors (new ones prefixed by >>):
>>>
> kernel//power/snapshot.c:40:28: fatal error:
Balbir Singh writes:
> On Mon, May 29, 2017 at 6:00 PM, Christophe LEROY
> wrote:
>> Le 25/05/2017 à 18:45, kbuild test robot a écrit :
>>> All errors (new ones prefixed by >>):
>>>
> kernel//power/snapshot.c:40:28: fatal error: asm/set_memory.h: No such
> file or directory
>>>
>>>
On Sun, Jun 04, 2017 at 12:36:48PM +0200, Johannes Thumshirn wrote:
> Allow overriding the announced NVMe Version of a via configfs.
>
> This is particularly helpful when debugging new features for the host
> or target side without bumping the hard coded version (as the target
> might not be
On Sun, Jun 04, 2017 at 12:36:48PM +0200, Johannes Thumshirn wrote:
> Allow overriding the announced NVMe Version of a via configfs.
>
> This is particularly helpful when debugging new features for the host
> or target side without bumping the hard coded version (as the target
> might not be
On Sun, Jun 04, 2017 at 06:04:53PM +0800, joeyli wrote:
> Hi Andy,
>
> Thanks for your help to review my patch.
>
> On Sat, Jun 03, 2017 at 08:37:51PM +0300, Andy Shevchenko wrote:
> > On Sat, Jun 3, 2017 at 8:20 PM, Lee, Chun-Yi
> > wrote:
> > > In hotplug logic, it
On Sun, Jun 04, 2017 at 06:04:53PM +0800, joeyli wrote:
> Hi Andy,
>
> Thanks for your help to review my patch.
>
> On Sat, Jun 03, 2017 at 08:37:51PM +0300, Andy Shevchenko wrote:
> > On Sat, Jun 3, 2017 at 8:20 PM, Lee, Chun-Yi
> > wrote:
> > > In hotplug logic, it always indicates
Hi Boris,
Thank you very much for your detailed review.
I just comming back from busy week for conference and started to look it.
I have a question regarding to the following comment.
>> static int toshiba_nand_init(struct nand_chip *chip)
>> {
>> +struct mtd_info *mtd =
> + }
> + len = NVME_NIDT_UUID_LEN;
> + memcpy(ns->uuid, data + pos + sizeof(*cur), len);
> + break;
> + default:
> + dev_warn(ns->ctrl->dev,
> + "Invalid
On Tue, May 30, 2017 at 07:11:19PM +0300, Leonard Crestez wrote:
> Suspend and resume on imx6ull is currenty not working because of some
> missed checks where behavior should match imx6ul.
>
> Signed-off-by: Leonard Crestez
> ---
> arch/arm/mach-imx/mxc.h | 6 ++
> + }
> + len = NVME_NIDT_UUID_LEN;
> + memcpy(ns->uuid, data + pos + sizeof(*cur), len);
> + break;
> + default:
> + dev_warn(ns->ctrl->dev,
> + "Invalid
On Tue, May 30, 2017 at 07:11:19PM +0300, Leonard Crestez wrote:
> Suspend and resume on imx6ull is currenty not working because of some
> missed checks where behavior should match imx6ul.
>
> Signed-off-by: Leonard Crestez
> ---
> arch/arm/mach-imx/mxc.h | 6 ++
>
Hi Boris,
Thank you very much for your detailed review.
I just comming back from busy week for conference and started to look it.
I have a question regarding to the following comment.
>> static int toshiba_nand_init(struct nand_chip *chip)
>> {
>> +struct mtd_info *mtd =
I think this needs to zero the remainder of the 4k
buffer, quoting the spec:
"The controller may return any number of variable length Namespace
Identification Descriptor structures that fit into the 4096 byte Identify
payload. All remaining bytes after the namespace identification descriptor
I think this needs to zero the remainder of the 4k
buffer, quoting the spec:
"The controller may return any number of variable length Namespace
Identification Descriptor structures that fit into the 4096 byte Identify
payload. All remaining bytes after the namespace identification descriptor
Fix inconsistent format and spelling in hash tests error messages.
Signed-off-by: Gilad Ben-Yossef
---
crypto/testmgr.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6f5f3ed..8c68c99 100644
Fix inconsistent format and spelling in hash tests error messages.
Signed-off-by: Gilad Ben-Yossef
---
crypto/testmgr.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6f5f3ed..8c68c99 100644
--- a/crypto/testmgr.c
On Sun, Jun 04, 2017 at 05:59:06PM +0300, Sagi Grimberg wrote:
>> +struct nvme_ns_identifier_hdr {
>> +__u8 nidt;
>> +__u8 nidl;
>> +__le16 reserved;
>> +};
>
> Nit: _hdr is usually associated with a message or alike.
>
> Maybe nvme_ns_id_desc is more consistent with the spec
On Sun, Jun 04, 2017 at 05:59:06PM +0300, Sagi Grimberg wrote:
>> +struct nvme_ns_identifier_hdr {
>> +__u8 nidt;
>> +__u8 nidl;
>> +__le16 reserved;
>> +};
>
> Nit: _hdr is usually associated with a message or alike.
>
> Maybe nvme_ns_id_desc is more consistent with the spec
On Sun, Jun 04, 2017 at 12:36:41PM +0200, Johannes Thumshirn wrote:
> The Namespace Identification Descriptor list is the only way a target
> can identify itself via the newly introduced UUID to the host (instead
> of the EUI-64 or NGUID).
s/instead/in addition/
> While I was already touching
On Sun, Jun 04, 2017 at 12:36:41PM +0200, Johannes Thumshirn wrote:
> The Namespace Identification Descriptor list is the only way a target
> can identify itself via the newly introduced UUID to the host (instead
> of the EUI-64 or NGUID).
s/instead/in addition/
> While I was already touching
What about a little helper like this: ?
static u16 nvmet_copy_ns_identifier(struct nvmet_req *req, u8 type, u8 len,
void *id, off_t *off)
{
struct nvme_ns_identifier_hdr hdr = {
.nidt = type,
.nidl = len,
};
u16 status;
What about a little helper like this: ?
static u16 nvmet_copy_ns_identifier(struct nvmet_req *req, u8 type, u8 len,
void *id, off_t *off)
{
struct nvme_ns_identifier_hdr hdr = {
.nidt = type,
.nidl = len,
};
u16 status;
On 5/31/2017 18:50, Jani Nikula wrote:
From: Chris Wilson
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 0011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e]
On 5/31/2017 18:50, Jani Nikula wrote:
From: Chris Wilson
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 0011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454]
Hi.
2017-05-23 22:34 GMT+09:00 Javier Martinez Canillas :
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device
Hi.
2017-05-23 22:34 GMT+09:00 Javier Martinez Canillas :
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when
[CC Andrew]
On Sun 04-06-17 13:01:09, Yu Zhao wrote:
> Saw need_resched() warnings when swapping on large swapfile (TBs)
> because continuously allocating many pages in swap_cgroup_prepare()
> took too long.
>
> We already cond_resched when freeing page in swap_cgroup_swapoff().
> Do the same
[CC Andrew]
On Sun 04-06-17 13:01:09, Yu Zhao wrote:
> Saw need_resched() warnings when swapping on large swapfile (TBs)
> because continuously allocating many pages in swap_cgroup_prepare()
> took too long.
>
> We already cond_resched when freeing page in swap_cgroup_swapoff().
> Do the same
On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins
I exercised this patch on an
On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins
I exercised this patch on an AST2500-based machine. The results
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
include/uapi/linux/tty.h
between commit:
8a8dabf2dd68 ("tty: handle the case where we cannot restore a line
discipline")
from the tty tree and commit:
1ab92da32e37 ("staging: speakup: add tty-based comms
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
include/uapi/linux/tty.h
between commit:
8a8dabf2dd68 ("tty: handle the case where we cannot restore a line
discipline")
from the tty tree and commit:
1ab92da32e37 ("staging: speakup: add tty-based comms
On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote:
> The Aspeed 24XX/25XX chips share a single hardware interrupt across 14
> separate I2C busses. This adds a dummy irqchip which maps the single
> hardware interrupt to software interrupts for each of the busses.
>
> Signed-off-by: Brendan
On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote:
> The Aspeed 24XX/25XX chips share a single hardware interrupt across 14
> separate I2C busses. This adds a dummy irqchip which maps the single
> hardware interrupt to software interrupts for each of the busses.
>
> Signed-off-by: Brendan
This is just in case. While it works, I consider it to be diagnostic
data for those unfortunate enough to be intimate with tty locking :)
---
V1 (925bb1ce47f4) changelog:
tty_insert_flip_string_fixed_flag() is racy against itself when called
from the ioctl(TCXONC, TCION/TCIOFF) path [1] and the
This is just in case. While it works, I consider it to be diagnostic
data for those unfortunate enough to be intimate with tty locking :)
---
V1 (925bb1ce47f4) changelog:
tty_insert_flip_string_fixed_flag() is racy against itself when called
from the ioctl(TCXONC, TCION/TCIOFF) path [1] and the
Mon, Jun 05, 2017 at 02:57:21AM CEST, yanhaishu...@cmss.chinamobile.com wrote:
>We must free allocated skb when genlmsg_put() return fails.
>
>Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)")
>Signed-off-by: Haishuang Yan
Acked-by: Jiri Pirko
Mon, Jun 05, 2017 at 02:57:21AM CEST, yanhaishu...@cmss.chinamobile.com wrote:
>We must free allocated skb when genlmsg_put() return fails.
>
>Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)")
>Signed-off-by: Haishuang Yan
Acked-by: Jiri Pirko
Thanks.
On Tue, May 30, 2017 at 06:25:52PM +0200, Johan Hovold wrote:
> In an attempt to work around a pinmux over-allocation issue in driver
> core, commit dc5878abf49c ("usb: core: move root hub's device node
> assignment after it is added to bus") moved the device-tree node
> assignment until after the
On Tue, May 30, 2017 at 06:25:52PM +0200, Johan Hovold wrote:
> In an attempt to work around a pinmux over-allocation issue in driver
> core, commit dc5878abf49c ("usb: core: move root hub's device node
> assignment after it is added to bus") moved the device-tree node
> assignment until after the
Sun, Jun 04, 2017 at 11:44:13PM CEST, sudipm.mukher...@gmail.com wrote:
>The build of mips ar7_defconfig was failing with the error:
>../net/sched/act_api.c: In function 'tcf_action_goto_chain_init':
>../net/sched/act_api.c:37:18: error:
> implicit declaration of function 'tcf_chain_get'
>
Sun, Jun 04, 2017 at 11:44:13PM CEST, sudipm.mukher...@gmail.com wrote:
>The build of mips ar7_defconfig was failing with the error:
>../net/sched/act_api.c: In function 'tcf_action_goto_chain_init':
>../net/sched/act_api.c:37:18: error:
> implicit declaration of function 'tcf_chain_get'
>
On 17-05-17, 12:32, Viresh Kumar wrote:
> Hi,
>
> Here is the 7th version of the series and it looks very different from
> whatever is sent until now. Almost a rewrite.
Gentle reminder as 3 weeks have passed since this was last posted :)
@Kevin/Ulf: Any inputs ?
--
viresh
On 17-05-17, 12:32, Viresh Kumar wrote:
> Hi,
>
> Here is the 7th version of the series and it looks very different from
> whatever is sent until now. Almost a rewrite.
Gentle reminder as 3 weeks have passed since this was last posted :)
@Kevin/Ulf: Any inputs ?
--
viresh
On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins
wrote:
> Added device tree binding documentation for Aspeed I2C busses.
>
> Signed-off-by: Brendan Higgins
> Acked-by: Rob Herring
Acked-by: Joel Stanley
On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins
wrote:
> Added device tree binding documentation for Aspeed I2C busses.
>
> Signed-off-by: Brendan Higgins
> Acked-by: Rob Herring
Acked-by: Joel Stanley
On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins
wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins
Reviewed-by:
On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins
wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins
Reviewed-by: Joel Stanley
I have also tested this on an
Now that the R_CCU device tree binding headers have been merged, we
can convert the raw number references in the device trees to use the
defined macros.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 8 +---
1 file changed, 5 insertions(+), 3
The A64 device tree file has some remnants of raw number references
to the CCU node, likely from when the CCU bindings and device tree
changes were first merged.
Convert these, and the R_CCU ones, to use the proper defined macros
from their respective device tree binding header files.
Hi Maxime,
These are some clean up patches for 4.12. They convert raw number
references for the CCU and R_CCU nodes, from when the CCU/R_CCU stuff
was first added, to the defined macros in the device tree header files.
These affect the A64 and H3/H5.
These are based on our sunxi/fixes-for-4.12
The A64 device tree file has some remnants of raw number references
to the CCU node, likely from when the CCU bindings and device tree
changes were first merged.
Convert these, and the R_CCU ones, to use the proper defined macros
from their respective device tree binding header files.
Hi Maxime,
These are some clean up patches for 4.12. They convert raw number
references for the CCU and R_CCU nodes, from when the CCU/R_CCU stuff
was first added, to the defined macros in the device tree header files.
These affect the A64 and H3/H5.
These are based on our sunxi/fixes-for-4.12
Now that the R_CCU device tree binding headers have been merged, we
can convert the raw number references in the device trees to use the
defined macros.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events
>
> The input stack already filters out the LID events. So instead of
> filtering them out at the source, we can hook up after the input
>
Hi, Benjamin
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events
>
> The input stack already filters out the LID events. So instead of
> filtering them out at the source, we can hook up after the input
>
2017-04-26 22:56 GMT+08:00 Paolo Bonzini :
> native_safe_halt enables interrupts, and you just shouldn't
> call rcu_irq_enter() with interrupts enabled. Reorder the
> call with the following local_irq_disable() to respect the
> invariant.
>
> Reported-by: Ross Zwisler
2017-04-26 22:56 GMT+08:00 Paolo Bonzini :
> native_safe_halt enables interrupts, and you just shouldn't
> call rcu_irq_enter() with interrupts enabled. Reorder the
> call with the following local_irq_disable() to respect the
> invariant.
>
> Reported-by: Ross Zwisler
> Cc:
The driver may sleep under a write spin lock, and the function
call path is:
cachefiles_mark_object_active (acquire the lock by write_lock)
cachefiles_printk_object
kmalloc(GFP_NOIO) --> may sleep
cachefiles_mark_object_buried (acquire the lock by write_lock)
cachefiles_printk_object
The driver may sleep under a write spin lock, and the function
call path is:
cachefiles_mark_object_active (acquire the lock by write_lock)
cachefiles_printk_object
kmalloc(GFP_NOIO) --> may sleep
cachefiles_mark_object_buried (acquire the lock by write_lock)
cachefiles_printk_object
Hi RT Devs,
I enabled cpu/cpuacct/cpuset/devices/freezer subsystems in cgroup.
Attach serveral thread ids to these systems' tasks file frequently
last 4 or 5 hours(start process, echo thread ids to tasks, stop
process). The system will hung, no response to user keyboard input.
Through I have
Hi RT Devs,
I enabled cpu/cpuacct/cpuset/devices/freezer subsystems in cgroup.
Attach serveral thread ids to these systems' tasks file frequently
last 4 or 5 hours(start process, echo thread ids to tasks, stop
process). The system will hung, no response to user keyboard input.
Through I have
Follow the recent trend for the license description, and fix the wrongly
stated X11 to MIT.
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
Follow the recent trend for the license description, and fix the wrongly
stated X11 to MIT.
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
Follow the recent trend for the license description, and fix the wrongly
stated X11 to MIT.
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
Follow the recent trend for the license description, and fix the wrongly
stated X11 to MIT.
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
Hi Finley,
On 2017/5/12 10:44, Finley Xiao wrote:
This adds the necessary data for handling eFuse on the rk322x.
Signed-off-by: Finley Xiao
---
Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 1 +
drivers/nvmem/rockchip-efuse.c
Hi Finley,
On 2017/5/12 10:44, Finley Xiao wrote:
This adds the necessary data for handling eFuse on the rk322x.
Signed-off-by: Finley Xiao
---
Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 1 +
drivers/nvmem/rockchip-efuse.c | 4
2 files
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
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
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).
Signed-off-by: Jason A. Donenfeld
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).
Signed-off-by: Jason A. Donenfeld
Cc:
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
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
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
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
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
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
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
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
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
---
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
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
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
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
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 +++--
The driver may sleep under a spin lock, and the function call path is:
ubifs_change_lp (acquire the lock by spin_lock)
change_category
ubifs_remove_from_cat
remove_from_lpt_heap
dbg_check_heap
ubifs_lpt_lookup
ubifs_get_pnode
read_pnode
The driver may sleep under a spin lock, and the function call path is:
ubifs_change_lp (acquire the lock by spin_lock)
change_category
ubifs_remove_from_cat
remove_from_lpt_heap
dbg_check_heap
ubifs_lpt_lookup
ubifs_get_pnode
read_pnode
for SPI controllers on imx53 and later SoCs, there is HW issue when
work in slave mode, as new device type 'IMX53_ECSPI' has been added
for these SPI controllers which is compatible with 'fsl,imx53-ecspi'.
This patch updates DTS to make imx53 later SPI controller only be
compatibile with
for SPI controllers on imx53 and later SoCs, there is HW issue when
work in slave mode, as new device type 'IMX53_ECSPI' has been added
for these SPI controllers which is compatible with 'fsl,imx53-ecspi'.
This patch updates DTS to make imx53 later SPI controller only be
compatibile with
Different ECSPI controller has different fifosize and DMA capability,
instead of calling functions to identify these information by check
devtype. add fifo_size and has_dmamode to spi_imx_devtype_data.
so that these information can be directly accessed.
Signed-off-by: Jiada Wang
Different ECSPI controller has different fifosize and DMA capability,
instead of calling functions to identify these information by check
devtype. add fifo_size and has_dmamode to spi_imx_devtype_data.
so that these information can be directly accessed.
Signed-off-by: Jiada Wang
---
Changes in v3:
* renamed several variables for for better readability
* created spi_imx_pio_transfer_slave() for slave pio transfer
* added fifo_size, has_dmamode and has_slavemode in spi_imx_devtype_data
Changes in v2:
* re-workd i.MX ECSPI controller slave mode support based on Geert's work
ECSPI contorller for iMX53 and iMX6 has few hardware issues
comparing to iMX51.
The change add possibility to detect which controller is used
to apply possible workaround and limitations.
Signed-off-by: Jiada Wang
---
.../devicetree/bindings/spi/fsl-imx-cspi.txt |
1 - 100 of 646 matches
Mail list logo