On Wed, 25 Jul 2018 13:22:36 -0700
Mark Salyzyn wrote:
> From: Nick Desaulniers
>
> Switch from 0x%lx to 0x%pK to print the kernel addresses.
>
> Fixes: CVE-2017-0630
Wait This breaks perf and trace-cmd! They require this to be able
to print various strings in trace events. This file is
On Wed, 25 Jul 2018 13:22:36 -0700
Mark Salyzyn wrote:
> From: Nick Desaulniers
>
> Switch from 0x%lx to 0x%pK to print the kernel addresses.
>
> Fixes: CVE-2017-0630
Wait This breaks perf and trace-cmd! They require this to be able
to print various strings in trace events. This file is
Hi all,
After merging the rdma tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
net/sunrpc/xprtrdma/svc_rdma_rw.c: In function 'svc_rdma_post_chunk_ctxt':
net/sunrpc/xprtrdma/svc_rdma_rw.c:350:5: warning: 'bad_wr' may be used
uninitialized in this function
Hi all,
After merging the rdma tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
net/sunrpc/xprtrdma/svc_rdma_rw.c: In function 'svc_rdma_post_chunk_ctxt':
net/sunrpc/xprtrdma/svc_rdma_rw.c:350:5: warning: 'bad_wr' may be used
uninitialized in this function
On 7/19/18 3:40 AM, Bruce Merry wrote:
> On 18 July 2018 at 17:49, Shakeel Butt wrote:
>> On Wed, Jul 18, 2018 at 8:37 AM Bruce Merry wrote:
>>> That sounds promising. Is there any way to tell how many zombies there
>>> are, and is there any way to deliberately create zombies? If I can
>>>
On 7/19/18 3:40 AM, Bruce Merry wrote:
> On 18 July 2018 at 17:49, Shakeel Butt wrote:
>> On Wed, Jul 18, 2018 at 8:37 AM Bruce Merry wrote:
>>> That sounds promising. Is there any way to tell how many zombies there
>>> are, and is there any way to deliberately create zombies? If I can
>>>
Hi Mylène,
On Wed, Jul 25, 2018 at 09:34:09AM +0200, Mylène Josserand wrote:
> On resume and suspend, set the value of wake and reset gpios
> to be sure that we are in a know state after suspending/resuming.
>
> Signed-off-by: Mylène Josserand
> ---
> drivers/input/touchscreen/edt-ft5x06.c |
Hi Mylène,
On Wed, Jul 25, 2018 at 09:34:09AM +0200, Mylène Josserand wrote:
> On resume and suspend, set the value of wake and reset gpios
> to be sure that we are in a know state after suspending/resuming.
>
> Signed-off-by: Mylène Josserand
> ---
> drivers/input/touchscreen/edt-ft5x06.c |
There is a potential execution path in which function
platform_get_resource() returns NULL. If this happens,
we will end up having a NULL pointer dereference.
Fix this by replacing devm_ioremap with devm_ioremap_resource,
which has the NULL check and the memory region request.
This code was
Hi Mylène,
On Wed, Jul 25, 2018 at 09:34:08AM +0200, Mylène Josserand wrote:
> Add the support of regulator to use it as VCC source.
>
> Signed-off-by: Mylène Josserand
> Reviewed-by: Rob Herring
> ---
> .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
>
Hi Amit,
On Wed, Jul 18, 2018 at 01:19:17PM +0530, Amit Kucheria wrote:
> One thermal zone per cpu is defined
>
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 170
> +++
> 1 file changed, 170 insertions(+)
>
> diff --git
There is a potential execution path in which function
platform_get_resource() returns NULL. If this happens,
we will end up having a NULL pointer dereference.
Fix this by replacing devm_ioremap with devm_ioremap_resource,
which has the NULL check and the memory region request.
This code was
Hi Mylène,
On Wed, Jul 25, 2018 at 09:34:08AM +0200, Mylène Josserand wrote:
> Add the support of regulator to use it as VCC source.
>
> Signed-off-by: Mylène Josserand
> Reviewed-by: Rob Herring
> ---
> .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
>
Hi Amit,
On Wed, Jul 18, 2018 at 01:19:17PM +0530, Amit Kucheria wrote:
> One thermal zone per cpu is defined
>
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 170
> +++
> 1 file changed, 170 insertions(+)
>
> diff --git
On Fri, 13 Jul 2018 08:18:03 -0400
Steven Rostedt wrote:
> On Fri, 13 Jul 2018 11:53:01 +0900
> Masami Hiramatsu wrote:
>
> > On Thu, 12 Jul 2018 13:54:12 -0400
> > Francis Deslauriers wrote:
> >
> > > From: Masami Hiramatsu
> > >
> > > Prohibit kprobe-events probing on notrace function.
>
On Fri, 13 Jul 2018 08:18:03 -0400
Steven Rostedt wrote:
> On Fri, 13 Jul 2018 11:53:01 +0900
> Masami Hiramatsu wrote:
>
> > On Thu, 12 Jul 2018 13:54:12 -0400
> > Francis Deslauriers wrote:
> >
> > > From: Masami Hiramatsu
> > >
> > > Prohibit kprobe-events probing on notrace function.
>
On 2018-07-24 17:33, Joe Perches wrote:
On Tue, 2018-07-24 at 14:56 -0700, pher...@codeaurora.org wrote:
A reminder to review a few patches I had sent last week. Below are the
links for the patches.
https://lkml.org/lkml/2018/7/5/798
I have no fundamental object to this one, but
the 80
On 2018-07-24 17:33, Joe Perches wrote:
On Tue, 2018-07-24 at 14:56 -0700, pher...@codeaurora.org wrote:
A reminder to review a few patches I had sent last week. Below are the
links for the patches.
https://lkml.org/lkml/2018/7/5/798
I have no fundamental object to this one, but
the 80
On Thu, Jul 19, 2018 at 02:25:21PM -0700, Rishabh Bhatnagar wrote:
> When calling request_firmware_into_buf(), we pass the FW_OPT_NOCACHE
> flag with the intent of skipping the caching mechanism of the
> firmware loader. Unfortunately, that doesn't work, because
> alloc_lookup_fw_priv() isn't told
On Thu, Jul 19, 2018 at 02:25:21PM -0700, Rishabh Bhatnagar wrote:
> When calling request_firmware_into_buf(), we pass the FW_OPT_NOCACHE
> flag with the intent of skipping the caching mechanism of the
> firmware loader. Unfortunately, that doesn't work, because
> alloc_lookup_fw_priv() isn't told
Hi Boris,
On 07/25/2018 05:22 AM, Borislav Petkov wrote:
> On Tue, Jul 24, 2018 at 03:02:13PM -0400, Masayoshi Mizuma wrote:
>> [*] KASAN report is as follows.
>
> That KASAN report is an arbitrary side-effect from the missing segmented
> support so I ripped it out from the commit message and
Hi Boris,
On 07/25/2018 05:22 AM, Borislav Petkov wrote:
> On Tue, Jul 24, 2018 at 03:02:13PM -0400, Masayoshi Mizuma wrote:
>> [*] KASAN report is as follows.
>
> That KASAN report is an arbitrary side-effect from the missing segmented
> support so I ripped it out from the commit message and
Hi Stephen,
On 07/25/2018 06:45 PM, Stephen Boyd wrote:
> Quoting Gustavo A. R. Silva (2018-07-18 18:58:45)
>> There is a potential execution path in which function
>> platform_get_resource() returns NULL. If this happens,
>> we will end up having a NULL pointer dereference.
>>
>> Fix this by
Hi Stephen,
On 07/25/2018 06:45 PM, Stephen Boyd wrote:
> Quoting Gustavo A. R. Silva (2018-07-18 18:58:45)
>> There is a potential execution path in which function
>> platform_get_resource() returns NULL. If this happens,
>> we will end up having a NULL pointer dereference.
>>
>> Fix this by
On 07/25/2018 06:45 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
>> In case memory resources for *fw* were allocated, release them
>> before return.
>>
>> Addresses-Coverity-ID: 1472044 ("Resource leak")
>> Fixes: 6a794a27daca ("fsi:
On 07/25/2018 06:45 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
>> In case memory resources for *fw* were allocated, release them
>> before return.
>>
>> Addresses-Coverity-ID: 1472044 ("Resource leak")
>> Fixes: 6a794a27daca ("fsi:
FYI, we noticed the following commit (built with gcc-7):
commit: 24c944dd64f807542a2ec72744c81f064d1a60da ("ovl: Modify ovl_lookup() and
friends to lookup metacopy dentry")
https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git overlayfs-next
in testcase: boot
on test machine:
FYI, we noticed the following commit (built with gcc-7):
commit: 24c944dd64f807542a2ec72744c81f064d1a60da ("ovl: Modify ovl_lookup() and
friends to lookup metacopy dentry")
https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git overlayfs-next
in testcase: boot
on test machine:
On 07/25/2018 05:03 PM, Stephen Rothwell wrote:
> Hi Matthew,
>
> On Wed, 25 Jul 2018 16:36:21 -0700 Matthew Wilcox wrote:
>>
>> On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
>>>
>>> Commits
>>>
>>> 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
>>>
On 07/25/2018 05:03 PM, Stephen Rothwell wrote:
> Hi Matthew,
>
> On Wed, 25 Jul 2018 16:36:21 -0700 Matthew Wilcox wrote:
>>
>> On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
>>>
>>> Commits
>>>
>>> 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
>>>
Hi Matthew,
On Wed, 25 Jul 2018 16:36:21 -0700 Matthew Wilcox wrote:
>
> On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
> >
> > Commits
> >
> > 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
> > aaf149902c79 ("filesystem-dax: Set page->index")
> >
>
Hi Matthew,
On Wed, 25 Jul 2018 16:36:21 -0700 Matthew Wilcox wrote:
>
> On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
> >
> > Commits
> >
> > 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
> > aaf149902c79 ("filesystem-dax: Set page->index")
> >
>
Hi Linus,
Thanks a lot for your comments.
Sorry for my late reply, I was on vacation.
The last days I have been working to move NPCM pinctrl GPIO to GENERIC
GPIO, most of the work have been done but I had the some issue.
I initialize bgpio as follow:
ret =
Hi Linus,
Thanks a lot for your comments.
Sorry for my late reply, I was on vacation.
The last days I have been working to move NPCM pinctrl GPIO to GENERIC
GPIO, most of the work have been done but I had the some issue.
I initialize bgpio as follow:
ret =
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
While we're here, mark kclist_add() with __init so that we'll get a
warning if
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
While we're here, mark kclist_add() with __init so that we'll get a
warning if
From: Omar Sandoval
Now we only need kclist_lock from user context and at fs init time, and
the following changes need to sleep while holding the kclist_lock.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff
From: Omar Sandoval
Now we only need kclist_lock from user context and at fs init time, and
the following changes need to sleep while holding the kclist_lock.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff
From: Omar Sandoval
Now that we're using an rwsem, we can hold it during the entirety of
read_kcore() and have a common return path. This is preparation for the
next change.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 70 -
1 file
From: Omar Sandoval
Now that we're using an rwsem, we can hold it during the entirety of
read_kcore() and have a common return path. This is preparation for the
next change.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 70 -
1 file
From: Omar Sandoval
The current code does a full search of the segment list every time for
every page. This is wasteful, since it's almost certain that the next
page will be in the same segment. Instead, check if the previous segment
covers the current page before doing the list search.
From: Omar Sandoval
The current code does a full search of the segment list every time for
every page. This is wasteful, since it's almost certain that the next
page will be in the same segment. Instead, check if the previous segment
covers the current page before doing the list search.
From: Omar Sandoval
The memory hotplug notifier kcore_callback() only needs kclist_lock to
prevent races with __kcore_update_ram(), but we can easily eliminate
that race by using an atomic xchg() in __kcore_update_ram(). This is
preparation for converting kclist_lock to an rwsem.
Reviewed-by:
From: Omar Sandoval
Currently, the ELF file header, program headers, and note segment are
allocated all at once, in some icky code dating back to 2.3. Programs
tend to read the file header, then the program headers, then the note
segment, all separately, so this is a waste of effort. It's
From: Omar Sandoval
The memory hotplug notifier kcore_callback() only needs kclist_lock to
prevent races with __kcore_update_ram(), but we can easily eliminate
that race by using an atomic xchg() in __kcore_update_ram(). This is
preparation for converting kclist_lock to an rwsem.
Reviewed-by:
From: Omar Sandoval
Currently, the ELF file header, program headers, and note segment are
allocated all at once, in some icky code dating back to 2.3. Programs
tend to read the file header, then the program headers, then the note
segment, all separately, so this is a waste of effort. It's
From: Omar Sandoval
The vmcoreinfo information is useful for runtime debugging tools, not
just for crash dumps. A lot of this information can be determined by
other means, but this is much more convenient, and it only adds a page
at most to the file.
Signed-off-by: Omar Sandoval
---
From: Omar Sandoval
The vmcoreinfo information is useful for runtime debugging tools, not
just for crash dumps. A lot of this information can be determined by
other means, but this is much more convenient, and it only adds a page
at most to the file.
Signed-off-by: Omar Sandoval
---
From: Omar Sandoval
Hi,
This series makes a few improvements to /proc/kcore. It fixes a couple
of small issues in v3 but is otherwise the same. Patches 1, 2, and 3 are
prep patches. Patch 4 is a fix/cleanup. Patch 5 is another prep patch.
Patches 6 and 7 are optimizations to ->read(). Patch 8
From: Omar Sandoval
This is preparation for allowing CRASH_CORE to be enabled for any
architecture.
swapper_pg_dir is always either an array or a macro expanding to NULL.
In the latter case, VMCOREINFO_SYMBOL() won't work, as it tries to take
the address of the given symbol:
#define
From: Omar Sandoval
There's a theoretical race condition that will cause /proc/kcore to miss
a memory hotplug event:
CPU0 CPU1
// hotplug event 1
kcore_need_update = 1
open_kcore() open_kcore()
kcore_update_ram()
From: Omar Sandoval
Hi,
This series makes a few improvements to /proc/kcore. It fixes a couple
of small issues in v3 but is otherwise the same. Patches 1, 2, and 3 are
prep patches. Patch 4 is a fix/cleanup. Patch 5 is another prep patch.
Patches 6 and 7 are optimizations to ->read(). Patch 8
From: Omar Sandoval
This is preparation for allowing CRASH_CORE to be enabled for any
architecture.
swapper_pg_dir is always either an array or a macro expanding to NULL.
In the latter case, VMCOREINFO_SYMBOL() won't work, as it tries to take
the address of the given symbol:
#define
From: Omar Sandoval
There's a theoretical race condition that will cause /proc/kcore to miss
a memory hotplug event:
CPU0 CPU1
// hotplug event 1
kcore_need_update = 1
open_kcore() open_kcore()
kcore_update_ram()
On Wed, Jul 18, 2018 at 12:55:03PM +0530, Amit Kucheria wrote:
> The current code will always return 0x in case of negative
> temperatures due to a bug in how the binary sign extension is being done.
>
> Use sign_extend32() instead.
>
> Signed-off-by: Amit Kucheria
> ---
>
On Wed, Jul 18, 2018 at 12:55:03PM +0530, Amit Kucheria wrote:
> The current code will always return 0x in case of negative
> temperatures due to a bug in how the binary sign extension is being done.
>
> Use sign_extend32() instead.
>
> Signed-off-by: Amit Kucheria
> ---
>
Quoting Krzysztof Kozlowski (2018-07-25 08:55:15)
> When driver is built as module and DT node contains clocks compatible
> (e.g. "samsung,s2mps11-clk"), the module will not be autoloaded because
> module aliases won't match.
>
> The modalias from uevent: of:NclocksTCsamsung,s2mps11-clk
> The
Quoting Krzysztof Kozlowski (2018-07-25 08:55:15)
> When driver is built as module and DT node contains clocks compatible
> (e.g. "samsung,s2mps11-clk"), the module will not be autoloaded because
> module aliases won't match.
>
> The modalias from uevent: of:NclocksTCsamsung,s2mps11-clk
> The
On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were allocated, release them
> before return.
>
> Addresses-Coverity-ID: 1472044 ("Resource leak")
> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed
> ColdFire")
>
On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were allocated, release them
> before return.
>
> Addresses-Coverity-ID: 1472044 ("Resource leak")
> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed
> ColdFire")
>
Quoting Gustavo A. R. Silva (2018-07-18 18:58:45)
> There is a potential execution path in which function
> platform_get_resource() returns NULL. If this happens,
> we will end up having a NULL pointer dereference.
>
> Fix this by adding asanity check in order to avoid a
> NULL pointer
Quoting Gustavo A. R. Silva (2018-07-18 18:58:45)
> There is a potential execution path in which function
> platform_get_resource() returns NULL. If this happens,
> we will end up having a NULL pointer dereference.
>
> Fix this by adding asanity check in order to avoid a
> NULL pointer
Quoting Andreas Färber (2018-07-22 14:20:10)
> From: Govindraj Raja
>
> The SDHost currently clocks the card 4x slower than it
> should do, because there is a fixed divide by 4 in the
> sdhost wrapper that is not present in the clock tree.
> To model this, add a fixed divide by 4 clock node in
>
Quoting Andreas Färber (2018-07-22 14:20:10)
> From: Govindraj Raja
>
> The SDHost currently clocks the card 4x slower than it
> should do, because there is a fixed divide by 4 in the
> sdhost wrapper that is not present in the clock tree.
> To model this, add a fixed divide by 4 clock node in
>
On 7/25/2018 7:24 PM, Stephen Boyd wrote:
Quoting Marcel Ziswiler (2018-07-20 00:54:22)
From: Marcel Ziswiler
Actually report the error code from devm_regulator_get() which may as
well just be a probe deferral.
Signed-off-by: Marcel Ziswiler
---
drivers/clk/tegra/clk-dfll.c | 5 +++--
On 7/25/2018 7:24 PM, Stephen Boyd wrote:
Quoting Marcel Ziswiler (2018-07-20 00:54:22)
From: Marcel Ziswiler
Actually report the error code from devm_regulator_get() which may as
well just be a probe deferral.
Signed-off-by: Marcel Ziswiler
---
drivers/clk/tegra/clk-dfll.c | 5 +++--
Quoting Saravanan Sekar (2018-07-19 02:06:47)
> Add Actions Semi S700 SoC clock support
>
> Signed-off-by: Parthiban Nallathambi
> Signed-off-by: Saravanan Sekar
> Reviewed-by: Manivannan Sadhasivam
> ---
Applied to clk-next
Quoting Saravanan Sekar (2018-07-19 02:06:47)
> Add Actions Semi S700 SoC clock support
>
> Signed-off-by: Parthiban Nallathambi
> Signed-off-by: Saravanan Sekar
> Reviewed-by: Manivannan Sadhasivam
> ---
Applied to clk-next
Quoting Saravanan Sekar (2018-07-19 02:06:45)
> Add REGMAP_MMIO as dependency to avoid undefined
> reference to regmap symbols.
>
> Fixes: d85d20053e19 ("clk: actions: Add S900 SoC clock support")
> Signed-off-by: Saravanan Sekar
> Reviewed-by: Andreas Färber
> Reviewed-by: Manivannan
Quoting Saravanan Sekar (2018-07-19 02:06:46)
> Add clock bindings constants for action S700
> Maintain common clock dt-bindings for Actions Semi SoC's
> S700 and S900.
>
> Signed-off-by: Parthiban Nallathambi
> Signed-off-by: Saravanan Sekar
> Reviewed-by: Rob Herring
> ---
Applied to
Quoting Saravanan Sekar (2018-07-19 02:06:45)
> Add REGMAP_MMIO as dependency to avoid undefined
> reference to regmap symbols.
>
> Fixes: d85d20053e19 ("clk: actions: Add S900 SoC clock support")
> Signed-off-by: Saravanan Sekar
> Reviewed-by: Andreas Färber
> Reviewed-by: Manivannan
Quoting Saravanan Sekar (2018-07-19 02:06:46)
> Add clock bindings constants for action S700
> Maintain common clock dt-bindings for Actions Semi SoC's
> S700 and S900.
>
> Signed-off-by: Parthiban Nallathambi
> Signed-off-by: Saravanan Sekar
> Reviewed-by: Rob Herring
> ---
Applied to
On Tue, Jul 24, 2018 at 08:09:59PM +0200, Marcus Folkesson wrote:
> Hello Dmitry,
>
> On Tue, Jul 24, 2018 at 02:38:04AM +, Dmitry Torokhov wrote:
> > Hi Marcus,
> >
> > On Mon, Jul 16, 2018 at 04:40:14PM +0200, Marcus Folkesson wrote:
> > > The USB device is only needed during setup, so put
On Tue, Jul 24, 2018 at 08:09:59PM +0200, Marcus Folkesson wrote:
> Hello Dmitry,
>
> On Tue, Jul 24, 2018 at 02:38:04AM +, Dmitry Torokhov wrote:
> > Hi Marcus,
> >
> > On Mon, Jul 16, 2018 at 04:40:14PM +0200, Marcus Folkesson wrote:
> > > The USB device is only needed during setup, so put
On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
> Hi Matthew,
>
> Commits
>
> 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
> aaf149902c79 ("filesystem-dax: Set page->index")
>
> are missing a Signed-off-by from their committers.
Oh, hah. I assume
On Thu, Jul 26, 2018 at 07:28:14AM +1000, Stephen Rothwell wrote:
> Hi Matthew,
>
> Commits
>
> 890e537e2b42 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
> aaf149902c79 ("filesystem-dax: Set page->index")
>
> are missing a Signed-off-by from their committers.
Oh, hah. I assume
page_freeze_refs has already been relplaced by page_ref_freeze, but
it is not modified in the comment.
Signed-off-by: Jiang Biao
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 03822f8..d29e207 100644
--- a/mm/vmscan.c
+++
page_freeze_refs has already been relplaced by page_ref_freeze, but
it is not modified in the comment.
Signed-off-by: Jiang Biao
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 03822f8..d29e207 100644
--- a/mm/vmscan.c
+++
On Wed, Jul 25, 2018 at 12:11:26AM +0900, Tetsuo Handa wrote:
> On 2018/07/19 7:58, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Now that we're using an rwsem, we can hold it during the entirety of
> > read_kcore() and have a common return path. This is preparation for the
> > next
On Wed, Jul 25, 2018 at 12:11:26AM +0900, Tetsuo Handa wrote:
> On 2018/07/19 7:58, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Now that we're using an rwsem, we can hold it during the entirety of
> > read_kcore() and have a common return path. This is preparation for the
> > next
On Thu, Jul 26, 2018 at 01:11:01AM +0200, Jiri Kosina wrote:
> On Wed, 25 Jul 2018, Linus Torvalds wrote:
>
> > > Mitigate userspace-userspace attacks by always unconditionally filling
> > > RSB on
> > > context switch when generic spectrev2 mitigation has been enabled.
> >
> > Shouldn't this
On Thu, Jul 26, 2018 at 01:11:01AM +0200, Jiri Kosina wrote:
> On Wed, 25 Jul 2018, Linus Torvalds wrote:
>
> > > Mitigate userspace-userspace attacks by always unconditionally filling
> > > RSB on
> > > context switch when generic spectrev2 mitigation has been enabled.
> >
> > Shouldn't this
Quoting Keiji Hayashibara (2018-07-18 22:23:48)
> From: Kunihiko Hayashi
>
> Add clock control for SPI controller on UniPhier SoCs.
>
> Signed-off-by: Kunihiko Hayashi
> Signed-off-by: Masahiro Yamada
> ---
Signed-off-by chain is a little weird, but I'll go with it.
Applied to clk-next
Quoting Keiji Hayashibara (2018-07-18 22:23:48)
> From: Kunihiko Hayashi
>
> Add clock control for SPI controller on UniPhier SoCs.
>
> Signed-off-by: Kunihiko Hayashi
> Signed-off-by: Masahiro Yamada
> ---
Signed-off-by chain is a little weird, but I'll go with it.
Applied to clk-next
Hi,
On Tue, Jul 24, 2018 at 4:56 PM, Matthias Kaehlcke wrote:
> The field 'prev_stage' in struct qpnp_tm_chip is not used, remove it.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/thermal/qcom-spmi-temp-alarm.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Douglas Anderson
Hi,
On Tue, Jul 24, 2018 at 4:56 PM, Matthias Kaehlcke wrote:
> The field 'prev_stage' in struct qpnp_tm_chip is not used, remove it.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/thermal/qcom-spmi-temp-alarm.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Douglas Anderson
Quoting Marcel Ziswiler (2018-07-20 00:54:22)
> From: Marcel Ziswiler
>
> Actually report the error code from devm_regulator_get() which may as
> well just be a probe deferral.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/clk/tegra/clk-dfll.c | 5 +++--
> 1 file changed, 3
Quoting Marcel Ziswiler (2018-07-20 00:54:22)
> From: Marcel Ziswiler
>
> Actually report the error code from devm_regulator_get() which may as
> well just be a probe deferral.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/clk/tegra/clk-dfll.c | 5 +++--
> 1 file changed, 3
Hi,
On Tue, Jul 24, 2018 at 4:50 PM, Matthias Kaehlcke wrote:
> The current example for a thermal zone isn't very useful as reference
> since it would result in a hardware shutdown at 145°C, instead of
> allowing the system to try to shutdown gracefully. Without an ADC
> channel a maximum of two
Hi,
On Tue, Jul 24, 2018 at 4:50 PM, Matthias Kaehlcke wrote:
> The current example for a thermal zone isn't very useful as reference
> since it would result in a hardware shutdown at 145°C, instead of
> allowing the system to try to shutdown gracefully. Without an ADC
> channel a maximum of two
Hi,
On Wed, Jul 25, 2018 at 07:48:21AM +1000, NeilBrown wrote:
> On Tue, Jul 24 2018, Brian Norris wrote:
> > On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
> >> On Tue, Jul 24 2018, Boris Brezillon wrote:
> >> > On Tue, 24 Jul 2018 08:46:33 +1000
> >> > NeilBrown wrote:
> >> >> One
Hi,
On Wed, Jul 25, 2018 at 07:48:21AM +1000, NeilBrown wrote:
> On Tue, Jul 24 2018, Brian Norris wrote:
> > On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
> >> On Tue, Jul 24 2018, Boris Brezillon wrote:
> >> > On Tue, 24 Jul 2018 08:46:33 +1000
> >> > NeilBrown wrote:
> >> >> One
Quoting Masahiro Yamada (2018-07-20 01:37:35)
> The Denali NAND controller IP needs three clocks:
>
> - clk: controller core clock
>
> - clk_x: bus interface clock
>
> - ecc_clk: clock at which ECC circuitry is run
>
> Currently, only the first one (50MHz) is provided. The rest of the
>
Quoting Masahiro Yamada (2018-07-20 01:37:36)
> Add USB3 PHY clocks where missing. Use fixed-factor clocks for those
> without gating.
>
> For clarification, prefix clock names with 'ss' or 'hs'.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to clk-next
Quoting Masahiro Yamada (2018-07-20 01:37:35)
> The Denali NAND controller IP needs three clocks:
>
> - clk: controller core clock
>
> - clk_x: bus interface clock
>
> - ecc_clk: clock at which ECC circuitry is run
>
> Currently, only the first one (50MHz) is provided. The rest of the
>
Quoting Masahiro Yamada (2018-07-20 01:37:36)
> Add USB3 PHY clocks where missing. Use fixed-factor clocks for those
> without gating.
>
> For clarification, prefix clock names with 'ss' or 'hs'.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to clk-next
Hi,
On Tue, Jul 24, 2018 at 4:51 PM, Matthias Kaehlcke wrote:
> The documentation claims that the 'reg' property consists of two values,
> the SPMI address and the length of the controller's registers. However
> the SPMI bus to which it is added specifies "#size-cells = <0>;". Remove
> the
Hi,
On Tue, Jul 24, 2018 at 4:51 PM, Matthias Kaehlcke wrote:
> The documentation claims that the 'reg' property consists of two values,
> the SPMI address and the length of the controller's registers. However
> the SPMI bus to which it is added specifies "#size-cells = <0>;". Remove
> the
Hi,
On Tue, Jul 24, 2018 at 4:46 PM, Matthias Kaehlcke wrote:
> The thermal zone uses spmi-temp-alarm as sensor, the trip points
> correspond to the PMIC thermal stages 1 and 2. The critical trip
> point at 125°C disables the partial PMIC shutdown at stage 2.
>
> Without an IIO input the sensor
Hi,
On Tue, Jul 24, 2018 at 4:46 PM, Matthias Kaehlcke wrote:
> The thermal zone uses spmi-temp-alarm as sensor, the trip points
> correspond to the PMIC thermal stages 1 and 2. The critical trip
> point at 125°C disables the partial PMIC shutdown at stage 2.
>
> Without an IIO input the sensor
101 - 200 of 1900 matches
Mail list logo
