from -next, could you test
> the -mm tree at git://git.cmpxchg.org/linux-mmots.git and verify that
> this patch below fixes the issue?
Looks like next-20170605 is broken for ARMs again.. And the patch
below does not apply for me against mmots/master or next.
Care to update?
Regards,
Tony
> the -mm tree at git://git.cmpxchg.org/linux-mmots.git and verify that
> this patch below fixes the issue?
Looks like next-20170605 is broken for ARMs again.. And the patch
below does not apply for me against mmots/master or next.
Care to update?
Regards,
Tony
Hi all,
Changes since 20170605:
The clk tree lost its build failure.
The net-next tree gained a conflict against the net tree.
The mfd tree lost its build failure.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge commits (relative to Linus' tree
Hi all,
Changes since 20170605:
The clk tree lost its build failure.
The net-next tree gained a conflict against the net tree.
The mfd tree lost its build failure.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge commits (relative to Linus' tree
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
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
Hi Mario
thanks for your tests, and, at first glance, your patches seem to be
sensible so,
please, send the changes as patches for net.git kernel.
Regards
Peppe
On 6/6/2017 12:11 AM, Mario Molitor wrote:
Dear stmmac maintainer group,
I have found an problem in stmmac driver of linux
Hi Mario
thanks for your tests, and, at first glance, your patches seem to be
sensible so,
please, send the changes as patches for net.git kernel.
Regards
Peppe
On 6/6/2017 12:11 AM, Mario Molitor wrote:
Dear stmmac maintainer group,
I have found an problem in stmmac driver of linux
On 2017-06-02 13:09, Han Xu wrote:
> On 06/01/2017 08:48 PM, Stefan Agner wrote:
>> Hi Han,
>>
>> On 2017-06-01 14:14, Han Xu wrote:
>>> On 06/01/2017 02:20 PM, Stefan Agner wrote:
This are the missing device tree parts to add NAND support for i.MX 7.
See previous patchset:
On 2017-06-02 13:09, Han Xu wrote:
> On 06/01/2017 08:48 PM, Stefan Agner wrote:
>> Hi Han,
>>
>> On 2017-06-01 14:14, Han Xu wrote:
>>> On 06/01/2017 02:20 PM, Stefan Agner wrote:
This are the missing device tree parts to add NAND support for i.MX 7.
See previous patchset:
On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote:
> These functions are simple convenience wrappers that call
> wait_for_random_bytes before calling the respective get_random_*
> function.
It may be advantageous to add a timeout, too.
There's been a number of times I
On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote:
> These functions are simple convenience wrappers that call
> wait_for_random_bytes before calling the respective get_random_*
> function.
It may be advantageous to add a timeout, too.
There's been a number of times I did not want to
+++ Corentin Labbe [02/06/17 14:05 +0200]:
This patch fix the following warning:
kernel/module.c: In function 'add_usage_links':
kernel/module.c:1653:6: warning: variable 'nowarn' set but not used
[-Wunused-but-set-variable]
int nowarn;
Signed-off-by: Corentin Labbe
+++ Corentin Labbe [02/06/17 14:05 +0200]:
This patch fix the following warning:
kernel/module.c: In function 'add_usage_links':
kernel/module.c:1653:6: warning: variable 'nowarn' set but not used
[-Wunused-but-set-variable]
int nowarn;
Signed-off-by: Corentin Labbe
---
kernel/module.c | 13
On 06/02/2017 04:11 PM, Arnaldo Carvalho de Melo wrote:
[]
>>
>> If you have specific patches in Jiri's branch that you think are good to
>> go, just point me to them and I'll cherry-pick them.
>>
>> I'm looking now at the one you pointed out above (070b9644981e).
>
> Just looked, but the
On 06/02/2017 04:11 PM, Arnaldo Carvalho de Melo wrote:
[]
>>
>> If you have specific patches in Jiri's branch that you think are good to
>> go, just point me to them and I'll cherry-pick them.
>>
>> I'm looking now at the one you pointed out above (070b9644981e).
>
> Just looked, but the
On Thu, 01 Jun 2017 02:00:22 PDT (-0700), Arnd Bergmann wrote:
> On Thu, Jun 1, 2017 at 2:56 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 05:55:15 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
>
>
On Fri, 26 May 2017 02:06:58 PDT (-0700), Arnd Bergmann wrote:
> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 04:19:42 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
>
>>> Also,
On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote:
> On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 04:30:50 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
RISC-V
On Fri, 26 May 2017 02:06:58 PDT (-0700), Arnd Bergmann wrote:
> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 04:19:42 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
>
>>> Also, it would be good to replace the
On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote:
> On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 04:30:50 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
RISC-V has both 32-bit and 64-bit base ISAs,
On Thu, 01 Jun 2017 02:00:22 PDT (-0700), Arnd Bergmann wrote:
> On Thu, Jun 1, 2017 at 2:56 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 05:55:15 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
>
>
+#ifndef _ASM_RISCV_CACHE_H
+#define
On Mon, 29 May 2017 04:17:40 PDT (-0700), Arnd Bergmann wrote:
> On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 04:46:22 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
diff
On Thu, 25 May 2017 12:51:54 PDT (-0700), Arnd Bergmann wrote:
> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote:
>> On Mon, 22 May 2017 19:11:35 PDT (-0700), o...@lixom.net wrote:
>
>> * Parens around single-statement __asm__ macros. For these I also get a
>>
On Mon, 29 May 2017 04:17:40 PDT (-0700), Arnd Bergmann wrote:
> On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt wrote:
>> On Tue, 23 May 2017 04:46:22 PDT (-0700), Arnd Bergmann wrote:
>>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt wrote:
diff --git a/arch/riscv/Kconfig
On Thu, 25 May 2017 12:51:54 PDT (-0700), Arnd Bergmann wrote:
> On Thu, May 25, 2017 at 3:59 AM, Palmer Dabbelt wrote:
>> On Mon, 22 May 2017 19:11:35 PDT (-0700), o...@lixom.net wrote:
>
>> * Parens around single-statement __asm__ macros. For these I also get a
>>message when they're
Defining kexec_purgatory as a zero-length char array upsets compile
time size checking. Since this is built on a per-arch basis, define
it as an unsized char array (like is done for other similar things,
e.g. linker sections). This silences the warning generated by the future
This avoids CONFIG_FORTIFY_SOURCE from being enabled during the EFI stub
build, as adding a panic() implementation may not work well. This can be
adjusted in the future.
Suggested-by: Daniel Micay
Signed-off-by: Kees Cook
Cc; Matt Fleming
Defining kexec_purgatory as a zero-length char array upsets compile
time size checking. Since this is built on a per-arch basis, define
it as an unsized char array (like is done for other similar things,
e.g. linker sections). This silences the warning generated by the future
This avoids CONFIG_FORTIFY_SOURCE from being enabled during the EFI stub
build, as adding a panic() implementation may not work well. This can be
adjusted in the future.
Suggested-by: Daniel Micay
Signed-off-by: Kees Cook
Cc; Matt Fleming
Cc: Ard Biesheuvel
---
Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis
that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE.
Suggested-by: Mark Rutland
Signed-off-by: Kees Cook
Cc: Catalin Marinas
Cc: Will
Adjust vdso_{start|end} to be char arrays to avoid compile-time analysis
that flags "too large" memcmp() calls with CONFIG_FORTIFY_SOURCE.
Suggested-by: Mark Rutland
Signed-off-by: Kees Cook
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Jisheng Zhang
---
arch/arm64/kernel/vdso.c | 10 +-
From: Daniel Micay
Noticed by FORTIFY_SOURCE, this swaps memcpy() for strncpy() to zero-value
fill the end of the buffer instead of over-reading a string from .rodata.
Signed-off-by: Daniel Micay
[kees: wrote commit log]
Signed-off-by: Kees Cook
From: Daniel Micay
Noticed by FORTIFY_SOURCE, this swaps memcpy() for strncpy() to zero-value
fill the end of the buffer instead of over-reading a string from .rodata.
Signed-off-by: Daniel Micay
[kees: wrote commit log]
Signed-off-by: Kees Cook
Cc: Greg Kroah-Hartman
Cc: Wayne Porter
---
This fixes a over-read condition detected by FORTIFY_SOURCE for this line:
memcpy(SKB_TO_PKT(skb), _pkt, sizeof(skb->cb));
The error was:
In file included from ./include/linux/bitmap.h:8:0,
from ./include/linux/cpumask.h:11,
from
This switches the hibernate_64.S function names into character arrays
to match other areas of the kernel where this is done (e.g., linker
scripts). Specifically this fixes a compile-time error noticed by the
future CONFIG_FORTIFY_SOURCE routines that complained about PAGE_SIZE
being copied out of
This fixes a over-read condition detected by FORTIFY_SOURCE for this line:
memcpy(SKB_TO_PKT(skb), _pkt, sizeof(skb->cb));
The error was:
In file included from ./include/linux/bitmap.h:8:0,
from ./include/linux/cpumask.h:11,
from
This switches the hibernate_64.S function names into character arrays
to match other areas of the kernel where this is done (e.g., linker
scripts). Specifically this fixes a compile-time error noticed by the
future CONFIG_FORTIFY_SOURCE routines that complained about PAGE_SIZE
being copied out of
I was originally carrying these patches in my KSPP tree, but akpm
is taking the FORTIFY_SOURCE patch into -mm. As such, these fixes
should be included as well.
-Kees
I was originally carrying these patches in my KSPP tree, but akpm
is taking the FORTIFY_SOURCE patch into -mm. As such, these fixes
should be included as well.
-Kees
Igor Stoppa wrote:
> +int pmalloc_protect_pool(struct pmalloc_pool *pool)
> +{
> + struct pmalloc_node *node;
> +
> + if (!pool)
> + return -EINVAL;
> + mutex_lock(>nodes_list_mutex);
> + hlist_for_each_entry(node, >nodes_list_head, nodes_list) {
> +
Igor Stoppa wrote:
> +int pmalloc_protect_pool(struct pmalloc_pool *pool)
> +{
> + struct pmalloc_node *node;
> +
> + if (!pool)
> + return -EINVAL;
> + mutex_lock(>nodes_list_mutex);
> + hlist_for_each_entry(node, >nodes_list_head, nodes_list) {
> +
On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote:
> Hey Ted,
>
> On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote:
> > Note that crypto_rng_reset() is called by big_key_init() in
> > security/keys/big_key.c as a late_initcall(). So if we are on a
> > system
On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote:
> Hey Ted,
>
> On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote:
> > Note that crypto_rng_reset() is called by big_key_init() in
> > security/keys/big_key.c as a late_initcall(). So if we are on a
> > system where the crng
the node counters because the
> zones have special boot pagesets, whereas the nodes do not.
>
> Add boot nodestats against which we account until the dynamic per-cpu
> allocator is available.
This isn't working for me. I applied it on top of next-20170605, I still
get an oops:
ial boot pagesets, whereas the nodes do not.
>
> Add boot nodestats against which we account until the dynamic per-cpu
> allocator is available.
This isn't working for me. I applied it on top of next-20170605, I still
get an oops:
$ qemu-system-ppc64 -M pseries -m 1G -kernel build/vmlinu
From: Sandeep Tripathy
This patch adds support for Stingray clocks in iproc
ccf. The Stingray SOC has various plls based on iproc
pll architecture.
Signed-off-by: Sandeep Tripathy
Signed-off-by: Anup Patel
From: Sandeep Tripathy
This patch adds support for Stingray clocks in iproc
ccf. The Stingray SOC has various plls based on iproc
pll architecture.
Signed-off-by: Sandeep Tripathy
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/clk/bcm/Kconfig | 8
This patchset adds initial support of Broadcom Stingray SOC
by reusing existing Broadcom iProc device drivers.
Most of the patches in this patchset are DT patches except
the Stingray clock tree support which just one patch.
This patchset is based on Linux-4.12-rc4 and it is also available
at
This patchset adds initial support of Broadcom Stingray SOC
by reusing existing Broadcom iProc device drivers.
Most of the patches in this patchset are DT patches except
the Stingray clock tree support which just one patch.
This patchset is based on Linux-4.12-rc4 and it is also available
at
On Sat, Jun 3, 2017 at 3:40 AM, Stephen Boyd wrote:
> On 06/02, Anup Patel wrote:
>> diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c
>> new file mode 100644
>> index 000..342f702
>> --- /dev/null
>> +++ b/drivers/clk/bcm/clk-sr.c
>> @@ -0,0 +1,320 @@
>>
On Sat, Jun 3, 2017 at 3:40 AM, Stephen Boyd wrote:
> On 06/02, Anup Patel wrote:
>> diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c
>> new file mode 100644
>> index 000..342f702
>> --- /dev/null
>> +++ b/drivers/clk/bcm/clk-sr.c
>> @@ -0,0 +1,320 @@
>> +
>> +static const
Hi,
On Friday 02 June 2017 04:20 PM, Ulf Hansson wrote:
> On 1 June 2017 at 16:33, Kishon Vijay Abraham I wrote:
>> There are the set of fixes that were sent initially as part
>> of [1].
>>
>> These are mostly fixes w.r.t populating regulators in
>> mmc dt node. It was working
Hi,
On Friday 02 June 2017 04:20 PM, Ulf Hansson wrote:
> On 1 June 2017 at 16:33, Kishon Vijay Abraham I wrote:
>> There are the set of fixes that were sent initially as part
>> of [1].
>>
>> These are mostly fixes w.r.t populating regulators in
>> mmc dt node. It was working before because the
Hey Ted,
On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote:
> Note that crypto_rng_reset() is called by big_key_init() in
> security/keys/big_key.c as a late_initcall(). So if we are on a
> system where the crng doesn't get initialized until during the system
> boot scripts,
Hey Ted,
On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote:
> Note that crypto_rng_reset() is called by big_key_init() in
> security/keys/big_key.c as a late_initcall(). So if we are on a
> system where the crng doesn't get initialized until during the system
> boot scripts, and big_key is
+ Daniel
On 05-06-17, 17:07, Tao Wang wrote:
> cpu idle cooling driver performs synchronized idle injection across
> all cpu in same cluster, offers a new method to cooling down cpu,
> that is similar to intel_power_clamp driver, but is basically
> designed for ARM platform.
> Each cluster has
+ Daniel
On 05-06-17, 17:07, Tao Wang wrote:
> cpu idle cooling driver performs synchronized idle injection across
> all cpu in same cluster, offers a new method to cooling down cpu,
> that is similar to intel_power_clamp driver, but is basically
> designed for ARM platform.
> Each cluster has
From: jane@oracle.com
Date: Mon, 5 Jun 2017 20:03:28 -0700
> On sun4v sparc, it looks like kzalloc(64, GFP_KERNEL) ends up
> allocating from kmalloc_caches[6] - a 64-byte kmem-cache allocated
> by kmem_cache_init() with SLAB_HWCACHE_ALIGN flag set, so it's in
> l3-cache-line-size alignment,
From: jane@oracle.com
Date: Mon, 5 Jun 2017 20:03:28 -0700
> On sun4v sparc, it looks like kzalloc(64, GFP_KERNEL) ends up
> allocating from kmalloc_caches[6] - a 64-byte kmem-cache allocated
> by kmem_cache_init() with SLAB_HWCACHE_ALIGN flag set, so it's in
> l3-cache-line-size alignment,
On Tue, Jun 6, 2017 at 7:38 AM, Florian Fainelli wrote:
>
>
> On 06/05/2017 09:51 AM, Florian Fainelli wrote:
>> On 06/01/2017 11:34 PM, Anup Patel wrote:
>>> This patchset adds initial support of Broadcom Stingray SOC
>>> by reusing existing Broadcom iProc device drivers.
On Tue, Jun 6, 2017 at 7:38 AM, Florian Fainelli wrote:
>
>
> On 06/05/2017 09:51 AM, Florian Fainelli wrote:
>> On 06/01/2017 11:34 PM, Anup Patel wrote:
>>> This patchset adds initial support of Broadcom Stingray SOC
>>> by reusing existing Broadcom iProc device drivers.
>>>
>>> Most of the
Many laptops (and maybe servers?) have embedded WMI Binary MOF metadata.
We do not yet have open-source tools for processing the data, although
one is in the works thanks to Pali:
https://github.com/pali/bmfdec
There is currently no interface to get the data in the first place. By
Many laptops (and maybe servers?) have embedded WMI Binary MOF metadata.
We do not yet have open-source tools for processing the data, although
one is in the works thanks to Pali:
https://github.com/pali/bmfdec
There is currently no interface to get the data in the first place. By
Ping~ Willing to hear some feed back :-)
On Tue, May 02, 2017 at 09:04:50PM +0800, Wei Yang wrote:
>My previous patch "x86/mm/numa: Remove numa_nodemask_from_meminfo()" hits a
>problem in numa_emulation. The reason is numa_nodes_parsed is not set
>correctly after emulation.
>
>This patch set
Ping~ Willing to hear some feed back :-)
On Tue, May 02, 2017 at 09:04:50PM +0800, Wei Yang wrote:
>My previous patch "x86/mm/numa: Remove numa_nodemask_from_meminfo()" hits a
>problem in numa_emulation. The reason is numa_nodes_parsed is not set
>correctly after emulation.
>
>This patch set
On 06/06/17 14:41, Chris Packham wrote:
> The #address-cells and #size-cells properties need to be accounted for
> when dealing with the "memory" device tree node.
>
> Signed-off-by: Chris Packham
> ---
> drivers/edac/mv64x60_edac.c | 30
On 06/06/17 14:41, Chris Packham wrote:
> The #address-cells and #size-cells properties need to be accounted for
> when dealing with the "memory" device tree node.
>
> Signed-off-by: Chris Packham
> ---
> drivers/edac/mv64x60_edac.c | 30 +-
> 1 file changed, 21
2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi :
> Add nodes of thermal monitor and thermal zone for UniPhier LD20 SoC.
> The thermal monitor is included in sysctrl.
>
> Furthermore, since SoC installed in the reference board doesn't have a
> calibrated value of
On Mon, May 29, 2017 at 07:45:05PM -0700, Dmitry Torokhov wrote:
> On Sat, May 27, 2017 at 11:40:52AM -0700, Andy Lutomirski wrote:
> > On Sat, May 27, 2017 at 9:17 AM, Dmitry Torokhov
> > wrote:
> > > On May 27, 2017 9:04:38 AM PDT, Andy Lutomirski
2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi :
> Add nodes of thermal monitor and thermal zone for UniPhier LD20 SoC.
> The thermal monitor is included in sysctrl.
>
> Furthermore, since SoC installed in the reference board doesn't have a
> calibrated value of thermal monitor, this patch gives the
On Mon, May 29, 2017 at 07:45:05PM -0700, Dmitry Torokhov wrote:
> On Sat, May 27, 2017 at 11:40:52AM -0700, Andy Lutomirski wrote:
> > On Sat, May 27, 2017 at 9:17 AM, Dmitry Torokhov
> > wrote:
> > > On May 27, 2017 9:04:38 AM PDT, Andy Lutomirski wrote:
> > >>On Sat, May 27, 2017 at 3:50 AM,
On Mon, Jun 05, 2017 at 08:43:43AM +0200, Michal Hocko wrote:
>On Sat 03-06-17 10:24:40, Wei Yang wrote:
>> Hi, Michal
>>
>> Just go through your patch.
>>
>> I have one question and one suggestion as below.
>>
>> One suggestion:
>>
>> This patch does two things to me:
>> 1. Replace
On Mon, Jun 05, 2017 at 08:43:43AM +0200, Michal Hocko wrote:
>On Sat 03-06-17 10:24:40, Wei Yang wrote:
>> Hi, Michal
>>
>> Just go through your patch.
>>
>> I have one question and one suggestion as below.
>>
>> One suggestion:
>>
>> This patch does two things to me:
>> 1. Replace
On 06/05/2017 05:57 PM, David Miller wrote:
From: Jane Chu
Date: Mon, 5 Jun 2017 16:48:31 -0600
Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info()
only allocates a single page for NR_CPUS mondo entries. Thus we cannot
use all 4096 CPUs on some SPARC
On 06/05/2017 05:57 PM, David Miller wrote:
From: Jane Chu
Date: Mon, 5 Jun 2017 16:48:31 -0600
Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info()
only allocates a single page for NR_CPUS mondo entries. Thus we cannot
use all 4096 CPUs on some SPARC platforms.
To fix,
On Thu, Jun 01, 2017 at 10:43:39PM +0200, Michał Kępień wrote:
> I know I have probably started sounding like a broken record by now, but
> I still have not seen any response (apart from the typos getting fixed)
> to my comments on this patch which I posted in January 2016 [1].
>
> None of the
On Thu, Jun 01, 2017 at 10:43:39PM +0200, Michał Kępień wrote:
> I know I have probably started sounding like a broken record by now, but
> I still have not seen any response (apart from the typos getting fixed)
> to my comments on this patch which I posted in January 2016 [1].
>
> None of the
On Tue, Jun 06, 2017 at 02:50:59AM +0200, Jason A. Donenfeld wrote:
> 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
On Tue, Jun 06, 2017 at 02:50:59AM +0200, Jason A. Donenfeld wrote:
> 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(-)
>
On Tue, Jun 6, 2017 at 3:21 AM, Corentin Labbe
wrote:
> This patch add the dt node for the syscon register present on the
> Allwinner A83T
>
> Signed-off-by: Corentin Labbe
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 6 ++
> 1 file
On Tue, Jun 6, 2017 at 3:21 AM, Corentin Labbe
wrote:
> This patch add the dt node for the syscon register present on the
> Allwinner A83T
>
> Signed-off-by: Corentin Labbe
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
On 06/05/2017 03:36 PM, Jay Zhou wrote:
/* enable ucontrol for s390 */
struct kvm_s390_ucas_mapping {
diff --git a/memory.c b/memory.c
index 4c95aaf..b836675 100644
--- a/memory.c
+++ b/memory.c
@@ -809,6 +809,13 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
On 06/05/2017 03:36 PM, Jay Zhou wrote:
/* enable ucontrol for s390 */
struct kvm_s390_ucas_mapping {
diff --git a/memory.c b/memory.c
index 4c95aaf..b836675 100644
--- a/memory.c
+++ b/memory.c
@@ -809,6 +809,13 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi :
> Add devicetree binding documentation for thermal monitor implemented on
> Socionext UniPhier SoCs.
>
> Signed-off-by: Kunihiko Hayashi
> ---
> .../bindings/thermal/uniphier-thermal.txt
2017-05-29 18:15 GMT+09:00 Kunihiko Hayashi :
> Add devicetree binding documentation for thermal monitor implemented on
> Socionext UniPhier SoCs.
>
> Signed-off-by: Kunihiko Hayashi
> ---
> .../bindings/thermal/uniphier-thermal.txt | 54
> ++
> 1 file changed, 54
The #address-cells and #size-cells properties need to be accounted for
when dealing with the "memory" device tree node.
Signed-off-by: Chris Packham
---
drivers/edac/mv64x60_edac.c | 30 +-
1 file changed, 21 insertions(+), 9
The #address-cells and #size-cells properties need to be accounted for
when dealing with the "memory" device tree node.
Signed-off-by: Chris Packham
---
drivers/edac/mv64x60_edac.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git
On Tue, Jun 06, 2017 at 12:19:26AM +0200, Pali Rohár wrote:
> On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
> > On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote:
> > > > metadata. I think that Samba has tools to interpret it, but there
> > > > is currently no interface to get the
On Tue, Jun 06, 2017 at 12:19:26AM +0200, Pali Rohár wrote:
> On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
> > On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote:
> > > > metadata. I think that Samba has tools to interpret it, but there
> > > > is currently no interface to get the
Hi,
If strong pullup is forced (=2) a strong pullup is placed for 750ms.
Is also external power detected the bus will be unlocked and a
additional 750ms sleep is performed.
This 2nd sleep should be avoided.
Kind regards,
Ingo Flaschberger
--- w1_therm.c_org 2017-06-06
Hi,
If strong pullup is forced (=2) a strong pullup is placed for 750ms.
Is also external power detected the bus will be unlocked and a
additional 750ms sleep is performed.
This 2nd sleep should be avoided.
Kind regards,
Ingo Flaschberger
--- w1_therm.c_org 2017-06-06
On Tue, Jun 6, 2017 at 6:41 AM, Daniel Lezcano
wrote:
> On Mon, Jun 05, 2017 at 06:29:53PM +0930, Joel Stanley wrote:
>> On Mon, Jun 5, 2017 at 5:18 PM, Andrew Jeffery wrote:
>> > The merging of a number of clocksource drivers into fttmr010 means we
>>
On Tue, Jun 6, 2017 at 6:41 AM, Daniel Lezcano
wrote:
> On Mon, Jun 05, 2017 at 06:29:53PM +0930, Joel Stanley wrote:
>> On Mon, Jun 5, 2017 at 5:18 PM, Andrew Jeffery wrote:
>> > The merging of a number of clocksource drivers into fttmr010 means we
>> > require clock-names to be specified in
On 06/05/2017 09:51 AM, Florian Fainelli wrote:
> On 06/01/2017 11:34 PM, Anup Patel wrote:
>> This patchset adds initial support of Broadcom Stingray SOC
>> by reusing existing Broadcom iProc device drivers.
>>
>> Most of the patches in this patchset are DT patches except
>> the Stingray clock
On 06/05/2017 09:51 AM, Florian Fainelli wrote:
> On 06/01/2017 11:34 PM, Anup Patel wrote:
>> This patchset adds initial support of Broadcom Stingray SOC
>> by reusing existing Broadcom iProc device drivers.
>>
>> Most of the patches in this patchset are DT patches except
>> the Stingray clock
Hi Boris,
2017-03-31 1:30 GMT+09:00 Boris Brezillon :
> On Thu, 30 Mar 2017 17:15:03 +0900
> Masahiro Yamada wrote:
>
>> Recent versions of this IP support automatic erased page detection.
>> If an erased page is detected on
Hi Boris,
2017-03-31 1:30 GMT+09:00 Boris Brezillon :
> On Thu, 30 Mar 2017 17:15:03 +0900
> Masahiro Yamada wrote:
>
>> Recent versions of this IP support automatic erased page detection.
>> If an erased page is detected on reads, the controller does not set
>> INTR__ECC_UNCOR_ERR, but
On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote:
> On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote:
> > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote:
> > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote:
> > > > On 05/26, Fabien Lahoudere wrote:
> >
On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote:
> On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote:
> > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote:
> > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote:
> > > > On 05/26, Fabien Lahoudere wrote:
> >
1 - 100 of 2202 matches
Mail list logo